Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

+1 I'm getting used to go back to code and unwrap my optionals but if this could be done more automatically in interpolation it'd be great. On 18 May 2016 at 15:50, Krystof Vasa via swift-evolution wrote: > The string interpolation is one of the strong sides of Swift,

Re: [swift-evolution] [proposal] Allow "let" for computed propertieswhich only reference immutable data

ted property is constant, but maybe it doesn't work that way. - Dave Sweeris On May 17, 2016, at 14:40, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote: If the value of the property is a constant, shouldn't you just declare it as one? If you have any sort of com

Re: [swift-evolution] [proposal] Union Type

a > switch/if tree or whatever else inside the method to break the types back > apart again in the method body and without even needing any new mechanism > in the language at all? > > Again, sorry for the (very likely) redundant noise on my part. > > l8r > Sean > > > >

Re: [swift-evolution] [proposal] Union Type

Jiannan, I agree there is an use for union types, I'm just not really fond of the syntax (I'd really prefer something like 'union<...>') and with using it for optionals. To enable this syntax for optionals, None would have to be a valid type of the language and that would enable one to create the

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

ompiler > knows that a computed property is constant, but maybe it doesn't work that > way. > > - Dave Sweeris > > On May 17, 2016, at 14:40, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org> wrote: > > If the value of the property is a constant, shouldn

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

I don't like this idea so -1 from me. Most languages allow that extra comma at the end of a list and sure that eases reordering a list but making them optional at all lines may make the code confusing to read and put an extra job at the compiler to decide whether a line is a new item or

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

If the value of the property is a constant, shouldn't you just declare it as one? If you have any sort of computation in it, even concatenating two constant strings, can you really say this is a constant? And you would also be overloading the compiler into trying to check for every property you

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is'instead of just types

+1 -Original Message- From: "Joe Groff via swift-evolution" Sent: ‎16/‎05/‎2016 06:06 PM To: "swift-evolution" Subject: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is'instead of just types Currently, we parse a type

Re: [swift-evolution] Winding down the Swift 3 release

I'm speaking for myself here but I'm already working independent projects in Linux here. The only missing feature to my current needs it's the implementation of NSBundle methods like load(). Any idea when we'll get those implemented? - Leonardo -Original Message- From: "Chris Lattner

Re: [swift-evolution] Union instead of Optional

I don't really get it why the compiler is to complain about the if block not having an else in this case. That seems like a bug that will push us to write unnecessary code. The compiler is not capable of inferring there are more conditions to evaluate in an if statement opposed to a switch

Re: [swift-evolution] Union instead of Optional

I can understand this proposal nite and I don't really think they're related to enums at all. You can today achieve the very same behaviour using an empty protocol. protocol P { } class A : P { } class B : P { } struct C : P { } func test(value : P) { } IMO, the proposed syntax will only

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

this because they should have the > same problem... > > On Friday, 13 May 2016, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org> wrote: > >> To me this makes more sense for operators than for other functions or >> properties. For the former you c

Re: [swift-evolution] Could enums have their rawValue type inferred?

Eric, I think I understood your proposal. If I may explain in other words it would be "to automatically cast rawValue when assigning an enum value to a variable or argument of the type of the enum's raw value", am I right? I think this would imply a little more inference and type checking rules

Re: [swift-evolution] Removing "_ in" from empty closures

+1 here and I don't think it will make life more difficult for the compiler as it already handles the examples Joe Groff provided. On the contrary, by removing the need for those "_ in" declarations and checks you make the life of the compiler easier. - Leonardo On 13 May 2016 at 13:25, Matthew

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

To me this makes more sense for operators than for other functions or properties. For the former you could create conflict with previously declared function (or properties with variables) and there is no restriction in Swift that says you cannot or should not create a top level function or

Re: [swift-evolution] multi-line string literals.

That's my point. You start with a little two-line string and when you see you have those all over your code. A feature is never bad but a feature that may be misused creates temptation to go for bad programming practices, like "I'm using it just this once" and once you're there you never stop.

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

I too agree the unwrapping process can be tedious but I believe this is best because it forces us to check we're doing the right thing in code and prevents a lot of errors we have to keep on checking in more dynamic languages. -1 from me too. - Leonardo On 11 May 2016 at 10:19, Patrick Smith via

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

I think a clearer syntax here would be for n in 1...2 { } as it casts no shadow of doubt about how many times the loop will be executed. > On 10 May 2016, at 9:27 pm, Tyler Cloutier via swift-evolution > wrote: > > What would repeat 1 { } mean then? Repeat N?

Re: [swift-evolution] [proposal] default returns

This feels a little bit like back when I began studying Pascal where every function has an implicit Result variable to which we were to set the return value. I'm not particularly against Pascal or this syntax but it may lead to programmers scratching their heads to find out where a certain

Re: [swift-evolution] [proposal] extra if syntax

Despite being interesting and existing in other languages, I believe in Swift this could lead to weird declarations like let x = 5 if b == 2 Would that mean the variable doesn't get declared if the condition fails? If it gets declared, which will be its value? The types of statements that

<    1   2