Re: [swift-evolution] Variadic generics discussion

On Jun 1, 2016, at 3:29 AM, Brent Royal-Gordon via swift-evolution wrote: >> There's definitely the possibility of going off the deep end with complexity >> like C++, but since we already have tuples as a primitive language feature, >> I think there's a

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

> My pitch: I want to promote these three helper functions to the standard > library and remove their underscore prefixes. These functions currently have implementations like this: @_transparent @warn_unused_result public // @testable func

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

> Am 31.05.2016 um 10:14 schrieb Chris Williams via swift-evolution > : > > Honestly what I’ve wanted for quite some time is just reasonable default > parameter names. $0/$1… or any variation on index-based arguments is terrible > for comprehension, and I feel like

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1 `return` in guards should stay, because there one has to use either `return`, `continue` or `break`. It would be ugly and inconsistent if one of these could be left out. -Thorsten > Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution > : > > I really

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

I like this idea. The problem is that it would require that we have an Index.NonNegativeDistance as argument to really make it statically safe. And we would have to have methods producing these, probably as optional return values. Otherwise we won't have achieved statically safety but

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Great! Thanks for the additional details! -Thorsten > Am 31.05.2016 um 19:31 schrieb John McCall : > >> On May 29, 2016, at 6:38 AM, Thorsten Seitz wrote: >> An, now I see what you mean. You are right, P ::= ∃ t : P . t is a >> constrained existential

Re: [swift-evolution] Ad hoc enums / options

I admire the desire of this proposal to increase the readability of code. I'm -1 to the proposal itself, though: - It breaks the ability to pass in a variable containing the desired value, rather than the literal value itself. (Unless you actually want a not-so-anonymous enum type whose

Re: [swift-evolution] Variadic generics discussion

> I agree that this is a better design for Swift than the monstrosity I started > out with. > > The "biggest" technical challenge I see is being able to type a reduction > sort of operator on a heterogenous tuple based on on whatever protocols and > constraints are common to its constituent

Re: [swift-evolution] Ad hoc enums / options

> And the obvious answer is you can have up to 255 of these babies for the > anonymous enum type, and be able to pass numerical equivalents UInt8 with > compile time substitution. That the ad-hoc enumeration is basically a > syntactic shorthand for UInt8, with an enforced upper bound compile

Re: [swift-evolution] Working with enums by name

> Don't you think it's a bit of a waste to be repeating the name of the value > as a string just to use init(rawValue:) with them? Who said anything about repeating the name? Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type :help for assistance. 1> enum Planet:

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> On May 31, 2016, at 5:54 PM, Chris Lattner wrote: > >> On May 31, 2016, at 6:20 PM, Joe Groff wrote: >>> If the goal was to remove magic from the compiler, then a possible >>> direction would be to do something like: >>> >>> 1) Introduce a new

Re: [swift-evolution] Variadic generics discussion

I agree that this is a better design for Swift than the monstrosity I started out with. The "biggest" technical challenge I see is being able to type a reduction sort of operator on a heterogenous tuple based on on whatever protocols and constraints are common to its constituent members. For

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Revisiting this conversation, it seems that most of the design space has been thoroughly explored. I think all suggestions presented so far boil down to these: Q: How is an arbitrary boolean assertion introduced after `if let`? Option 1 (present scenario)--using `where` Advantages: expressive

Re: [swift-evolution] Working with enums by name

If I got the idea right, you would need to implement yourself the protocol methods to answer for both init(rawValue: Int) and init(rawValue: String) - which is how you have to do today only with the string part - while my proposed approach you'd have to implement nothing yourself. L > On 31

Re: [swift-evolution] Variadic generics discussion

> There's definitely the possibility of going off the deep end with complexity > like C++, but since we already have tuples as a primitive language feature, I > think there's a straightforward language design that enables the most > important use cases for variadics. If we have "tuple

Re: [swift-evolution] Working with enums by name

Don't you think it's a bit of a waste to be repeating the name of the value as a string just to use init(rawValue:) with them? What if I need to store another string associated with the value of the enum e.g. I want to create an enum to represent options in a menu and the associated value is to

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 31, 2016, at 7:10 PM, Chris Lattner wrote: > > This is very close to my priority list. That said, I think that all of these > are out of scope for swift 3 sadly. Happy to hear these priorities look about right to you also. (I realized

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> On May 31, 2016, at 6:20 PM, Joe Groff wrote: >> If the goal was to remove magic from the compiler, then a possible direction >> would be to do something like: >> >> 1) Introduce a new declmodifier named something like “atomiclazy”. >> 2) Disallow global and static

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 6:05 PM, Joe Groff wrote: > > >> On May 31, 2016, at 12:49 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

