|
Subjunctive posted:Every single person involved in Swift knew that opening language direction to public discussion was going to be like chewing glass. For none of them is this the first rodeo, and all these rodeos suck. They're a huge distraction and emotionally draining. Agreed; Even though I don't think the renaming proposal is all that important I trust the Swift team and I know they've had lots of internal arguments about it so I'm just going to wait and see how it works in practice. I'm also mostly staying away from swift-evolution (besides the fact that I have a real job and my own side project app [that will surely be rejected in review]).
|
# ? Feb 5, 2016 00:07 |
|
|
# ? May 30, 2024 12:19 |
|
I'm in a class:code:
code:
|
# ? Feb 7, 2016 18:09 |
|
Is this intended:code:
|
# ? Feb 17, 2016 20:35 |
|
Doh004 posted:Is this intended: I doubt we ever explicitly considered it, but it seems reasonable enough. What else could we reasonably do, warn "hey, you probably fat-fingered something here, and we're pretty sure it's what you actually wanted, but maybe you fat-fingered something else nearby since you're such a lovely typist"? It's not like we're interpreting it as octal or something.
|
# ? Feb 17, 2016 20:43 |
|
Is there an upper limit to the number of arguments in a closure, or does this mean I can write $8008135 if I'm patient enough?
|
# ? Feb 17, 2016 20:57 |
|
rjmccall posted:I doubt we ever explicitly considered it, but it seems reasonable enough. What else could we reasonably do, warn "hey, you probably fat-fingered something here, and we're pretty sure it's what you actually wanted, but maybe you fat-fingered something else nearby since you're such a lovely typist"? I'd be okay with this warning. I only saw this while code reviewing a PR. I yelled at the engineer because CLEARLY they hadn't actually attempted to compile their code. Much to my surprise they had and it worked just fine
|
# ? Feb 17, 2016 21:14 |
|
Flobbster posted:Is there an upper limit to the number of arguments in a closure, or does this mean I can write $8008135 if I'm patient enough? There's certainly some implementation limit, and it's probably lower than we strictly validate, but there's no particular reason for us to impose a language limit.
|
# ? Feb 18, 2016 00:24 |
|
Doh004 posted:I'd be okay with this warning. you don't seem to 'get' swift you can't yell at people and swift things, you've gotta be mellow, put on some smooooth tunes, glass of nice whiskey by the fireplace
|
# ? Feb 18, 2016 00:37 |
|
rjmccall posted:There's certainly some implementation limit, and it's probably lower than we strictly validate, but there's no particular reason for us to impose a language limit. Well, I gave let x = { $8008135 } five minutes to compile before I gave up and killed it. I imagine eventually it would either hit the "unable to infer closure return type" error that I would expect, or die for some other resource exhaustion reason. I'm tempted to file a bug, but this is really stupid Edit: Because I'm procrastinating, I did a little digging. It looks like referencing $n in a closure is quadratic on n (albeit with a low constant). Extrapolating the results of $0 through $3500 or so... $8008135 would take about 275 days to compile. Flobbster fucked around with this message at 04:04 on Feb 18, 2016 |
# ? Feb 18, 2016 02:03 |
|
They should cap it at $65534 so they can fit the numbers in a uint16_t and make better use of cache lines.
|
# ? Feb 18, 2016 02:28 |
|
Flobbster posted:Well, I gave let x = { $8008135 } five minutes to compile before I gave up and killed it. I imagine eventually it would either hit the "unable to infer closure return type" error that I would expect, or die for some other resource exhaustion reason. Out of curiosity, is it still non-linear if you only parse / type-check? There are command-line options you can use for this.
|
# ? Feb 18, 2016 04:12 |
|
rjmccall posted:Out of curiosity, is it still non-linear if you only parse / type-check? There are command-line options you can use for this. swiftc -parse -dump-type-refinement-contexts for $3500 still takes about 3.5 seconds to complete before erroring out, so it looks like yes. I should mention that I'm using Swift 2.1 for this—I don't have 2.2 installed on this machine, but I know there were a ton of codegen/performance improvements in that release. Not sure if this is something that would be affected, though.
|
# ? Feb 18, 2016 04:46 |
|
So I've had this idea kickin around for an app I'd like to develop while I'm still in school for a while now. I want to prove that I can work with a decently sized project and want to learn more development skills in general. I started messing around with React Native and I'm starting to feel like it is loving dumb since I can't seem to get it to do anything I want it to do without some fuckery or hacks. If I work with swift, am I going to have an easier time building my app coming from a java & c background than with this react bullshit? Thanks.
|
# ? Feb 21, 2016 06:00 |
|
playground tough posted:If I work with swift, am I going to have an easier time building my app coming from a java & c background than with this react bullshit? Thanks. In my opinion, yes. React Native is cool but has kind of a steep learning curve if you're not already familiar with JavaScript / web tools / React itself.
|
# ? Feb 21, 2016 06:03 |
|
playground tough posted:So I've had this idea kickin around for an app I'd like to develop while I'm still in school for a while now. I want to prove that I can work with a decently sized project and want to learn more development skills in general. I started messing around with React Native and I'm starting to feel like it is loving dumb since I can't seem to get it to do anything I want it to do without some fuckery or hacks. Yes 100%. Please learn the actual system first instead of jumping into whatever Facebook's framework of the year may be at the time.
|
# ? Feb 21, 2016 16:34 |
|
Help, please. What am I doing wrong.
|
# ? Feb 21, 2016 18:10 |
|
That's when I add print() everywhere and recompile.
|
# ? Feb 21, 2016 20:07 |
|
I recently discovered that LLDB is not idempotent; I get some mystifying error about declarations having conflicting types, but I can just try again and get a different message, and then eventually it just works. You might be hosed, though.
|
# ? Feb 21, 2016 23:24 |
|
rjmccall posted:I recently discovered that LLDB...not idempotent you don't say?
|
# ? Feb 22, 2016 03:35 |
|
Well, I was expecting that the expression parser would be starting from a clean-ish state each time, but I guess I know for a fact that it doesn't, so welp.
|
# ? Feb 22, 2016 04:24 |
|
Is there any way in Swift to generate a copy of a struct but with one or more values changed? So given a struct like...code:
code:
|
# ? Feb 25, 2016 12:49 |
|
I saw an interesting talk about lenses that provided a way to do that. Interesting as a thought experiment I didn't think it was practical. If you are okay with the boilerplate to accomplish this. I think that might be worth a look. If you are looking for a language feature to do basically:code:
https://www.youtube.com/watch?v=ofjehH9f-CU
|
# ? Feb 25, 2016 21:06 |
|
There isn't a language feature for it right now. You can add a method per property, like so:Swift code:
|
# ? Feb 25, 2016 21:55 |
|
You can also do something likeSwift code:
Swift code:
|
# ? Feb 25, 2016 21:58 |
|
Ah cool...alas I'm being super strict + anal about no var's whatsoever! Purely for a learning exercise. Do you think it might be a feature for the future?
|
# ? Feb 25, 2016 23:30 |
|
toiletbrush posted:Ah cool...alas I'm being super strict + anal about no var's whatsoever! Purely for a learning exercise. Sure, it's something we're aware of as being kindof awkward.
|
# ? Feb 25, 2016 23:42 |
|
Does this mean you're also looking at ways make it easier to write fluent interfaces/builders with structs? Right now having the initializer result be immutable is a showstopper because I can't write "let foo = Foo().something(5).somethingElse(10)" even if those methods are mutating. I've been working on a side project where I've had an opportunity to really use protocol-oriented programming, extensions, constraints, and generics in some cool ways and I've gotta say, I love just how algebraically Swift lets me design components. Being able to say "this type implements this set of methods, but also this superset of additional methods if the associated type is X" is mind blowing. And I've only written one class, and it was purely an implementation detail to get copy-on-write for a value type.
|
# ? Feb 26, 2016 00:24 |
|
Thanks! I think we appreciate the importance of builder patterns and want to serve those better. I can't imagine us ever allowing you to call mutating methods on an r-value, though.
|
# ? Feb 26, 2016 01:41 |
|
toiletbrush posted:Is there any way in Swift to generate a copy of a struct but with one or more values changed? I handle this pretty similarly to the way rjmmccall mentioned: code:
My primary annoyance is with the sheer amount of boilerplate, but it's mostly copy-pasting and swapping out which variable is being changed, otherwise, it works quite well, I think.
|
# ? Feb 26, 2016 05:23 |
|
If gyb was built into the compiler/build system we totally wouldn't need any new language features ever again.
|
# ? Feb 26, 2016 05:36 |
|
Plorkyeran posted:If gyb was built into the compiler/build system we totally wouldn't need any new language features ever again. I mean I've almost asked for Scala-style macros in this thread more than once, but then I remember what a mess those could turn into. Same way Clang plugins to transform code are fun until they aren't.
|
# ? Feb 26, 2016 06:14 |
|
Flobbster posted:Does this mean you're also looking at ways make it easier to write fluent interfaces/builders with structs? Right now having the initializer result be immutable is a showstopper because I can't write "let foo = Foo().something(5).somethingElse(10)" even if those methods are mutating. We've found this to be the case as well. My rough guess right now is we're going to end up deleting about 20,000 - 30,000 lines of code when the core sync/database logic is fully converted to Swift, if not more.
|
# ? Feb 26, 2016 09:15 |
|
Is there some reason, other than for fun, you would define your structs like that? I hope they don't add language features that make people think declaring structs full of let bindings is a sane idea.
|
# ? Feb 26, 2016 15:32 |
|
Why do you think immutable structs are a bad idea?
|
# ? Feb 26, 2016 17:18 |
|
A struct with var properties is still immutable.
|
# ? Feb 27, 2016 01:27 |
|
pokeyman posted:A struct with var properties is still immutable. In a way, but in another way it looks mutable in usage. Even if the struct has var properties, it would still benefit from this syntax, because right now it takes me at least two lines to make a copy of a template struct with some changes.
|
# ? Feb 27, 2016 01:53 |
|
If I saw a bunch of structs full of let bindings I would presume that the person who wrote the code didn't understand value types. If you're using structs in a reasonable way, and two lines is an issue, then you could define your own way of handling that. e.g.code:
|
# ? Feb 27, 2016 14:03 |
|
Is it because declaring a variable of a strict type using "let" will prevent mutation of the "var" members of the struct anyway, thus making "let" properties on a struct pointlessly strict?
|
# ? Feb 27, 2016 17:59 |
|
Yes. If you use lets, you're taking away the user's choice of mutability for any particular value.
|
# ? Feb 27, 2016 18:37 |
|
|
# ? May 30, 2024 12:19 |
|
jawbroken posted:If you're using structs in a reasonable way, and two lines is an issue, then you could define your own way of handling that. e.g. The thing is, this breaks encapsulation; now whoever wants to create a struct with one variable different has to know how that variable is stored internal to the struct. I find that problematic. Back to my star example: code:
If I went with the closure idea, then I'd have to expose how I'm storing that to whoever calls, and that seems to break encapsulation. It also means I'd probably have to do something fancy to allow setters on all three, or if I change my mind about internal storage later, I'd have to update all the callers. As for why, for the Star, pretty much all of those are there for ease of testing; create an object with sane defaults and change the things I want in the test clearly. However, as you get higher up in my struct tree, I keep the same notation of withChangeToX to effectively cascade a couple of changes in the struct tree, and I like the consistency of naming. Doing it with the withX functions also gives me the ability to pause anywhere in the chain and capture the struct, do some more work and capture that, and possibly run comparisons on the two, especially around computed values. The Star example is admittedly a little weak in that arena, because they're effectively static in my game.
|
# ? Feb 27, 2016 19:08 |