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

Maybe it's overkill. My personal opinion is that breaking the symmetry of the language like this (are there any other types of function arguments that cannot be passed as either variable values or literals?) is too much a price to pay. Your library thinks it's being clever and vends its function

Re: [swift-evolution] Variadic generics discussion

On Jun 1, 2016, at 8:26 AM, Brent Royal-Gordon wrote: >> Sounds like more compiler magic... rather than trying to reduce it. > > Think of it this way: The amount of compiler magic should be at most > proportional to the amount of utility granted by that magic. Most of the > magic in this des

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

> It breaks the ability to pass in a variable containing the desired value, rather than the literal value itself. Maybe that's appropriate? If the caller is not passing in a hardcoded enum case, then that enum is probably general enough that it warrants a normal enum. But there are also situation

Re: [swift-evolution] Variadic generics discussion

> Sounds like more compiler magic... rather than trying to reduce it. Think of it this way: The amount of compiler magic should be at most proportional to the amount of utility granted by that magic. Most of the magic in this design is not directly in service of variadic generics, but rather in

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 straightforward language design that e

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 _isDebugAssertConfigurat

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 I’m being lazy and hurting w

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 like the proposal in case o

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 effectively

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

> Swift doesn’t have this problem, so it treats warnings as “things that should > be addressed before you commit your patch, but shouldn’t block a build if > (e.g.) you’re in the middle of a big refactoring”. For example, an unused > variables is a warning in Swift. That sounds an awful lot li

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

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 type defining a subtype relationship. >>

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 definition

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 mem

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 tim

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: S

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 declmodifier named something like “atomiclazy”.

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

I like the idea, but it is worth noting that unless the syntax is generalized (which I'm not necessarily against), the type of `operation` cannot be referenced. This means that you can't declare a variable of that type, unless you assign the argument to it. Félix > Le 31 mai 2016 à 09:16:56, E

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 examp

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 whe

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 Ma

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 splatting"

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 afterwards that I left of

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 variables, unless they are e

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: >>> >>> well there is no macro system, and for the moment a clear statement

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 ___ swift-evolution mailing list swif

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 stored type properties (static) and lazy stored propert

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). Conditio

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 >> chris that this is not on the table in the short term

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 = optional 3 && z == 2 else { ... } Fi

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, 2016

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 > wrote: > > If we go back to y

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 def

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) } Als

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 understand this design yet. --

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

If we had generic protocols, you could implement RawRepresentable twice, once using Ints and one using Strings. But that's probably never going to happen. /digression Austin On Tue, May 31, 2016 at 3:11 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 31, 201

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 contains vs member -- E, who has p

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 https://lists.swift.org/mailman/listinfo/swi

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 this already through RawRep

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 right up > until the mo

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

> | enum Planet : Int { > | case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune > | > | init?(caseName name : String) { The compiler actually does this already through RawRepresentable if you put `String` as your raw type. So what's the use case for this? Code which

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

I prefer keeping $ as a valid character for identifiers. Moreover, such a change will break a lot of client code other than closures (where it can be auto-migrated). > On May 31, 2016, at 2:51 AM, James F via swift-evolution > wrote: > > Moreover, this would free up $ as an operator. I'm for

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

Returning to the list after a brutally busy spring, a demi-review: I vote… +1 on addressing this problem, +1 on the proposal’s structural approach (list of items which may be either boolean tests or bindings, in any order), and +1 on eliminating “where” in the presence of a better approach, …bu

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 >> mailto:swift-evolution@swift.org>> 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

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 yo

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

> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution > wrote: > > * Should `where` clauses be allowed where the contents of the where clause > have no connection to the condition that precedes it? > * Is there a technical way to to check for such conformance? > * Should the `where` clau

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 *CANNOT* > > provide a

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 syn

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 that place is sayin

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 co

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 > > wrote: >> >> I have a proposal for #6 in the pipe, but

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 receiv

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 slapping a > generic type signature on a let co

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 reviewing a draft when it’s re

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 property

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 != 5, let z = z, z

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 wrote:

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 argue for the e

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 com

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 stored properties (lazy var) >> are lazily initializ

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 continue the discussion is welcome

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 each other. > > That won't compile.

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 of the where clause and b was just in

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 partia

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 < > swift-evolution@swift.org> wrote: > > On

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 year now. I had no

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 jus

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 >> wrote: > >> >>> On May 31, 2016, at

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

I should have left the entire context in my reply. > On May 31, 2016, at 1:59 PM, Xiaodi Wu wrote: > > On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On May 31, 2016, at 1:47 PM, Xiaodi Wu >

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

+1 from me to this updated proposal. Now I like it very much :) On 31.05.2016 22:36, 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 t

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 now. I had no idea

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> wrote: > >> >>> Not allowe

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 in

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  | gua

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: > > On May 31, 2016, at

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 gu

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 > mailto: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 ru

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 swift, except for the “…". so t

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 beca

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 gu

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 behavior at > all): > > func foo(

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

On Tue, May 31, 2016 at 2:32 PM, Christopher Kornher via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > >> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: > >> These lines of rea

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

so there is no way to draw a parallel between integer literals and say ‘value’ ? Could you provide an example? I don’t understand what you might mean. --  Adrian Zubarev Sent with Airmail ___ swift-evolution mailing list swift-evolution@swift.org http

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

> 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 stored properties (lazy var) > are lazi

[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 the

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 prop

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 which, I'd add: `where` suggests there's a subord

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 inconsistency in language in this case

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 anything that can get us awa

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 compiler.

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 wit

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 now I see your point, it’s b

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 follo

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 Swift (regular, non-variadi

  1   2   >