> On May 30, 2016, at 3:09 PM, Erica Sadun wrote: > You can't splat but you can decompose a tuple by assignment: Right. That is because assignment permits destructuring. Parameter lists do not (anymore). -Chris ___

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> On May 31, 2016, at 12:37 PM, Chris Lattner via swift-evolution > wrote: > >> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution >> wrote: >> Lazy evaluation when assigning static variables >> >> Introduction >> >> Both

Re: [swift-evolution] Variadic generics discussion

This is very close to my priority list. That said, I think that all of these are out of scope for swift 3 sadly. After Swift 3, the priority list will be driven by what the standard library needs to get its APIs realized in their ideal form (eg without any of the _ protocol hacks).

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 12:49 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution >> wrote: >> >> well there is no macro system, and for the moment a clear statement from

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

This arises a different question: Should `description` always return the same value? For example: Can `description` of “May 31th, 2016” return “Today” if we evaluate it today and return “Yesterday” if we evaluate it tomorrow? Are such side-effects (using a volatile global value) permitted? Then

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

>> On May 27, 2016, at 5:30 PM, Erica Sadun via swift-evolution >> wrote: >> >> >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon >>> wrote: >>> guard x == 0 && a == b && c == d && let y = optional, w = optional2, v =

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

My original v2 proposal draft suggested making value preserving and human readable descriptions orthogonal, but Chris and a few other people suggested they liked the originally suggested design better. I have a link in the "Alternatives" section to that original draft. Austin On Tue, May 31,

Re: [swift-evolution] Ad hoc enums / options

Correction/ Clarification. My assumption. The signature I am assuming is actually: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = false ) -> UIImage { > On May 31, 2016, at 3:27 PM, Hooman Mehr via swift-evolution >

Re: [swift-evolution] Ad hoc enums / options

If we go back to your original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = true ) -> UIImage { There is a different type of sugar that I would like to have: Having label stand for `true` when we have a defaulted boolean flag, whose

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I certainly am warm to that myself, although I’m also sympathetic to what Chris wrote about the inconsistency it introduces: let x = optionalX!, y = optionalY! // Works! doStuff(x, y) if let x = optionalX, y = optionalY { // Doesn’t work. Confusion! doStuff(x, y) }

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Tue May 31 2016, Thorsten Seitz wrote: > I agree with Vladimir. Having a value preserving representation is > orthogonal to a human readable representation. I too think he's making a good point. I could be missing something, but it seems to me we don't fully

Re: [swift-evolution] Working with enums by name

> On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> • also wants OptionSetType-like behavior (and thus an Int raw type). > > Then it's not an `enum`, it's a `struct`. You can get it for free as an array of enums and test with

Re: [swift-evolution] Working with enums by name

> • also wants OptionSetType-like behavior (and thus an Int raw type). Then it's not an `enum`, it's a `struct`. -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Exactly what I feel about this. I am prepared to go as far as disallowing: let x = optionalX, y = optionalY syntax to free up comma for use instead of semicolon. Then the above becomes: let x = optionalX, let y = optionalY In this case we will keep the comma at the end of the line as well.

Re: [swift-evolution] Working with enums by name

> On May 31, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> | enum Planet : Int { >> | case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune >> | >> | init?(caseName name : String) { > > The compiler actually does

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:20 PM, Brent Royal-Gordon > wrote: > >> func scaleAndCropImage( >>image: UIImage, >>toSize size: CGSize, >>operation: (.Fit | .Fill) = .Fit >>) -> UIImage { > > As I said the last time this proposal came up, I think this is great

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 9:49 PM, Chris Lattner wrote: > > >> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution >> > wrote: >> >> well there is no macro system, and for the moment a clear statement

Re: [swift-evolution] Ad hoc enums / options

> func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > operation: (.Fit | .Fill) = .Fit > ) -> UIImage { As I said the last time this proposal came up, I think this is great right up until the moment you need `operation` to be computed or kept in a variable. Then

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:46 PM, Vladimir.S wrote: > > > If you are not allowing callers to store their argument in a variable then > > I am 100% opposed to this. That would the first case in Swift where you > > *MUST* provide a literal argument when calling a function, and

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

>case spades { >let bezierPath = UIBezierPath() Does each instance of `.spades` have a *separate* UIBezierPath, or do all instances of `.spades` share one? If it's the former, I have strong doubts you'll actually get this through. If it's the latter, that isn't really what this

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:43 PM, Brandon Knope wrote: > Why would that argue for the removal of where > > if let y = y where y != 5 && x < z > > I would still prefer: > if let y = y where y != 5, x < z, let z = someOptional where z == 10 > > To me, where still has a place. And

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except I disagree. It might seem like a stylistic flourish, but it can be more expressive in informing the reader that the variable after the where clause was recently introduced somewhere in the preceding clause. Without it, you'd have to scan the entire conditional clause and around the

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 3:39 PM, Austin Zheng wrote: > > (inline) > > On Tue, May 31, 2016 at 1:34 PM, Matthew Johnson > wrote: > >> On May 31, 2016, at 3:25 PM, Austin Zheng >

Re: [swift-evolution] Ad hoc enums / options

> If you are not allowing callers to store their argument in a variable then > I am 100% opposed to this. That would the first case in Swift where you > *MUST* provide a literal argument when calling a function, and *CANNOT* > provide a value you store in a variable (possibly something you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Why would that argue for the removal of where if let y = y where y != 5 && x < z I would still prefer: if let y = y where y != 5, x < z, let z = someOptional where z == 10 To me, where still has a place. And that place is saying "hey this is a recently introduced or shadowed variable, so don't

Re: [swift-evolution] Variadic generics discussion

(inline) On Tue, May 31, 2016 at 1:34 PM, Matthew Johnson wrote: > > On May 31, 2016, at 3:25 PM, Austin Zheng wrote: > > I have a proposal for #6 in the pipe, but there are actually some > subtleties I have to work out (it's not as simple as just

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 3:25 PM, Austin Zheng wrote: > > I have a proposal for #6 in the pipe, but there are actually some subtleties > I have to work out (it's not as simple as just slapping a generic type > signature on a let constant). Cool. Looking forward to

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

On 31.05.2016 22:37, Chris Lattner wrote: 1) Introduce a new declmodifier named something like “atomiclazy”. 2) Disallow global and static variables, unless they are explicitly marked atomiclazy (compiler would provide a fixit hint to suggest this). 3) Replace the atomiclazy magic with a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope wrote: > What is wrong with: > > if let x = x where x > 10, y != 5, let z = z where z != x > > Just as a contrived example? > Because any grammar that permits what you propose would necessarily permit: ``` if let x = x, x > 10, y !=

Re: [swift-evolution] Variadic generics discussion

(I should mention that this is all just my personal read on the situation, and shouldn't be construed as trying to stop or induce anyone else from doing anything. Would love to see other proposals on generics, if people want to work on them.) On Tue, May 31, 2016 at 1:25 PM, Austin Zheng

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope wrote: > And why couldn't we propose that it should? > And that is this proposal; the options considered for the spelling are comma, semicolon, and `&&`. Now we circle back to my earlier point. The introduction of any of these would

Re: [swift-evolution] Variadic generics discussion

I have a proposal for #6 in the pipe, but there are actually some subtleties I have to work out (it's not as simple as just slapping a generic type signature on a let constant). I think #5 is just considered a 'bug' and doesn't need a proposal (it might actually be finished already; I saw some

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I added the example I posted in my last reply and submitted a pull request.  --  Adrian Zubarev Sent with Airmail ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

> 31 maj 2016 kl. 21:37 skrev Chris Lattner : > >> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution >> wrote: >> Lazy evaluation when assigning static variables >> Introduction >> Both stored type properties (static) and lazy

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution > wrote: > > This is pretty much where my thinking about the topic has led me as well. > I'll resign this topic to pursue some other, hopefully more relevant work, > although anyone who wants to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

And why couldn't we propose that it should? Brandon > On May 31, 2016, at 4:14 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope wrote: >> What is wrong with: >> >> if let y = y && x < z >> >> They are, after all, independent from

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let x = x where x > 10, y != 5, let z = z where z != x Just as a contrived example? Brandon > On May 31, 2016, at 4:03 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 2:59 PM, Brandon Knope wrote: >> Except "b" is the main focus

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

On 31.05.2016 22:42, Leonardo Pessoa via swift-evolution wrote: I'd actually like to see a change in guard so that I don't need those braces. I'd like something more readable like | guard cond1 or return nil | guard cond2 or throw MyError.IllegalValue | guard cond3 or do { ... } I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:08 PM, Brandon Knope wrote: > What is wrong with: > > if let y = y && x < z > > They are, after all, independent from each other. > That won't compile. Brandon > > On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:59 PM, Brandon Knope wrote: > > Except "b" is the main focus of the where clause and b was just in the > preceding if condition. > > I feel like we are trying to find ways to break the current where clause even > though we've enjoyed it for almost a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

The y == y I presume is to get around this requirement by reintroducing a variable in the previous part of the conditional to be able to refer to other variables. x > z isn't allowed, but y == y && x > z would be because it's using y. I'm not convinced anyone would do this when they could

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let y = y && x < z They are, after all, independent from each other. Brandon > On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:59 PM, Brandon Knope wrote: > Except "b" is the main focus of the where clause and b was just in the > preceding if condition. > > I feel like we are trying to find ways to break the current where clause > even though we've enjoyed it for almost a year

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution < swift-evolution@swift.org> wrote: > > On May 31, 2016, at 1:47 PM, Xiaodi Wu wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except "b" is the main focus of the where clause and b was just in the preceding if condition. I feel like we are trying to find ways to break the current where clause even though we've enjoyed it for almost a year now. I had no idea it was problematic and restrictive. I thought it made its

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I apologize for the tons of typos I make. :/ --  Adrian Zubarev Sent with Airmail Am 31. Mai 2016 um 21:55:53, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I'd actually like to see a change in guard so that I don't need those  braces. I'd like something more readable like  |

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

A huge +1 on the syntax change, which I think is a colossal improvement over the current situation and adds a lot of clarity to enum declarations. Neutral on the necessity to add actual stored properties to the enums. If the new syntax were merely syntactic sugar that would effectively generate

Re: [swift-evolution] Variadic generics discussion

This is pretty much where my thinking about the topic has led me as well. I'll resign this topic to pursue some other, hopefully more relevant work, although anyone who wants to continue the discussion is welcome to. On Tue, May 31, 2016 at 12:49 PM, Chris Lattner wrote: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:47 PM, Xiaodi Wu wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution > > wrote: >> >> Not allowed: >> … >> let a = a >> let b = b where b > 10 && a >

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution > wrote: > > well there is no macro system, and for the moment a clear statement from > chris that this is not on the table in the short term. the code in the > example looked like run-of-the-mill

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution < swift-evolution@swift.org> wrote: > >> Not allowed: >> … >> let a = a >> let b = b where b > 10 && a > 5 >> > > Why would this not be allowed by your rule? You're making use of `b` in > your where clause. As I demonstrated

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> > Not allowed: > … > let a = a > let b = b where b > 10 && a > 5 > > Why would this not be allowed by your rule? You're making use of `b` in your > where clause. As I demonstrated above, essentially any assertion can be > rewritten to work around your rule. In general: It is not allowed

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I'd actually like to see a change in guard so that I don't need those braces. I'd like something more readable like | guard cond1 or return nil | guard cond2 or throw MyError.IllegalValue | guard cond3 or do { ... } It may add more cases for the compiler to handle but in all cases I used

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 2:36 PM, Adrian Zubarev via swift-evolution > wrote: > >> Exactly. You are allowed to omit `return` if the entire body only consists >> of `return some().expression` > > Thats where the useless example comes in (but we don’t need this

[swift-evolution] Working with enums by name

Since we're talking a lot enums these days, I'd like to bring into discussion a proposal that has been briefly mentioned in another thread to enable working with enums using their names. This is currently possible in the language but it's a bit burdensome. You can just interpolate the value of

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Exactly.  You are allowed to omit `return` if the entire body only consists of `return some().expression` Thats where the useless example comes in (but we don’t need this behavior at all): func foo(boolean: Bool) {     guard boolean else {}     print("true“) } I made some changes to the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: >> These lines of reasoning are what have compelled me to conclude that `where` >> might not be salvageable. > > To

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 8:45 PM, Adrian Zubarev via swift-evolution > wrote: > > I feel like return is very important part of guard statement. I understand > the requirement for consistency with properties/closures/functions, but I’ll > prefer to have some

Re: [swift-evolution] Variadic generics discussion

what I mean is I think it is perfectly doable as a runtime thing, without much apparent magic (the compiler support code is a different story), but it looks like a clean runtime story. > On May 31, 2016, at 7:59 PM, Austin Zheng wrote: > > How so? I'm interested in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I could be pedantic and say that "previousInterestingFoo" now relies on the newly bound "foo" on assignment in the while loop keeping it relevant contextually. Ultimately, my responsibility as a user of the language is not to try to figure out the inner workings of the grammar or the

Re: [swift-evolution] Variadic generics discussion

well there is no macro system, and for the moment a clear statement from chris that this is not on the table in the short term. the code in the example looked like run-of-the-mill swift, except for the “…". so that leaves us with swift looking code that would be executed by the compiler, but

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 2:13 PM, Adrian Zubarev via swift-evolution > wrote: > >> Please remove the section on guard as any of the preceding will never have >> single expression top level code blocks if they contain a guard clause. > > I didn’t get this at first but

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause. I didn’t get this at first but now I see your point, it’s because the whole returning scope will need `return` at the very end so `guard` should

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 1:11 PM, Austin Zheng via swift-evolution > wrote: > > AFAICT compile-time code generation suffers from the C++ templates problem - > my understanding is that if you don't have access to the definition of the > template you can't specialize. A

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 2:04 PM, Erica Sadun wrote: > >> >> On May 31, 2016, at 12:35 PM, Matthew Johnson > > wrote: >> >> I think I'm -1 on this. It makes things easier for the implementer of the >> function and

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 12:35 PM, Matthew Johnson wrote: > > I think I'm -1 on this. It makes things easier for the implementer of the > function and harder for the caller. > > It's not clear whether the caller could store an argument to pass in a > variable, but if

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 1:59 PM, Adrian Zubarev via swift-evolution > wrote: > >> +1. This is example *is not* a single expression code block. There are 3 >> expressions (the condition, the return value in the else block, and the >> primary return value). > > The

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: > These lines of reasoning are what have compelled me to conclude that `where` > might not be salvageable. To which, I'd add: `where` suggests there's a subordinate and semantic relationship between the primary condition

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 12:35 PM, Adrian Zubarev via swift-evolution > wrote: > > Here is the draft proposal: > https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md > >

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1. This is example *is not* a single expression code block. There are 3 expressions (the condition, the return value in the else block, and the primary return value).  The `else` block is a returning single expression block. I can’t show the `guard` example without any returning scope. You

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

See, I'd wondered about that early on. But it didn't sound like this was a restriction that could be formalized straightforwardly in the grammar. Even if it could, it is too restrictive. Consider: ``` var previousInterestingFoo = 0 while let foo = sequence.next() where previousInterestingFoo <

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

> On May 31, 2016, at 1:16 PM, Vladimir.S via swift-evolution > wrote: > > I really like the proposal in case of properties and functions, but I really > don't want to have > guard boolean else { "false” } +1. This is example *is not* a single expression code

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I really like the proposal in case of properties and functions, but I  really don't want to have  guard boolean else { "false" }  I feel like `return` is very important part of `guard` statement.  I understand the requirement for consistency with  properties/closures/functions, but I'll prefer to

Re: [swift-evolution] Ad hoc enums / options

Here is a correction to the equivalent declaration. It would be a RawRepresentable String enum to be compatible with serialization mechanisms e.g. JSON. and other representations. Again, the name could be auto-generated to keep the syntax succinct. … would be equivalent to class MyImage {

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I feel like return is very important part of guard statement. I understand the requirement for consistency with properties/closures/functions, but I’ll prefer to have some inconsistency in language in this case and require return for guard. And in case I’ll have to choose all-or-nothig, I’ll

Re: [swift-evolution] Ad hoc enums / options

>> I have two suggested “improvements” >> >> 1) Make the enum String raw-representable. Name it somehow. This does not >> affect Erica’s original syntax. >> 2) Force an explicit name. >> >> class MyImage { >> func scaleAndCropImage( >> image: UIImage, >> toSize

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> What I'm hearing is that at least some developers would like to retain > where clauses in case conditions and optional binding conditions but still > allow the more controllable logic introduced by differentiating condition > types with semicolons or newlines. Is that a fair summary? I believe

Re: [swift-evolution] Ad hoc enums / options

I think I'm -1 on this. It makes things easier for the implementer of the function and harder for the caller. It's not clear whether the caller could store an argument to pass in a variable, but if they could they would need to list out all cases in the type of the variable (unless these

Re: [swift-evolution] Ad hoc enums / options

> Begin forwarded message: > > From: Christopher Kornher > Subject: Fwd: [swift-evolution] Ad hoc enums / options > Date: May 31, 2016 at 12:25:33 PM MDT > To: Erica Sadun > > Apologies for using you as a relay... > >> Begin forwarded message: >> >>

Re: [swift-evolution] [Pitch] #warning

Thank you Charlie, just exactly what I think regarding all these #errors/#warnings/comments etc On 31.05.2016 19:53, Charlie Monroe via swift-evolution wrote: The way I see it and would use it: Directives: *#error* - fatal error, the binary shouldn't compile - e.g. unknown OS host and the

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I really like the proposal in case of properties and functions, but I really don't want to have guard boolean else { "false" } I feel like `return` is very important part of `guard` statement. I understand the requirement for consistency with properties/closures/functions, but I'll prefer to

  1   2   >