Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Kevin Lundberg via swift-evolution]

I do like this to a point, but it ascribes special compiler behavior to 
specific argument labels which feels odd. If someone defined another operator 
function with a completely different argument label, would it just be ignored? 
If a developer makes a typo, that could be a subtle bug that may be confusing. 
Or should the compiler only allow those two argument labels for unary operator 
functions? That feels strange since it's not a restriction present anywhere 
else, and it starts to feel like the labels have a dual purpose that also falls 
into the realm of keywords.

Either option doesn't quite sit right with me, even though the lack of 
duplication that this solution has does look better, admittedly. 

--
Kevin Lundberg

On May 18, 2016, at 12:57 AM, Brent Royal-Gordon  wrote:

>> Additionally, I am generally +1 for the same reasons as Brent, but I
>> have another caveat as well:
>> 
>> Defining prefix and postfix functions looks like this in the proposal:
>> 
>> static prefix func ++(value: inout Self) -> Self
>> static postfix func ++(value: inout Self) -> Self
>> 
>> yet the proposal suggests calling them this way from these boilerplate
>> methods:
>> 
>> prefix func ++ (value: inout T) -> T {
>> return T.++(prefix: )
>> }
>> postfix func ++ (value: inout T) -> T {
>>   return T.++(postfix: )
>> }
> 
> I actually found this bizarre too, but forgot to mention it. My suggested 
> solution runs in the other direction: We should require that *all* unary 
> operator declarations and references use `prefix` or `postfix` as a parameter 
> label. Thus, the trampoline operators themselves would be written as:
> 
>func ++ (prefix value: inout T) -> T {
>return T.++(prefix: )
>}
>
>func ++ (postfix value: inout T) -> T {
>return T.++(postfix: )
>}
> 
> Not would be written as:
> 
>func ! (prefix value: B) -> Bool
> 
> While force-unwrap (if we had inout return values) would be written:
> 
>func ! (postfix value: inout Optional) -> inout T
> 
> `prefix` and `postfix` would be eliminated from the language as declaration 
> modifiers, except when declaring custom operators (which is already the Land 
> Of Ad-Hoc Syntax).
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Xiaodi Wu via swift-evolution]

I too have a little trouble with the suggested trampoline syntax:

>  static prefix func ++(value: inout Self) -> Self
>  static postfix func ++(value: inout Self) -> Self

I agree with Brent that the most appropriate way to write the trampoline
itself would be something more like:

```
static func ++ (prefix value: inout Self) -> Self
```

No particular need to eliminate declaration modifiers altogether quite yet
for the non-trampoline operators. The reasoning is this: a "prefix func" or
a "postfix func" would be used at the call site by actually prefixing or
postfixing the value. By contrast, the trampoline functions are called like
any other static member -- i.e. `T.++(prefix: foo)` -- and thus the
function itself is not really a "prefix func" or a "postfix func", just a
func with a parameter label.


On Tue, May 17, 2016 at 9:57 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > Additionally, I am generally +1 for the same reasons as Brent, but I
> > have another caveat as well:
> >
> > Defining prefix and postfix functions looks like this in the proposal:
> >
> >  static prefix func ++(value: inout Self) -> Self
> >  static postfix func ++(value: inout Self) -> Self
> >
> > yet the proposal suggests calling them this way from these boilerplate
> > methods:
> >
> > prefix func ++ (value: inout T) -> T {
> >  return T.++(prefix: )
> >  }
> > postfix func ++ (value: inout T) -> T {
> >return T.++(postfix: )
> >  }
>
> I actually found this bizarre too, but forgot to mention it. My suggested
> solution runs in the other direction: We should require that *all* unary
> operator declarations and references use `prefix` or `postfix` as a
> parameter label. Thus, the trampoline operators themselves would be written
> as:
>
> func ++ (prefix value: inout T) -> T {
> return T.++(prefix: )
> }
>
> func ++ (postfix value: inout T) -> T {
> return T.++(postfix: )
> }
>
> Not would be written as:
>
> func ! (prefix value: B) -> Bool
>
> While force-unwrap (if we had inout return values) would be written:
>
> func ! (postfix value: inout Optional) -> inout T
>
> `prefix` and `postfix` would be eliminated from the language as
> declaration modifiers, except when declaring custom operators (which is
> already the Land Of Ad-Hoc Syntax).
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Xiaodi Wu via swift-evolution]

Another +1 to Jacob's suggestion, and of course +1 to the intent of the
proposal itself.


On Tue, May 17, 2016 at 10:17 PM, Austin Zheng via swift-evolution <
swift-evolution@swift.org> wrote:

> I like Jacob's suggestion of "init(describing:)", and I also think the
> review team should consider the global function alternative. My main goal
> is also preventing silently incorrect code.
>
> Austin
>
> > On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I would still prefer a global function; because the output is from
> reflection, it’s really more for debugging purposes than actually
> serialising something.
> >
> > But any change to this gets a +1 from me. It’s too easy to accidentally
> call this instead of one of the other argument-less initialisers on String.
> >
> > Karl
> >
> >> On 18 May 2016, at 05:32, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hello Swift community,
> >>
> >> The review of "SE-0089: Renaming String.init(_: T)" begins now and
> runs through May 23. The proposal is available here:
> >>
> >>
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
> >>
> >> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >>
> >>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> or, if you would like to keep your feedback private, directly to the
> review manager.
> >>
> >> What goes into a review?
> >>
> >> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> >>
> >>  * What is your evaluation of the proposal?
> >>  * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >>  * Does this proposal fit well with the feel and direction of Swift?
> >>  * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >>  * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> >>
> >> More information about the Swift evolution process is available at
> >>
> >>  https://github.com/apple/swift-evolution/blob/master/process.md
> >>
> >> Thank you,
> >>
> >> -Chris Lattner
> >> Review Manager
> >>
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Austin Zheng via swift-evolution]

I like Jacob's suggestion of "init(describing:)", and I also think the review 
team should consider the global function alternative. My main goal is also 
preventing silently incorrect code.

Austin

> On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> I would still prefer a global function; because the output is from 
> reflection, it’s really more for debugging purposes than actually serialising 
> something.
> 
> But any change to this gets a +1 from me. It’s too easy to accidentally call 
> this instead of one of the other argument-less initialisers on String.
> 
> Karl
> 
>> On 18 May 2016, at 05:32, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
>> through May 23. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Karl Wagner via swift-evolution]

I would still prefer a global function; because the output is from reflection, 
it’s really more for debugging purposes than actually serialising something.

But any change to this gets a +1 from me. It’s too easy to accidentally call 
this instead of one of the other argument-less initialisers on String.

Karl

> On 18 May 2016, at 05:32, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
> through May 23. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

[Chris Lattner via swift-evolution]

> On May 17, 2016, at 9:14 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md
> 
> The proposal says this at the beginning:
> 
>> Swift's rule for attribues/keywords is that keywords usually modify type of 
>> variable; attributes do not.
> 
> [citation needed]
> 
> As far as I can tell, this is not true at all. Most declaration modifiers do 
> *not* change the type of anything; as far as I can tell, only `mutating`, 
> `nonmutating`, and possibly `optional` do. Meanwhile, several 
> attributes—particularly `@noescape` and `@autoclosure`—*do* change the type. 
> So where is this belief coming from?

Correct - the proposal is incorrect in this claim.  Swift's typical policy is 
that attributes do *not* modify the type of the declaration, which is why Swift 
1 and 2 have used “lazy” instead of “@lazy”.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Brent Royal-Gordon via swift-evolution]

> Additionally, I am generally +1 for the same reasons as Brent, but I
> have another caveat as well:
> 
> Defining prefix and postfix functions looks like this in the proposal:
> 
>  static prefix func ++(value: inout Self) -> Self
>  static postfix func ++(value: inout Self) -> Self
> 
> yet the proposal suggests calling them this way from these boilerplate
> methods:
> 
> prefix func ++ (value: inout T) -> T {
>  return T.++(prefix: )
>  }
> postfix func ++ (value: inout T) -> T {
>return T.++(postfix: )
>  }

I actually found this bizarre too, but forgot to mention it. My suggested 
solution runs in the other direction: We should require that *all* unary 
operator declarations and references use `prefix` or `postfix` as a parameter 
label. Thus, the trampoline operators themselves would be written as:

func ++ (prefix value: inout T) -> T {
return T.++(prefix: )
}

func ++ (postfix value: inout T) -> T {
return T.++(postfix: )
}

Not would be written as:

func ! (prefix value: B) -> Bool

While force-unwrap (if we had inout return values) would be written:

func ! (postfix value: inout Optional) -> inout T

`prefix` and `postfix` would be eliminated from the language as declaration 
modifiers, except when declaring custom operators (which is already the Land Of 
Ad-Hoc Syntax).

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

+1

-Thorsten 

> Am 16.05.2016 um 23:06 schrieb Joe Groff via swift-evolution 
> :
> 
> Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd 
> expect, but does lead to problems when an 'as' expression appears as part of 
> a comparison:
> 
>20 as Int64 < y as Int64 // error, '>' expected to close generic parameter 
> list Int64
> 
> Looking to the future, many people have also expressed interest in the 
> ability to do dynamic type checks against metatype values, not only static 
> types, as in:
> 
>class Base {}
>class DerivedA {}
>class DerivedB {}
> 
>var x: Base.Type = DerivedA
> 
>DerivedA() as? x // succeeds
>DerivedB() as? x // fails
>
> If we accept 
> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
>  dropping the '.self' requirement to refer to type objects, then I think we 
> should also change 'is' and 'as' to parse the expression grammar on their 
> right-hand side, leaving it up to the normal expression disambiguation rule 
> to handle angle brackets. This solves the '20 as Int64 < x' problem, and 
> prepares us to support dynamic is/as queries in the future. (To be clear, 
> designing dynamic queries should be its own discussion.) What do you all 
> think?
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

On Tue, May 17, 2016 at 1:25 PM, Matthew Johnson 
wrote:
>
>
>
>>
>>
>> Within the angle brackets are zero or more 'clauses'. Clauses are
>> separated by semicolons. (This is so commas can be used in where
>> constraints, below. Better ideas are welcome. Maybe it's not necessary; we
>> can use commas exclusively.)
>>
>>
>> I’m not a fan of the semicolon idea.  I don’t see any reason for this.
>> The `where` keyword separates the protocol list from the constraints just
>> fine.  The list on either side should be able to use commas with no problem
>> (or line breaks if that proposal goes through).
>>
>>
> I'm leaning towards getting rid of the commas, but would like to write out
> a few 'dummy' examples to see if there are any readability issues that
> arise.
>
>
> Replaced with what?  Whitespace separation?  I suppose that might work for
> the protocol list but it feels inconsistent with the rest of Swift.  Commas
> plus (hopefully) the alternative of newline seem like the right direction
> to me.
>

Sorry, I completely misspoke (mistyped?). I meant I want to get rid of the
semicolons and use commas. I've come to the conclusion that there are no
readability issues, protocol<> already uses commas, and semicolons used in
this manner don't have a precedent anywhere else in the language.


>
>
>> There are five different possible clauses:
>>
>>
>>- 'class'. Must be the first clause, if present. Places a constraint
>>on the existential to be any class type. (Implies: Only one can exist.
>>Mutually exclusive with class name clause.)
>>
>>
>> (In the future a follow-up proposal should add in 'struct' or 'value' as
>> a counterpart.)
>>
>>
>> If we’re going to allow `struct` we should also allow `enum`.  `value`
>> would allow either of those.
>>
>>
> Of course. A future proposal can allow list members to discuss the exact
> details as to how struct, value, or enum specifiers should work.
>
>
> Yep, agree.  Just mentioning that if we’re going to reference it we should
> not leave obvious holes in what would be considered.  :)
>

Absolutely.


>
>
>>
>>- Class name. Must be the first clause, if present. (Implies: Only
>>one can exist. Mutually exclusive with 'class'.) Places a constraint on 
>> the
>>existential (not really an existential anymore) to be an instance of the
>>class, or one of its subclasses.
>>
>> It is still be an existential if it includes protocol requirements that
>> the class does not fulfill.  For example, you might have Any> SomeProtocol> where UIView does not conform to SomeProtocol, but various
>> subclasses do.
>>
>>
> Fair enough. (I don't think the way things work would be affected.)
>
>
>> Your proposal doesn’t discuss composing Any in the way that Adrian’s did
>> like this:
>>
>> typealias Foo = Any
>> Any
>>
>
> I didn't think it needed to be discussed. An Any<...> existential type is
> a type 'expression' just like any other, and should be allowed to
> participate in other Any<...>s.
>
>
>
>>
>> I like the idea of composition as it allows us to factor out
>> constraints.  If we are going to do that we should allow a class to be
>> specified in the composition as long is it is a subclass of all class
>> requirements of Any types it composes.  For example, this should be allowed:
>>
>> typealias Bar = Any
>>
>> This is still one class requirement for Bar, it just refines the class
>> requirement of Foo to be SubclassOfSomeClass rather than just SomeClass.
>>
>
> This is a good point. There should be clarification as to how special
> cases of Any<...> used in another Any<...> behave. For example, like you
> said Any> should be valid.
> This will go into any proposal that emerges from the discussion.
>
>
> Yes, this is why we need to discuss Any composition.  There are also cases
> of incompatible associated type constraints which need to be rejected (such
> as composing two Any’s where one has Element == String and another has
> Element == Int).
>

>
>
>>
>> Example: Any
>> "Any UIViewController or subclass which also satisfies the table view
>> data source and delegate protocols"
>>
>>- Dynamic protocol. This is entirely composed of the name of a
>>protocol which has no associated types or Self requirement.
>>
>> Example: Any
>> "Any type which conforms to both the CustomStringConvertible and
>> BooleanType protocols"
>>
>> I'm going to use 'static protocol' to refer to a protocol with associated
>> types or self requirements. Feel free to propose a more sound name.
>>
>>
>>- Self-contained static protocol, simple. This is composed of the
>>name of a static protocol, optionally followed by a 'where' clause in 
>> which
>>the associated types can be constrained 

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I think this is a good and long-needed change.

I also think that the matching protocols should be renamed to correspond to the 
initializers used to invoke them: CustomStringConvertible should become 
PrintingStringConvertible, and CustomDebugStringConvertible should become 
ReflectingStringConvertible. (The suffixes may change depending on SE-0041, of 
course.)

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. I've always found it rather disturbing and bizarre that you could make a 
String out of anything and get a random, possibly unintended result. 
`String.init(printing:)` makes this more intentional, which is definitely a 
good thing.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes. We're all about being explicit, right?

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I much prefer Swift's solution of using an initializer to other languages' use 
of `to_s` or `toString()` methods.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Kevin Lundberg via swift-evolution]

On 5/18/2016 12:03 AM, Brent Royal-Gordon via swift-evolution wrote:
> I'm in favor, with one small concern:
>
>> Then, the protocol author is responsible for providing a generic global 
>> trampoline operator that is constrained by the protocol type and delegates 
>> to the static operator on that type:
>>
>>  func == (lhs: T, rhs: T) -> Bool {
>>return T.==(lhs, rhs)
>>  }
> This trampoline operator, and all of the others in the proposal, appears to 
> be 100% pure boilerplate. Could Swift generate them for us?
>
> (Specifically, I'm suggesting that if protocol P defines a `static func 
> $!(args) -> ret`, Swift should automatically generate a global `func #!  P> (args) -> ret`, substituting `T` for any `Self`s among the parameters or 
> return values.)
>
I was just about to respond to this proposal with the same feedback.
This code is purely mechanical and could be written wrong by a protocol
author.

Additionally, I am generally +1 for the same reasons as Brent, but I
have another caveat as well:

Defining prefix and postfix functions looks like this in the proposal:

  static prefix func ++(value: inout Self) -> Self
  static postfix func ++(value: inout Self) -> Self

yet the proposal suggests calling them this way from these boilerplate
methods:

prefix func ++ (value: inout T) -> T {
  return T.++(prefix: )
  }
postfix func ++ (value: inout T) -> T {
return T.++(postfix: )
  }

Having this mismatch between argument labels at the declaration and call
site feels strange to me, and it is inconsistent with how function
argument labels work everywhere else in the language. What if the prefix
and postfix keywords also required the functions to be disambiguated
somehow in a way that the current method naming scheme allows?

  static prefix func ++(prefix value: inout Self) -> Self
  static postfix func ++(postfix value: inout Self) -> Self

This will give a clear signal for callers to know how they should call
the function by looking at the declaration, instead of relying on a
weird edge case for these kind of operator functions. `prefix` and
`postfix` don't necessarily need to be the actual names of the arguments
that are forced by the compiler, but they should be required to be
different in the same way that you can't re-declare the same identical
function signature any other time (aside from current global
prefix/postfix functions of course).

- Kevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Brent Royal-Gordon via swift-evolution]

> UPDATED APPROACH
> 
> Our updated approach focuses on the two most important conventions: one for 
> initialization and one for representation.
> 
> 1. `Initializable`
> 
> `Initializable` designates protocols that convert *from* a type or from an 
> associated type mentioned in the protocol name, such as the current 
> `LiteralConvertible` protocols.  This convention would include member 
> requirements for initializers, factory methods, and any other way an instance 
> can be imported to establish a new instance of the conforming type.
> 
> For example, conforming to `ArrayLiteralInitializable` would allow a set to 
> be created with `Set(arrayLiteral: )` and `var set: Set = []`.
> 
> This phrase replaces the `Creatable` form from our original proposal.
> 
> 2. `Representable`
> 
> `Representable` designates protocols whose primary purpose is to project *to* 
> a type or associated type mentioned in the protocol name.  Items in the 
> standard library that would be subsumed into this naming include 
> `CustomStringConvertible`, `CustomDebugStringConvertible`, and 
> `RawRepresentable`, which we imagine would become 
> `CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as 
> current) `RawRepresentable`.
> 
> This second category groups together the `Convertible` and `Representable` 
> categories from our original proposal and is predicated on the feedback from 
> the design team review. The `Representable` designation does not promise 
> bidirectional conversion although some `Representable` protocols may include 
> requirements to allow attempted initialization *from* the type of the 
> representation. Doing so falls outside the naming contract we are proposing. 

If we're doing this, I wonder if category 1 shouldn't just be `Convertible`. 
This would preserve our `LiteralConvertible` protocols with the same names 
(which, consistency issues aside, seem perfectly cromulent), while shifting the 
`StringConvertible` protocols over to the `Representable` category.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Robert Widmann via swift-evolution]

+1 (replying here because I can't find the root and I agree with this 
evaluation).

~Robert Widmann

2016/05/17 22:07、Trent Nadeau via swift-evolution  
のメッセージ:

> * What is your evaluation of the proposal?
> +1. A very simple API change that fixes a footgun in the standard library.
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> Yes.
> * Does this proposal fit well with the feel and direction of Swift?
> Yes.
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> N/A
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> I followed the original thread and read the proposal.
> 
>> On Tue, May 17, 2016 at 11:32 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> Hello Swift community,
>> 
>> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
>> through May 23. The proposal is available here:
>> 
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a 
>> change to Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

[Robert Widmann via swift-evolution]

+1.  A lot of (mostly functional) languages that need to disambiguate type 
constructors from terms enforce this as a requirement to great effect.

~Robert Widmann

2016/05/17 21:56、T.J. Usiyan via swift-evolution  
のメッセージ:

> Could we reconsider rejecting the uppercase and lowercase conventions as a 
> syntactic requirement? While I still disagree with enum cases not being 
> UpperCamelCase, that decision narrows the 'approved' enough that the 
> syntactic requirement would line up with guidance. It would also make 
> teaching the conventions much easier. New students who, for whatever reason, 
> prefer naming variables with upper camel case would have immediate and 
> concrete feedback from the dev tools that that is non-idiomatic. 
> 
> 
> If that is a non starter, let me try another. Was a disambiguating token 
> preceding the type reference considered? 
> 
>> On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> Hello Swift community,
>> 
>> The review of "SE-0090: Remove .self and freely allow type references in 
>> expressions" begins now and runs through May 23. The proposal is available 
>> here:
>> 
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a 
>> change to Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[T.J. Usiyan via swift-evolution]

+1
converting to a string is definitely lossy for most cases.

On Wed, May 18, 2016 at 12:09 AM, Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> * What is your evaluation of the proposal?
>>
>
> +1, because:
>   - I believe the default/generic "printing" initializer is not commonly
> used (at least, not on purpose).
>   - The new argument label clearly indicates what the initializer does.
>
> I would also submit for consideration "*init(describing:)*", to match the
> CustomStringConvertible ".description" property which it invokes.
>
>
>> * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>
> Yes: accidental use of the initializer can be harmful, and is currently
> very easy.
>
>
>> * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>
> Yes, it fits well with the API guidelines.
>
>
>> * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>>
> N/A
>
>
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>
> A quick reading.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

[T.J. Usiyan via swift-evolution]

+1
'default' alone makes this worth it.

On Tue, Apr 26, 2016 at 5:28 PM, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
> I think it's a good thing. I don't think that it would introduce any bad
> ambiguities for the human reader. E.g. "case .default:" may look like
> "default:", but so does "case .`default`:" - all other cases that I can
> think of don't seem to introduce any problems.
>
> > Am 26.04.2016 um 06:20 schrieb Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Hello Swift community,
> >
> > The review of "Allow (most) keywords in member references" begins now
> and runs through April 29th. The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at:
> >
> >   https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
> >
> >   * What is your evaluation of the proposal?
> >   * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >   * Does this proposal fit well with the feel and direction of Swift?
> >   * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >   * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >   https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

[Brent Royal-Gordon via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md

The proposal says this at the beginning:

> Swift's rule for attribues/keywords is that keywords usually modify type of 
> variable; attributes do not.

[citation needed]

As far as I can tell, this is not true at all. Most declaration modifiers do 
*not* change the type of anything; as far as I can tell, only `mutating`, 
`nonmutating`, and possibly `optional` do. Meanwhile, several 
attributes—particularly `@noescape` and `@autoclosure`—*do* change the type. So 
where is this belief coming from?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[T.J. Usiyan via swift-evolution]

I've been thinking about the "conversion to some other type from this
protocol" case for a while since it often seems to go against the guidance
to add a property for this conversion. `Convertible` is always an awkward
Protocol to write, in my opinion.

Is there a chance that we simplify the the `Convertible` case by adding
this syntax to protocols

``` swift

protocol CustomStringConvertible {
String.init(customStringFrom:)
}

```

or something similar? I admit that it *is* unwieldy to declare that String
has an initializer in a protocol *but* we almost always end up writing an
initializer which accepts our protocol and calls the 'constructor property'
we've required in the protocol. This removes that indirection (also
removing the strange two-ways-in-our-API-to-convert-this-to-that) and,
maybe, avoids some overloading.

On Mon, May 16, 2016 at 10:33 AM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, May 10, 2016 at 11:48 AM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of "SE-0041: Updating Protocol Naming Conventions for
>> Conversions" begins now and runs through May 16. The proposal is available
>> here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> review manager.
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to the direction of Swift.
>> When writing your review, here are some questions you might want to answer
>> in your review:
>>
>> * What is your evaluation of the proposal?
>>
>
> +1 with the newly proposed Initializable/Representable names.
> Initializable just fits perfectly with the fact that Swift has things
> called initializers and is a vast improvement over Creatable. Representable
> to denote the other direction makes sense compared to existing Cocoa APIs
> that use *Representation in their name.
>
>
>> * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>
> Yes. Many developers use stdlib as guidance when designing their own APIs
> and having the standard library be internally consistent sets a good
> example. These recommendations should also be hoisted into the API naming
> guidelines documentation so that people can easily cite it, as opposed to
> just saying "note the pattern that exists" (this is helpful when writing
> team-specific style guides and for enforcing conventions in code reviews).
>
>
>> * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>
> Yes, it makes the language more consistent.
>
>
>> * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>>
>
> None that handle conversions in this way using protocols.
>
>
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>
> I read the proposal, the message with the updated names afterwards, and
> loosely followed the e-mail threads.
>
>
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Chris Lattner
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Jacob Bandes-Storch via swift-evolution]

>
> * What is your evaluation of the proposal?
>

+1, because:
  - I believe the default/generic "printing" initializer is not commonly
used (at least, not on purpose).
  - The new argument label clearly indicates what the initializer does.

I would also submit for consideration "*init(describing:)*", to match the
CustomStringConvertible ".description" property which it invokes.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes: accidental use of the initializer can be harmful, and is currently
very easy.


> * Does this proposal fit well with the feel and direction of Swift?
>

Yes, it fits well with the API guidelines.


> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
N/A


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1. A very simple API change that fixes a footgun in the standard library.
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes.
* Does this proposal fit well with the feel and direction of Swift?
Yes.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
N/A
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I followed the original thread and read the proposal.

On Tue, May 17, 2016 at 11:32 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs
> through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

[Brent Royal-Gordon via swift-evolution]

> The review of "SE-0091: Improving operator requirements in protocols" begins 
> now and runs through May 23. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md

>   * What is your evaluation of the proposal?

I'm in favor, with one small concern:

> Then, the protocol author is responsible for providing a generic global 
> trampoline operator that is constrained by the protocol type and delegates to 
> the static operator on that type:
> 
>   func == (lhs: T, rhs: T) -> Bool {
> return T.==(lhs, rhs)
>   }

This trampoline operator, and all of the others in the proposal, appears to be 
100% pure boilerplate. Could Swift generate them for us?

(Specifically, I'm suggesting that if protocol P defines a `static func 
$!(args) -> ret`, Swift should automatically generate a global `func #!  
(args) -> ret`, substituting `T` for any `Self`s among the parameters or return 
values.)

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. Speeding up type inference is a Good Thing™.

>   * Does this proposal fit well with the feel and direction of Swift?

It *is* a little odd and hacky, particularly on the class side. I'm not saying 
it's any worse than the status quo, but it doesn't feel like a full solution 
yet.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Short of Perl 6's solution, which is to introduce full multimethods into the 
language, I don't think I've seen much that's better. (Other than the 
trampoline boilerplate, that is.)

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. It's more consistent, both with the rules for keywords vs. attributes
and with future improvements with property behaviors, as mentioned in the
proposal.
* Does this proposal fit well with the feel and direction of Swift?
Yes
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
"Wrapper" behaviors like this have been attributes in other languages I've
used, like Java.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal.

On Tue, May 17, 2016 at 11:31 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0087: Rename lazy to @lazy" begins now and runs through
> May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

[Trent Nadeau via swift-evolution]

* What is your evaluation of the proposal?
+1. Although I would prefer something like:

precedence(greaterThan: LogicalAnd)

to:

precedence(> LogicalAnd)

I think the latter is more difficult to read, and I just find the idea of
using an operator in an operator/precendencegroup definition strange.

* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
* Does this proposal fit well with the feel and direction of Swift?
Yes. Magical numbers are definitely not used elsewhere in the language.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
N/A
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal

On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0077: Improved operator declarations" begins now and
> runs through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

[T.J. Usiyan via swift-evolution]

Could we reconsider rejecting the uppercase and lowercase conventions as a
syntactic requirement? While I still disagree with enum cases not being
UpperCamelCase, that decision narrows the 'approved' enough that the
syntactic requirement would line up with guidance. It would also make
teaching the conventions much easier. New students who, for whatever
reason, prefer naming variables with upper camel case would have immediate
and concrete feedback from the dev tools that that is non-idiomatic.


If that is a non starter, let me try another. Was a disambiguating token
preceding the type reference considered?

On Tue, May 17, 2016 at 11:33 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0090: Remove .self and freely allow type references in
> expressions" begins now and runs through May 23. The proposal is available
> here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

[T.J. Usiyan via swift-evolution]

* What is your evaluation of the proposal?
+1
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. Definitely. Operator overloading is currently fine in only the
simplest of cases.
* Does this proposal fit well with the feel and direction of Swift?
I think so, yes.
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
No
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I followed the original thread and have been wrangling precedence for a
while now.



One problem that I have encountered with operators that I think still needs
solving is operators from different libraries colliding with regard to
precedence.

`^` is the example that bit me most recently. Swift has one with left
fixity at 160. I wanted to overload it with right fixity for math
operators. The only way that I have thought involves
- precedence groups are tied to a module
- overloads in modules are tied to specific precedence groups.

I have *not a clue* about how feasible this solution is, but it would allow
greater flexibility and, at least in my opinion, more understandable
behavior. Attempting to overload `^` right now, especially with right
fixity, results in confusing behavior.




On Tue, May 17, 2016 at 11:30 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0077: Improved operator declarations" begins now and
> runs through May 23. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0091: Improving operator requirements in protocols" begins 
now and runs through May 23. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0090: Remove .self and freely allow type references in 
expressions" begins now and runs through May 23. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
through May 23. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0087: Rename lazy to @lazy

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 
23. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0077: Improved operator declarations

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0077: Improved operator declarations" begins now and runs 
through May 23. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0050: Decoupling Floating Point Strides from Generic Implementations

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0050: Decoupling Floating Point Strides from Generic 
Implementations" begins now and runs through May 23. The proposal is available 
here:


https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to the direction of Swift. When writing 
your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for coding styles and "swift-format" tool

[Jacob Bandes-Storch via swift-evolution]

It would be awesome if Xcode exposed per-file or per-project formatting
settings, and could enforce them in the editor. I hope someone from the dev
tools group will be able to comment (and help guide the implementation of
this) if there are plans for such a feature.

Jacob

On Tue, May 17, 2016 at 7:17 PM, Shawn Erickson via swift-evolution <
swift-evolution@swift.org> wrote:

> I would love to see flexible formatting styles be more easily available
> like this.
>
> -Shawn
>
> On Tue, May 17, 2016 at 10:33 AM Daniel Martín 
> wrote:
>
>> As Swift is getting traction in more and more platforms outside of
>> Apple, we can expect that many coding styles different from what Apple
>> imposes with SourceKit's indenting rules will emerge. According to
>> https://bugs.swift.org/browse/SR-146, we now have decoupled indenting
>> logic from SourceKit into its own library, and a "swift-format" tool is
>> in the making.
>>
>> I am working on adding support for different coding styles to libIDE.
>> For example, with my changes you could decide how a case label should be
>> indented with respect to its parent switch context, among other things.
>> The current, hard coded indenting decisions in libIDE could be named the
>> "Apple" style, just like Clang supports Google, LLVM, Mozilla, coding
>> styles for C++. Also, this is something that can be supported by
>> external tools like Xcode quite easily.
>>
>> Do you think this is a good feature to have?
>>
>> --
>> Daniel Martín
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Support for coding styles and "swift-format" tool

[Shawn Erickson via swift-evolution]

I would love to see flexible formatting styles be more easily available
like this.

-Shawn

On Tue, May 17, 2016 at 10:33 AM Daniel Martín 
wrote:

> As Swift is getting traction in more and more platforms outside of
> Apple, we can expect that many coding styles different from what Apple
> imposes with SourceKit's indenting rules will emerge. According to
> https://bugs.swift.org/browse/SR-146, we now have decoupled indenting
> logic from SourceKit into its own library, and a "swift-format" tool is
> in the making.
>
> I am working on adding support for different coding styles to libIDE.
> For example, with my changes you could decide how a case label should be
> indented with respect to its parent switch context, among other things.
> The current, hard coded indenting decisions in libIDE could be named the
> "Apple" style, just like Clang supports Google, LLVM, Mozilla, coding
> styles for C++. Also, this is something that can be supported by
> external tools like Xcode quite easily.
>
> Do you think this is a good feature to have?
>
> --
> Daniel Martín
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution 
>  wrote:
> 
> So I don’t mind (too much) if it takes longer to get a stable ABI. It
> makes my life harder, but on the flip-side, I don’t want to be stuck
> with yet another broken language and ABI. I want this done right
> because it will be almost impossible to fix later.
> 
> Here’s a simple, yet tragic example: BOOL in Objective-C. We were
> stuck with signed char instead of getting a real boolean. Back in 10.4
> Tiger when the Intel migration was announced, I filed a bug report
> reminding them that this was the chance to fix this. They didn’t fix
> it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
> frame during the 64-bit transition, I filed again reminding them that
> this should be fixed before the 64-bit ABI gets locked down. Again, it
> wasn’t fixed so we were stuck. Then when the iOS SDK was going to
> become public, I filed again. Still not fixed. Then armv7, still
> nothing. Finally, for arm64, this was finally fixed. Too bad we’re
> stuck on Mac with this probably forever.

We apologize for the inconvenience.

The OS X and iOS architecture transitions demonstrate the two fundamental laws 
of ABI changes:
1. Opportunities to break ABI compatibility are rare.
2. Any opportunity to break ABI compatibility will suffer from severe schedule 
pressure.

The Objective-C ABIs have many problems that would have been improved with more 
time.
* We tried to get a "modern" ABI into i386, but the schedule was too tight and 
we lost time with some initial design ideas that didn't pan out. x86_64 was 
also a tight schedule, but much of the work was already in place from the i386 
attempt so we were able to get it done.
* Fixing BOOL was repeatedly not quite high enough priority. 
* The 64-bit metadata structures have at least one field that is 64-bit by 
accident (protocol_list_t.count). There was miscommunication between the 
compiler and the runtime when the design was specified, and then it was never 
high enough priority to coordinate a fix later.
* armv7 uses setjmp-longjmp exceptions instead of "zero-cost" exceptions 
because that's what GCC's arm compiler used then and we didn't have time to 
change it.
* The very first iPhone did not use a "modern" ABI. We knew we could break ABI 
compatibility at any time before 3rd party apps were supported, so we punted 
ABI modernization until after 1.0.
* Non-fragile ivars on iPhone had a fragility bug in the compiler. (You don't 
see non-fragile ivars doing their thing until the *second* release, except for 
deliberate testing. We didn't test enough.) Luckily the bad case was narrow and 
the miscompiled code was detectable by inspecting binaries in the App Store, so 
we were able to ask all of the affected apps to recompile with a fixed compiler 
before the next iPhoneOS version shipped.

If we tried to rush Swift ABI stability out the door for Swift 3 we would 
certainly end up with deliberate or accidental flaws like the above. Being able 
to take the time to get it right is a rare luxury.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Nate Cook  wrote:

>>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Mon May 09 2016, Nate Cook  wrote:
>>> 
>>> Yet another alternative would be to drop Set and Dictionary down a
>>> level to a FiniteSequence protocol in between Sequence and
>>> Collection. Basically none of the index-based collection APIs
>>> (i.e. everything except `count` and `isEmpty`) make sense on sets and
>>> dictionaries.
>> 
>> Strongly disagreed.  Any read-only operation that makes sense on a
>> bidirectional collection makes sense on these data structures.
>
> I don't see how the methods that impose meaning on the order of a set
> are useful. What does mySet.prefix(upTo: i) mean when I have no
> control or dependable way of knowing which elements lie between
> startIndex and i? mySet.first is useful, but it's meaning is more like
> NSSet's anyObject.

If you want to process the elements of your set in parallel, you want to
break it down into equally-sized regions and distribute the work across
cores.  That's indexing and slicing.

>>> index(where:) was marginally useful with dictionaries, but now that
>>> Sequence is getting first(where:), née find(...), even that isn't
>>> necessary.
>> 
>>   s.remove(at: s.index(where: { $0 < 1 }))
>
> Since Set's remove(at:) method is type-specific, it would need to be
> rewritten as remove(where:). 

That would mean “remove all elements satisfying this predicate,” to me.

> This example is kind of my point, though - it removes the first
> element less than 1, but only one such element, and there's no telling
> which. That's not an operation I've ever needed to perform on a set.
>
> To clarify, I don't think the current system is hurting Set and
> Dictionary in any way. It's simply providing them with methods that
> aren't very useful for that particular data structure.

I agree that because of Set's nature, some Collection algorithms are
less-applicable than they would otherwise be.  Does that mean Set isn't
fundamentally a Collection?  No it does not.  A Collection is a
multipass sequence with a representation of position.  Set definitely
has those properties.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

That's exactly my point, Sean.

- Leonardo

On 17 May 2016 at 20:31, Sean Heber  wrote:

> Cavet: I have not been following this, so probably someone has said this
> somewhere and flaws were pointed out.
>
> I don’t really understand the need for union types when you can have
> multiple methods of the same name that differ only by the type of their
> parameter:
>
> func something(value: A) {}
> func something(value: B) {}
> func something(value: C) {}
>
> Doesn’t this more or less accomplish the same thing without needing 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
>
>
>
> > On May 17, 2016, at 6:09 PM, Leonardo Pessoa via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > 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 following constructions:
> >
> > func something(value: None) -> None { ... }
> >
> > It wouldn't be essentially wrong but unnecessary since nil would be the
> only possible value of the type None. And I don't really see any need to
> change the way optionals are implemented to support unions. And we could
> still have optional unions using either syntax with existing optional
> syntax (which is very clear to me):
> >
> > func something(value: (A | B | C)?) { ... }
> >
> > or
> >
> > func something(value: union?) { ... }
> >
> > Just as I said before, I don't really think unions are necessary (did
> you mean overloading?) but I don't oppose them. I just don't think we need
> to change the way a feature already works to justify the addition of a new
> feature.
> >
> >
> > - Leonardo
> >
> > On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Union is far better then generic enum/protocol solution.
> > * It can extend the original enum and make it powerful.
> >
> > enum ResultDataType {
> > case Music
> > case Video
> > case File
> > }
> >
> > enum FailureType {
> > case HTTP404
> > case HTTP502
> > }
> >
> > enum FailureTypev2 {
> > case HTTP451
> > }
> >
> > typealias Result = (ResultDataType | FailureType | FailureTypev2)
> >
> >   * It keeps the code clear and does not need developer to announce
> some unnecessary protocols or enums.
> >   like UnionOf3 or ProtocolForABC
> >
> > * It is easy to wrap original value into an union type.
> >   let a = A()
> >   let union: (A|B|C) = a // Automatically wrap.
> >
> >   * Compiler might search their common properties, and methods, then
> mark them as a member of the union type.
> >   print(value.someCommonProperty) // Compiler will know
> their common properties automatically.
> >
> >
> >   * Compiler know the union type exactly composed with which types,
> better than only know which protocol.
> >   func input(value: ProtocolForABC) {
> >   if value is A {
> >
> >   } else if value is B {
> >
> >   } else if value is C {
> >
> >   } else {
> >   // There are other cases? Compiler doesn't know
> >   }
> >   }
> >
> > * Original types and union types can have a rational
> relationship between each other.
> >Original type is a sub-type of union types contain it.
> >
> >   var fn0: A->Void = {print(v0)}
> >   var fn1: (A|B)->Void = {print(v0)}
> >
> >   fn0 = fn1 // Original Type and Union Type has a sub-typing
> relationship, OK
> >
> >   var fn2: (A|B|C)->Void = {print($0)}
> >
> >   fn0 = fn2 // OK
> >   fn1 = fn2 // OK
> >
> >
> > * It is also easy to compare with value of original type.
> >   union == a // Can be compared, Yes for most cases.
> >
> >   * And the most important part, It can replace Optional.
> >   let string: String?
> >   is same to
> >   let string: (String | None)  instead of let string:
> Optional
> >
> >
> > I really think the union type is a good supplement for Swift. Make the
> language rational.
> > And the It is also really good for Reactive Programming.
> >
> > - Jiannan
> >
> >> 下面是被转发的邮件：
> >>
> >> 发件人: Haravikk 
> >> 主题: 回复： [swift-evolution] Union instead of Optional
> >> 日期: 2016年5月16日 GMT+8 18:35:25
> >> 收件人: Austin Zheng 
> >> 抄送: Cao Jiannan , Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>
> >>
> >>
> >>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <
> 

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Dave Abrahams via swift-evolution]

on Fri May 13 2016, Joe Groff  wrote:

>> On May 13, 2016, at 7:30 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Mon May 09 2016, Joe Groff  wrote:
>> 
>
 On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
> * Operations that depend on sorted-ness and use binary predicates should
> not be available on all Collections; they're too easy to misuse,
> they're hard to name well, and as Nicola Salmoria has noted, they
>>> 
> would not make any sense at all for a Set.
> 
> * They should be scoped to a kind of collection that bundles
> the predicate with the elements, e.g.
> 
>  let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of 
> the array
>  let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
> 
> Maybe there should also be protocols for this; CountableRange would
> already already conform to the immutable version.  We might want a
> mutable form of the protocol for sorted collections with
> insertion/removal methods.  This whole area needs more design.
 
 I agree with both of these statements, but not with your conclusion.
 
 There are three classes of collections:
 
 1) Those which are always sorted, like a SortedSet.
 2) Those which may or may not be sorted, like an Array.
 3) Those which are never sorted, like a Set.
 
 These APIs are useless on a #3, but #2 is still a valuable use case
 to support. In particular, it's quite common to use sorted `Array`s,
 and these APIs would help you do that.
 
 What I might consider doing is tying this to
 `RangeReplaceableCollection`. That protocol is applied only to types
 which allow insertion at arbitrary indices, which is a good, though
 not perfect, proxy for types which might allow you to manually
 maintain a sort order. `Array`, `ArraySlice`, `ContiguousArray`, and
 the mutable `String` views would get these methods, while `Set` and
 `Dictionary` would not.
>>> 
>>> We could also introduce a new OrderedCollection protocol. (This would
>>> also be useful in the future for supporting `case` pattern matching on
>>> collections. It makes sense to pattern-match arrays and other ordered
>>> collections in order by element, but you'd expect very different
>>> semantics pattern-matching an unordered Set.)
>> 
>> What do you mean by “Ordered” here?  Please note that when Cocoa uses
>> “Ordered” it means something very different from “Sorted.”  I don't find
>> the Cocoa usage intuitive myself, but it might be best to avoid that
>> term to avoid confusion.
>
> By "ordered", I only mean "ordering is significant to the value of the
> collection", so Array is ordered but Set is not.

That does not strike me as a useful-enough distinction to be worth
enshrining in a protocol.  What generic components would be constrained
on it?

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

Cavet: I have not been following this, so probably someone has said this 
somewhere and flaws were pointed out.

I don’t really understand the need for union types when you can have multiple 
methods of the same name that differ only by the type of their parameter:

func something(value: A) {}
func something(value: B) {}
func something(value: C) {}

Doesn’t this more or less accomplish the same thing without needing 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



> On May 17, 2016, at 6:09 PM, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
> 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 following 
> constructions:
> 
> func something(value: None) -> None { ... }
> 
> It wouldn't be essentially wrong but unnecessary since nil would be the only 
> possible value of the type None. And I don't really see any need to change 
> the way optionals are implemented to support unions. And we could still have 
> optional unions using either syntax with existing optional syntax (which is 
> very clear to me):
> 
> func something(value: (A | B | C)?) { ... }
> 
> or
> 
> func something(value: union?) { ... }
> 
> Just as I said before, I don't really think unions are necessary (did you 
> mean overloading?) but I don't oppose them. I just don't think we need to 
> change the way a feature already works to justify the addition of a new 
> feature.
> 
> 
> - Leonardo
> 
> On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution 
>  wrote:
> Union is far better then generic enum/protocol solution.
> * It can extend the original enum and make it powerful.
>   
> enum ResultDataType {
> case Music
> case Video
> case File
> }
> 
> enum FailureType {
> case HTTP404
> case HTTP502
> }
> 
> enum FailureTypev2 {
> case HTTP451
> }
> 
> typealias Result = (ResultDataType | FailureType | FailureTypev2)
> 
>   * It keeps the code clear and does not need developer to announce some 
> unnecessary protocols or enums.
>   like UnionOf3 or ProtocolForABC
> 
> * It is easy to wrap original value into an union type.
>   let a = A()
>   let union: (A|B|C) = a // Automatically wrap.
> 
>   * Compiler might search their common properties, and methods, then mark 
> them as a member of the union type.
>   print(value.someCommonProperty) // Compiler will know their 
> common properties automatically.
> 
> 
>   * Compiler know the union type exactly composed with which types, 
> better than only know which protocol.
>   func input(value: ProtocolForABC) {
>   if value is A {
> 
>   } else if value is B {
> 
>   } else if value is C {
> 
>   } else {
>   // There are other cases? Compiler doesn't know
>   }
>   }
> 
> * Original types and union types can have a rational relationship 
> between each other. 
>Original type is a sub-type of union types contain it.
> 
>   var fn0: A->Void = {print(v0)}
>   var fn1: (A|B)->Void = {print(v0)}
> 
>   fn0 = fn1 // Original Type and Union Type has a sub-typing 
> relationship, OK
> 
>   var fn2: (A|B|C)->Void = {print($0)}
> 
>   fn0 = fn2 // OK
>   fn1 = fn2 // OK
> 
> 
> * It is also easy to compare with value of original type.
>   union == a // Can be compared, Yes for most cases.
> 
>   * And the most important part, It can replace Optional.
>   let string: String?
>   is same to 
>   let string: (String | None)  instead of let string: 
> Optional
>   
> 
> I really think the union type is a good supplement for Swift. Make the 
> language rational.
> And the It is also really good for Reactive Programming.   
> 
> - Jiannan  
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: Haravikk 
>> 主题: 回复： [swift-evolution] Union instead of Optional
>> 日期: 2016年5月16日 GMT+8 18:35:25
>> 收件人: Austin Zheng 
>> 抄送: Cao Jiannan , Adrian Zubarev via swift-evolution 
>> 
>> 
>> 
>>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution 
>>>  wrote:
>>> 
>>> If A, B, and C are not related via protocol or class inheritance, then 
>>> there is almost nothing you can do with value. Otherwise you still need to 
>>> test against the concrete 

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Dave Abrahams via swift-evolution]

on Tue May 10 2016, Joe Groff  wrote:

>> On May 6, 2016, at 3:16 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and
>> myself.
>
>> 
>> on Tue May 03 2016, Chris Lattner  wrote:
>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0074: Implementation of Binary Search functions"
>>> begins now and runs through May 9. The proposal is available here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All
>>> reviews should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review
>>> through constructive criticism and contribute to the direction of
>>> Swift. When writing your review, here are some questions you might
>>> want to answer in your review:
>>> 
>>> * What is your evaluation of the proposal?
>> 
>> We think binary searches are fundamental and important, and want to see
>> them added.  However, we don't agree with the form of the current
>> proposal.  In particular, we think:
>> 
>> * Operations that depend on sorted-ness and use binary predicates should
>>  not be available on all Collections; they're too easy to misuse,
>>  they're hard to name well, and as Nicola Salmoria has noted, they
>>  would not make any sense at all for a Set.
>> 
>> * They should be scoped to a kind of collection that bundles
>>  the predicate with the elements, e.g.
>> 
>>let x = Sorted([3, 4, 1, 5, 2], >)  // stores a sorted copy of 
>> the array
>>let y = Sorted(preSorted: 0..<100, <)  // stores a copy of the range
>> 
>>  Maybe there should also be protocols for this; CountableRange would
>>  already already conform to the immutable version.  We might want a
>>  mutable form of the protocol for sorted collections with
>>  insertion/removal methods.  This whole area needs more design.
>
> I worry that attaching these methods to a strongly-typed `Sorted`
> wrapper limits their appeal. It's useful to be able to binary-search
> through data in a standard container that's known to be sorted, or
> over a subregion of the data that's sorted. While you can of course
> cobble together a Sorted(Slice(container[sortedRange])), that's pretty
> inconvenient. Is misapplying binary search algorithms to unsorted data
> a big problem in practice in C++?

No, but:

1. Algorithms on collections in C++ are not methods that you'd find by
   code completion.

2. We have stronger naming conventions than C++ does, such that we're
   inclined to stick the word “sorted” into the names of all the
   algorithms that have a sortedness precondition.  There are a few of
   them; e.g. don't forget unique().  The resulting design gets pretty ugly.

3. The idea of a collection that maintains its sorted order is a
   powerful one that has been useful in practice

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

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 following constructions:

func something(value: None) -> None { ... }

It wouldn't be essentially wrong but unnecessary since nil would be the
only possible value of the type None. And I don't really see any need to
change the way optionals are implemented to support unions. And we could
still have optional unions using either syntax with existing optional
syntax (which is very clear to me):

func something(value: (A | B | C)?) { ... }

or

func something(value: union?) { ... }

Just as I said before, I don't really think unions are necessary (did you
mean overloading?) but I don't oppose them. I just don't think we need to
change the way a feature already works to justify the addition of a new
feature.


- Leonardo

On 16 May 2016 at 08:26, Cao Jiannan via swift-evolution <
swift-evolution@swift.org> wrote:

> Union is far better then generic enum/protocol solution.
> * It can extend the original enum and make it powerful.
> enum ResultDataType {
> case Music
> case Video
> case File
> }
>
> enum FailureType {
> case HTTP404
> case HTTP502
> }
>
> enum FailureTypev2 {
> case HTTP451
> }
>
> typealias Result = (ResultDataType | FailureType | FailureTypev2)
>
> * It keeps the code clear and does not need developer to announce some
> unnecessary protocols or enums.
> like UnionOf3 or ProtocolForABC
>
> * It is easy to wrap original value into an union type.
> let a = A()
> let union: (A|B|C) = a // Automatically wrap.
>
> * Compiler might search their common properties, and methods, then mark
> them as a member of the union type.
> print(value.someCommonProperty) // Compiler will know their common
> properties automatically.
>
>
> * Compiler know the union type exactly composed with which types, better
> than only know which protocol.
> func input(value: ProtocolForABC) {
> if value is A {
>
> } else if value is B {
>
> } else if value is C {
>
> } else {
>  // There are other cases? Compiler doesn't know
> }
> }
>
> * Original types and union types can have a rational relationship
> between each other.
>Original type is a sub-type of union types contain it.
>
> var fn0: A->Void = {print(v0)}
> var fn1: (A|B)->Void = {print(v0)}
>
> fn0 = fn1 // Original Type and Union Type has a sub-typing relationship,
> OK
>
> var fn2: (A|B|C)->Void = {print($0)}
>
> fn0 = fn2 // OK
> fn1 = fn2 // OK
>
>
> * It is also easy to compare with value of original type.
> union == a // Can be compared, Yes for most cases.
>
> * And the most important part, *It can replace Optional.*
> let string: String?
> is same to
> let string: (String | None)  instead of let string: Optional
>
> I really think the union type is a good supplement for Swift. Make the
> language rational.
> And the It is also really good for Reactive Programming.
>
> - Jiannan
>
> 下面是被转发的邮件：
>
> *发件人: *Haravikk 
> *主题: **回复： [swift-evolution] Union instead of Optional*
> *日期: *2016年5月16日 GMT+8 18:35:25
> *收件人: *Austin Zheng 
> *抄送: *Cao Jiannan , Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>
>
>
> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If A, B, and C are not related via protocol or class inheritance, then
> there is almost nothing you can do with value. Otherwise you still need to
> test against the concrete type using a case statement or a if-else ladder.
>
>
> I think that a case statement or similar syntax will still be needed, and
> the case names would just be the types themselves. This would work best
> with support for type-narrowing, for example:
>
> func someMethod(value:(A|B|C)) {
> switch (value) {
> case .A:
> value.someMethodForTypeA()
> case .B:
> value.someMethodForTypeB()
> case .C:
> value.someMethodForTypeC()
> }
> }
>
> A union should really just be though of as a lightweight, restricted form
> of enum that can be declared in a quick ad-hoc fashion, similar to how
> tuples are a simpler form of struct.
>
> I’m generally a +1 for the feature, but I’d be interested to hear about
> how well equipped the compiler is for optimising something like this. In
> most cases an Optional covers what I need, and in more complex cases I’d
> probably declare overloads for each type (i.e- someMethod(value:A),
> someMethod(value:B) etc.); unions could make the latter case simpler, but
> will the compiler produce the same code behind the scenes, i.e- by
> isolating what’s unique to each type?
>
>
>
> ___
> swift-evolution mailing list
> 

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Nate Cook via swift-evolution]

> On May 17, 2016, at 5:18 PM, Luis Henrique B. Sousa via swift-evolution 
>  wrote:
> 
> Many thanks, @Maximilian. I'm also not sure about the performance cost, but I 
> think it is worth it. 
> So I just updated the proposal also including the additional min/max you have 
> suggested (thanks once again):
> https://github.com/apple/swift-evolution/pull/328
> 
> Best regards,
> 
> - Luis

The new Range types have a clamped(to:) method that should do what you need.

http://swiftdoc.org/v3.0/type/Range/#func-clamped-to_

>> On Tue, May 17, 2016 at 10:32 PM, Maximilian Hünenberger 
>>  wrote:
>> While it is true that it uses min and max, you have to add additional min 
>> max in order to achieve the desired behavior.
>> 
>> So the implementation should be: (also considering (hopefully all) recent 
>> naming/index model updates)
>> 
>> // Index is already Comparable
>> extension Collection {
>> 
>> subscript(clamping range: Range) -> SubSequence {
>> // ---> here you have to use the additional min/max
>> let start = min(max(startIndex, range.startIndex), endIndex)
>> let end = max(min(endIndex, range.endIndex), startIndex)
>> return self[start ..< end]
>> 
>> // ---> or as alternative, probably a bit less performant but 
>> Swiftier
>> return self[range.clamping(startIndex..> }
>> 
>> subscript(checking range: Range) -> SubSequence? {
>> guard range.startIndex >= startIndex && range.endIndex <= endIndex
>> else { return nil }
>> return self[range]
>> }
>> 
>> subscript(checking index: Index) -> Generator.Element? {
>> // ---> minor syntax update *
>> guard self.indices.contains(index)
>> else { return nil }
>> return self[index]
>> }
>> 
>> }
>> 
>> * I'm not sure it is worth the performance cost for arbitrary indices 
>> collection with O(n) search. I could imagine Set and Dictionary indices 
>> cannot be easily validated in comparison to Array indices. However this 
>> approach is more general and handles non trivial index collections where 
>> there is no guarantee that any index between startIndex and endIndex is a 
>> valid one.
>> The same arguments also apply to `subscript(checking range ...)` where you 
>> could validate start and endIndex of the range. 
>> 
>> Best regards
>> Maximilian
>> 
>>> Am 16.05.2016 um 09:45 schrieb Luis Henrique B. Sousa :
>>> 
>>> Yes. The suggested implementation does use min/max:
>>> 
>>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>>> 
>>> - Luis
>>> 
 On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger 
  wrote:
 I brought these up because the current implementation produces an error in 
 these cases. You have to insert additional min/max operations.
 
> Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa 
> :
> 
> Exactly, the idea is to return an empty array just like other languages 
> do. (e.g. python)
> 
> - Luis
> 
>> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution 
>>  wrote:
>>> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
>>> One point which should be discussed is the following behaviour:
>>> 
>>> let array = [0]
>>> // ranges are completely out of bounds and produce an error
>>> array[clamping: 1...2] // error
>>> array[clamping: -2...-1] // error
>>> 
>>> Should a range which has no intersection with the indices of the 
>>> collection
>>> produce an error or just clamp to 0..<0 respectively 
>>> endIndex..> 
>> I expect it will returns [] i.e. empty array, as no elements with 
>> 1...2(-2..-1) indexes in the array. I understand `clamping` similar as 
>> 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10] 
>> will silently move the right position to allowed index(4), and 
>> [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect 
>> that in [0][clamping: 1...2] will try to move both limits to allowed, 
>> and as no intersection - silently return empty array.
>> 
>>> 
>>> Best regards
>>> Maximilian
>>> 
>>> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via 
>>> swift-evolution
>>> >:
>>> 
 It seems that there is a consensus that this proposal might be a good
 addition to the standard library. All comments on this thread in the 
 past
 few weeks were related to naming, not around the behaviour or validity 
 of
 the proposed methods. So I will submit this proposal for review very 
 soon

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

[Eric Wing via swift-evolution]

So I don’t mind (too much) if it takes longer to get a stable ABI. It
makes my life harder, but on the flip-side, I don’t want to be stuck
with yet another broken language and ABI. I want this done right
because it will be almost impossible to fix later.

Here’s a simple, yet tragic example: BOOL in Objective-C. We were
stuck with signed char instead of getting a real boolean. Back in 10.4
Tiger when the Intel migration was announced, I filed a bug report
reminding them that this was the chance to fix this. They didn’t fix
it, so we were stuck. Then I filed again in the 10.5 beta Leopard time
frame during the 64-bit transition, I filed again reminding them that
this should be fixed before the 64-bit ABI gets locked down. Again, it
wasn’t fixed so we were stuck. Then when the iOS SDK was going to
become public, I filed again. Still not fixed. Then armv7, still
nothing. Finally, for arm64, this was finally fixed. Too bad we’re
stuck on Mac with this probably forever.

Anyway, I don’t want to deal with another monstrous broken language.
We have enough of those already. I actually consider it a good sign
when languages remove features instead of add them even if it causes
some migration pain. And I appreciate caution about making sure things
are correct and good before locking down an ABI we’re probably going
to be stuck with for at least another decade.

I assume that Apple still understands the importance of ABI
compatibility due to the Mac heritage and now that iOS has enabled 3rd
party framework support. So I’m fairly confident they will eventually
nail down a stable ABI. I just don’t want the Swift team to forget
that a stable ABI is important for all the other platforms too (even
if those platforms are terrible at delivering this themselves).

Thanks,
Eric
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

David, I'm thinking about the side effects calling a computed property has
and although I see some use cases for let properties I also see
workarounds. For example, a lazy initialiser will solve the issue of
running a certain code only once and caching its value. I also start to
think that any case in this proposal will be solved by lazy initialisers
thus rendering it unnecessary.


On 17 May 2016 at 17:50, David Sweeris  wrote:

> You can't, if you're extending a pre-existing type.
>
> I'd think that it might be possible to do some caching if the compiler
> 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'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 use
> let if the overall computation is constant or not. IMO, let isn't really
> the most appropriate keyword to use for properties.
>
> - Leonardo
>
> On 13 May 2016 at 04:44, Andru Felipe Zuniga via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> It would be useful for clarification of a computed property being
>> constant in extensions. For example:
>>
>> extension SKSpriteNode {
>> static let type: String {
>> return “Sprite”
>> }
>> }
>>
>> Andru
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Luis Henrique B. Sousa via swift-evolution]

Many thanks, @Maximilian. I'm also not sure about the performance cost, but
I think it is worth it.
So I just updated the proposal also including the additional min/max you
have suggested (thanks once again):
https://github.com/apple/swift-evolution/pull/328

Best regards,

- Luis

On Tue, May 17, 2016 at 10:32 PM, Maximilian Hünenberger <
m.huenenber...@me.com> wrote:

> While it is true that it uses min and max, you have to add *additional
> min max* in order to achieve the desired behavior.
>
> So the implementation should be: (also considering (hopefully all) recent
> naming/index model updates)
>
> // Index is already Comparable
> extension Collection {
>
> subscript(clamping range: Range) -> SubSequence {
> // ---> here you have to use the additional min/max
> let start = min(max(startIndex, range.startIndex), endIndex)
> let end = max(min(endIndex, range.endIndex), startIndex)
> return self[start ..< end]
>
> // ---> or as alternative, probably a bit less performant but
> Swiftier
> return self[range.clamping(startIndex.. }
>
> subscript(checking range: Range) -> SubSequence? {
> guard range.startIndex >= startIndex && range.endIndex <= endIndex
> else { return nil }
> return self[range]
> }
>
> subscript(checking index: Index) -> Generator.Element? {
> // ---> minor syntax update *
> guard self.indices.contains(index)
> else { return nil }
> return self[index]
> }
>
> }
>
> * I'm not sure it is worth the performance cost for arbitrary indices
> collection with O(n) search. I could imagine Set and Dictionary indices
> cannot be easily validated in comparison to Array indices. However this
> approach is more general and handles non trivial index collections where
> there is no guarantee that any index between startIndex and endIndex is a
> valid one.
> The same arguments also apply to `subscript(checking range ...)` where you
> could validate start and endIndex of the range.
>
> Best regards
> Maximilian
>
> Am 16.05.2016 um 09:45 schrieb Luis Henrique B. Sousa  >:
>
> Yes. The suggested implementation does use min/max:
>
>
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>
> - Luis
>
> On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger <
> m.huenenber...@me.com> wrote:
>
>> I brought these up because the current implementation produces an error
>> in these cases. You have to insert additional min/max operations.
>>
>> Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa > >:
>>
>> Exactly, the idea is to return an empty array just like other languages
>> do. (e.g. python)
>>
>> - Luis
>>
>> On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
>>>
 One point which should be discussed is the following behaviour:

 let array = [0]
 // ranges are completely out of bounds and produce an error
 array[clamping: 1...2] // error
 array[clamping: -2...-1] // error

 Should a range which has no intersection with the indices of the
 collection
 produce an error or just clamp to 0..<0 respectively
 endIndex..>>
>>> I expect it will returns [] i.e. empty array, as no elements with
>>> 1...2(-2..-1) indexes in the array. I understand `clamping` similar as
>>> 'bounded','in these bounds'. And as soon as [0,1,2,3,4][clamping:2...10]
>>> will silently move the right position to allowed index(4), and
>>> [0,1,2,3,4][clamping:-2...0]  will move left position to 0, I expect that
>>> in [0][clamping: 1...2] will try to move both limits to allowed, and as no
>>> intersection - silently return empty array.
>>>
>>>
 Best regards
 Maximilian

 Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via
 swift-evolution
 >:

 It seems that there is a consensus that this proposal might be a good
> addition to the standard library. All comments on this thread in the
> past
> few weeks were related to naming, not around the behaviour or validity
> of
> the proposed methods. So I will submit this proposal for review very
> soon
> assuming that nobody else has strong arguments against it. :-)
>
> Proposal:
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>
> If you have any corrections or suggestions to the proposal text itself,
> please comment on this gist:
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
> (or pull request to my repo)
>
> Regards,
>
> - Luis
>
> On Tue, May 10, 2016 at 4:13 PM, 

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

[Leonardo Pessoa via swift-evolution]

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 continuation from the previous line. This
may even be simpler to implement than I think but the code may become more
prone to errors as I may forget an item spans across two or more lines and
thus harder to read. If the clarity of code is a premisse of Swift, I think
this change would go against it.

- Leonardo

On 17 May 2016 at 15:22, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 17.05.2016 21:06, Tino Heth wrote:
>
>> - method parameters
>> - array and dictionary literals
>> - tuples
>> [anything else?]
>>
>
> list of generic types:
> func f(t: T, u: U, v: V) {
>  ..
> }
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Maximilian Hünenberger via swift-evolution]

While it is true that it uses min and max, you have to add additional min max 
in order to achieve the desired behavior.

So the implementation should be: (also considering (hopefully all) recent 
naming/index model updates)

// Index is already Comparable
extension Collection {

subscript(clamping range: Range) -> SubSequence {
// ---> here you have to use the additional min/max
let start = min(max(startIndex, range.startIndex), endIndex)
let end = max(min(endIndex, range.endIndex), startIndex)
return self[start ..< end]

// ---> or as alternative, probably a bit less performant but Swiftier
return self[range.clamping(startIndex.. SubSequence? {
guard range.startIndex >= startIndex && range.endIndex <= endIndex
else { return nil }
return self[range]
}

subscript(checking index: Index) -> Generator.Element? {
// ---> minor syntax update *
guard self.indices.contains(index)
else { return nil }
return self[index]
}

}

* I'm not sure it is worth the performance cost for arbitrary indices 
collection with O(n) search. I could imagine Set and Dictionary indices cannot 
be easily validated in comparison to Array indices. However this approach is 
more general and handles non trivial index collections where there is no 
guarantee that any index between startIndex and endIndex is a valid one.
The same arguments also apply to `subscript(checking range ...)` where you 
could validate start and endIndex of the range. 

Best regards
Maximilian

> Am 16.05.2016 um 09:45 schrieb Luis Henrique B. Sousa :
> 
> Yes. The suggested implementation does use min/max:
> 
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
> 
> - Luis
> 
>> On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger 
>>  wrote:
>> I brought these up because the current implementation produces an error in 
>> these cases. You have to insert additional min/max operations.
>> 
>>> Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa :
>>> 
>>> Exactly, the idea is to return an empty array just like other languages do. 
>>> (e.g. python)
>>> 
>>> - Luis
>>> 
 On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution 
  wrote:
> On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote:
> One point which should be discussed is the following behaviour:
> 
> let array = [0]
> // ranges are completely out of bounds and produce an error
> array[clamping: 1...2] // error
> array[clamping: -2...-1] // error
> 
> Should a range which has no intersection with the indices of the 
> collection
> produce an error or just clamp to 0..<0 respectively endIndex.. 
> Best regards
> Maximilian
> 
> Am 13.05.2016 um 17:10 schrieb Luis Henrique B. Sousa via swift-evolution
> >:
> 
>> It seems that there is a consensus that this proposal might be a good
>> addition to the standard library. All comments on this thread in the past
>> few weeks were related to naming, not around the behaviour or validity of
>> the proposed methods. So I will submit this proposal for review very soon
>> assuming that nobody else has strong arguments against it. :-)
>> 
>> Proposal: 
>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>> 
>> If you have any corrections or suggestions to the proposal text itself,
>> please comment on this gist:
>> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8
>> (or pull request to my repo)
>> 
>> Regards,
>> 
>> - Luis
>> 
>> On Tue, May 10, 2016 at 4:13 PM, Luis Henrique B. Sousa
>> > wrote:
>> 
>> Please let me know if you have more suggestions or corrections on
>> this proposal.
>> I'm tempted to submit it for review. :-)
>> 
>> - Luis
>> 
>> On Tue, May 10, 2016 at 8:53 AM, Luis Henrique B. Sousa
>> > 

Re: [swift-evolution] Enhanced existential types proposal discussion

[Joe Groff via swift-evolution]

> On May 17, 2016, at 2:04 PM, Austin Zheng  wrote:
> 
> I think this is also probably the best approach. Reskin protocol<> so people 
> can fix their code when 3.0 hits, and then extend its functionality in an 
> additive way.
> 
> Joe, given that this counts as part of "generics and ABI", is it acceptable 
> to continue discussion? Or should all of this be tabled until August?

IMO, discussion on the list is fine, though most of us are probably too busy to 
deeply participate right now, and any submitted proposals are likely to be 
deferred until after Swift 3 wraps up.

-Joe

> Austin
> 
> On Tue, May 17, 2016 at 1:55 PM, Joe Groff  wrote:
> 
> > On May 17, 2016, at 1:27 PM, Matthew Johnson via swift-evolution 
> >  wrote:
> >
> >
> >> On May 17, 2016, at 3:06 PM, Austin Zheng  wrote:
> >>
> >> I'm honestly not sure it makes sense to introduce a proposal just for 
> >> expressing  style requirements, and then trying 
> >> to retrofit fuller support for other existentials onto it. I would prefer 
> >> that the 'basic package' of existential cases be considered together as a 
> >> single proposal, unless a core team member expresses their preference 
> >> otherwise.
> >
> > It also renames protocol<> to Any, but fair enough.
> >
> > One reason to keep it separate is that the rename is a breaking change and 
> > we should really try to get that into Swift 3.  Generalizing existentials 
> > is an additive change.  I would love to have that in Swift 3 as well, but 
> > if it’s not going to make it I don’t think it should hold back the smaller 
> > change which is a breaking change.
> >
> > Doug, any opinion on this?
> 
> I agree with this. If we're certain we should reskin protocol<> as Any<>, we 
> should frontload that change—in addition to affecting source code, it'd also 
> influence the runtime behavior of type printing/parsing, which can't be 
> statically migrated in the future. I think any discussion of extending 
> existentials has to be considered out of scope for Swift 3, though, so the 
> Any rename deserves its own proposal.
> 
> -Joe
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Thanks Brent, this one is quite a keeper :). Concise and very friendly way of 
explaining RawRepresentable.

Sent from my iPhone

On 17 May 2016, at 21:05, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On the other hand: What's the point of "raw-value enums"? Are they just a 
>> bridge-technogy, or is it ok to use them to store constants?
> 
> I think of RawRepresentable (the protocol behind rawValue) as a serialization 
> mechanism, basically the Swift standard library's answer to NSCoding. Thus, 
> rawValue is a way to serialize your enum into an Int or String you know how 
> to read and write from disk. More broadly, I often apply RawRepresentable to 
> structs and have them return plist- or JSON-compatible dictionaries. 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

I think this is also probably the best approach. Reskin protocol<> so
people can fix their code when 3.0 hits, and then extend its functionality
in an additive way.

Joe, given that this counts as part of "generics and ABI", is it acceptable
to continue discussion? Or should all of this be tabled until August?

Austin

On Tue, May 17, 2016 at 1:55 PM, Joe Groff  wrote:

>
> > On May 17, 2016, at 1:27 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On May 17, 2016, at 3:06 PM, Austin Zheng 
> wrote:
> >>
> >> I'm honestly not sure it makes sense to introduce a proposal just for
> expressing  style requirements, and then trying
> to retrofit fuller support for other existentials onto it. I would prefer
> that the 'basic package' of existential cases be considered together as a
> single proposal, unless a core team member expresses their preference
> otherwise.
> >
> > It also renames protocol<> to Any, but fair enough.
> >
> > One reason to keep it separate is that the rename is a breaking change
> and we should really try to get that into Swift 3.  Generalizing
> existentials is an additive change.  I would love to have that in Swift 3
> as well, but if it’s not going to make it I don’t think it should hold back
> the smaller change which is a breaking change.
> >
> > Doug, any opinion on this?
>
> I agree with this. If we're certain we should reskin protocol<> as Any<>,
> we should frontload that change—in addition to affecting source code, it'd
> also influence the runtime behavior of type printing/parsing, which can't
> be statically migrated in the future. I think any discussion of extending
> existentials has to be considered out of scope for Swift 3, though, so the
> Any rename deserves its own proposal.
>
> -Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Joe Groff via swift-evolution]

> On May 17, 2016, at 1:27 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 17, 2016, at 3:06 PM, Austin Zheng  wrote:
>> 
>> I'm honestly not sure it makes sense to introduce a proposal just for 
>> expressing  style requirements, and then trying 
>> to retrofit fuller support for other existentials onto it. I would prefer 
>> that the 'basic package' of existential cases be considered together as a 
>> single proposal, unless a core team member expresses their preference 
>> otherwise.
> 
> It also renames protocol<> to Any, but fair enough.  
> 
> One reason to keep it separate is that the rename is a breaking change and we 
> should really try to get that into Swift 3.  Generalizing existentials is an 
> additive change.  I would love to have that in Swift 3 as well, but if it’s 
> not going to make it I don’t think it should hold back the smaller change 
> which is a breaking change.
> 
> Doug, any opinion on this?

I agree with this. If we're certain we should reskin protocol<> as Any<>, we 
should frontload that change—in addition to affecting source code, it'd also 
influence the runtime behavior of type printing/parsing, which can't be 
statically migrated in the future. I think any discussion of extending 
existentials has to be considered out of scope for Swift 3, though, so the Any 
rename deserves its own proposal.

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 3:06 PM, Austin Zheng  wrote:
> 
> I'm honestly not sure it makes sense to introduce a proposal just for 
> expressing  style requirements, and then trying to 
> retrofit fuller support for other existentials onto it. I would prefer that 
> the 'basic package' of existential cases be considered together as a single 
> proposal, unless a core team member expresses their preference otherwise.

It also renames protocol<> to Any, but fair enough.  

One reason to keep it separate is that the rename is a breaking change and we 
should really try to get that into Swift 3.  Generalizing existentials is an 
additive change.  I would love to have that in Swift 3 as well, but if it’s not 
going to make it I don’t think it should hold back the smaller change which is 
a breaking change.

Doug, any opinion on this?

> 
> Austin
> 
> On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson  > wrote:
> 
>> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution 
>> > wrote:
>> 
>> Feel free to add as much of this proposal into yours as you want.
> 
> The trend is towards smaller proposals and introducing change in stages.  
> Since Adrian’s proposal is almost ready it’s probably best to move ahead with 
> it as-is and follow up with generalized existentials (yours), and then 
> possibly a third on “opening” existentials.
> 
>> 
>> Austin
>> 
>> On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> +1 for extending my proposal and making `Any<>` even more a powerful beast. 
>> :)
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> I put together the skeleton of a proposal detailing enhancements to how 
>>> associated types can be referenced in Swift 3+. It's certainly not ready 
>>> for submission, but I think it gets across my ideas pretty well. Would love 
>>> to gather feedback and especially improvements.
>>> 
>>> Be unsparing; whatever form this feature takes will profoundly affect how 
>>> Swift developers program for years, so it needs to be done right.
>>> 
>>> See below:
>>> 
>>> Proposal
>>> 
>>> An existential type is defined using the "Any<...>" construct. Existential 
>>> types can be nested.
>>> 
>>> The empty existential type "Any<>" is typealiased to 'Any'.
>>> 
>>> Within the angle brackets are zero or more 'clauses'. Clauses are separated 
>>> by semicolons. (This is so commas can be used in where constraints, below. 
>>> Better ideas are welcome. Maybe it's not necessary; we can use commas 
>>> exclusively.)
>>> 
>>> There are five different possible clauses:
>>> 
>>> 'class'. Must be the first clause, if present. Places a constraint on the 
>>> existential to be any class type. (Implies: Only one can exist. Mutually 
>>> exclusive with class name clause.)
>>> 
>>> (In the future a follow-up proposal should add in 'struct' or 'value' as a 
>>> counterpart.)
>>> 
>>> Class name. Must be the first clause, if present. (Implies: Only one can 
>>> exist. Mutually exclusive with 'class'.) Places a constraint on the 
>>> existential (not really an existential anymore) to be an instance of the 
>>> class, or one of its subclasses.
>>> Example: Any
>>> "Any UIViewController or subclass which also satisfies the table view data 
>>> source and delegate protocols"
>>> Dynamic protocol. This is entirely composed of the name of a protocol which 
>>> has no associated types or Self requirement.
>>> 
>>> Example: Any
>>> "Any type which conforms to both the CustomStringConvertible and 
>>> BooleanType protocols"
>>> 
>>> I'm going to use 'static protocol' to refer to a protocol with associated 
>>> types or self requirements. Feel free to propose a more sound name.
>>> 
>>> Self-contained static protocol, simple. This is composed of the name of a 
>>> static protocol, optionally followed by a 'where' clause in which the 
>>> associated types can be constrained (with any of the three basic 
>>> conformance types: subclassing, protocol conformance, or type equality). 
>>> Associated types are referred to with a leading dot.
>>> 
>>> Example: Any>> .Generator.Element : SomeProtocol>
>>> "Any type that is a Collection, whose elements are NSObjects or their 
>>> subclasses conforming to SomeProtocol."
>>> 
>>> Bound static protocol. This is the same as a self-contained static 
>>> protocol, but with a leading " as " which binds the protocol to a 
>>> generic typealias. The name can be then be used in subsequent clauses to 
>>> build constraints.
>>> 
>>> Example: Any>> .IntegerLiteralType == 

Re: [swift-evolution] Enhanced existential types proposal discussion

[Adrian Zubarev via swift-evolution]

I'm honestly not sure it makes sense to introduce a proposal just for 
expressing  style requirements, and then trying to 
retrofit fuller support for other existentials onto it. I would prefer that the 
'basic package' of existential cases be considered together as a single 
proposal, unless a core team member expresses their preference otherwise.

I don’t see the point why we couldn’t do that! I mean if we add to much into a 
single proposal it would have more chances to be rejected. Besides that Chris 
already did the same with his `generic typealias` proposal where the whole 
feature was only introduced in its base form, which will gain more constraints 
later on. I don’t think the base form of `Any<>` gaining more constraints will 
break any code later, when there are no significant changes in syntax.

Another area you didn’t touch on is whether Any constructs (and typealiases 
referring to them) should be usable as generic constraints.  I would expect 
this to be possible but I think we need to spell it out.
I was thinking about this while looking at `var view: Any`. If UIView does not conform to SomeProtocol you won’t be able to 
construct that type because otherwise it just would be `UIView`.

One would only be able to construct `Any<>` if it can be inferred to a single 
type like `SomeClass`. Thats what I thought and dropped from mentioning that. 



Btw. I submitted a pull request already, but I noted in my proposal in the 
future directions section the following:

Any<> should reflect powerful generalized generic features to be able to 
constrain types even further. (This should have its own proposal, which will 
extend Any<> proposed here.)

I hope my English wasn't too bad, please don’t blame me. :D

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 22:07:00, Austin Zheng (austinzh...@gmail.com) schrieb:


Austin

On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson  wrote:

On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution 
 wrote:

Feel free to add as much of this proposal into yours as you want.

The trend is towards smaller proposals and introducing change in stages.  Since 
Adrian’s proposal is almost ready it’s probably best to move ahead with it 
as-is and follow up with generalized existentials (yours), and then possibly a 
third on “opening” existentials.


Austin

On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution 
 wrote:
+1 for extending my proposal and making `Any<>` even more a powerful beast. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution 
(swift-evolution@swift.org) schrieb:

I put together the skeleton of a proposal detailing enhancements to how 
associated types can be referenced in Swift 3+. It's certainly not ready for 
submission, but I think it gets across my ideas pretty well. Would love to 
gather feedback and especially improvements.

Be unsparing; whatever form this feature takes will profoundly affect how Swift 
developers program for years, so it needs to be done right.

See below:

Proposal

An existential type is defined using the "Any<...>" construct. Existential 
types can be nested.

The empty existential type "Any<>" is typealiased to 'Any'.

Within the angle brackets are zero or more 'clauses'. Clauses are separated by 
semicolons. (This is so commas can be used in where constraints, below. Better 
ideas are welcome. Maybe it's not necessary; we can use commas exclusively.)

There are five different possible clauses:

'class'. Must be the first clause, if present. Places a constraint on the 
existential to be any class type. (Implies: Only one can exist. Mutually 
exclusive with class name clause.)

(In the future a follow-up proposal should add in 'struct' or 'value' as a 
counterpart.)

Class name. Must be the first clause, if present. (Implies: Only one can exist. 
Mutually exclusive with 'class'.) Places a constraint on the existential (not 
really an existential anymore) to be an instance of the class, or one of its 
subclasses.
Example: Any
"Any UIViewController or subclass which also satisfies the table view data 
source and delegate protocols"
Dynamic protocol. This is entirely composed of the name of a protocol which has 
no associated types or Self requirement.

Example: Any
"Any type which conforms to both the CustomStringConvertible and BooleanType 
protocols"

I'm going to use 'static protocol' to refer to a protocol with associated types 
or self requirements. Feel free to propose a more sound name.

Self-contained static protocol, simple. This is composed of the name of a 
static protocol, optionally followed by a 'where' clause in which the 
associated types can be constrained (with any of the three basic conformance 
types: 

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

[Austin Zheng via swift-evolution]

Oh, this is a really interesting use case for that protocol. I wonder if
RawRepresentable might one day be auto-derivable for certain types, as part
of a more comprehensive Swift serialization/deserialization feature.

Austin

On Tue, May 17, 2016 at 1:05 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On the other hand: What's the point of "raw-value enums"? Are they just
> a bridge-technogy, or is it ok to use them to store constants?
>
> I think of RawRepresentable (the protocol behind rawValue) as a
> serialization mechanism, basically the Swift standard library's answer to
> NSCoding. Thus, rawValue is a way to serialize your enum into an Int or
> String you know how to read and write from disk. More broadly, I often
> apply RawRepresentable to structs and have them return plist- or
> JSON-compatible dictionaries.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

I'm honestly not sure it makes sense to introduce a proposal just for
expressing  style requirements, and then trying
to retrofit fuller support for other existentials onto it. I would prefer
that the 'basic package' of existential cases be considered together as a
single proposal, unless a core team member expresses their preference
otherwise.

Austin

On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson 
wrote:

>
> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Feel free to add as much of this proposal into yours as you want.
>
>
> The trend is towards smaller proposals and introducing change in stages.
> Since Adrian’s proposal is almost ready it’s probably best to move ahead
> with it as-is and follow up with generalized existentials (yours), and then
> possibly a third on “opening” existentials.
>
>
> Austin
>
> On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1 for extending my proposal and making `Any<>` even more a powerful
>> beast. :)
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>> I put together the skeleton of a proposal detailing enhancements to how
>> associated types can be referenced in Swift 3+. It's certainly not ready
>> for submission, but I think it gets across my ideas pretty well. Would love
>> to gather feedback and especially improvements.
>>
>> Be unsparing; whatever form this feature takes will profoundly affect how
>> Swift developers program for years, so it needs to be done right.
>>
>> See below:
>>
>> *Proposal*
>>
>> An existential type is defined using the "Any<...>" construct.
>> Existential types can be nested.
>>
>> The empty existential type "Any<>" is typealiased to 'Any'.
>>
>> Within the angle brackets are zero or more 'clauses'. Clauses are
>> separated by semicolons. (This is so commas can be used in where
>> constraints, below. Better ideas are welcome. Maybe it's not necessary; we
>> can use commas exclusively.)
>>
>> There are five different possible clauses:
>>
>>
>>- 'class'. Must be the first clause, if present. Places a constraint
>>on the existential to be any class type. (Implies: Only one can exist.
>>Mutually exclusive with class name clause.)
>>
>>
>> (In the future a follow-up proposal should add in 'struct' or 'value' as
>> a counterpart.)
>>
>>
>>- Class name. Must be the first clause, if present. (Implies: Only
>>one can exist. Mutually exclusive with 'class'.) Places a constraint on 
>> the
>>existential (not really an existential anymore) to be an instance of the
>>class, or one of its subclasses.
>>
>> Example: Any
>> "Any UIViewController or subclass which also satisfies the table view
>> data source and delegate protocols"
>>
>>- Dynamic protocol. This is entirely composed of the name of a
>>protocol which has no associated types or Self requirement.
>>
>>
>> Example: Any
>> "Any type which conforms to both the CustomStringConvertible and
>> BooleanType protocols"
>>
>> I'm going to use 'static protocol' to refer to a protocol with associated
>> types or self requirements. Feel free to propose a more sound name.
>>
>>
>>- Self-contained static protocol, simple. This is composed of the
>>name of a static protocol, optionally followed by a 'where' clause in 
>> which
>>the associated types can be constrained (with any of the three basic
>>conformance types: subclassing, protocol conformance, or type equality).
>>Associated types are referred to with a leading dot.
>>
>>
>> Example: Any> .Generator.Element : SomeProtocol>
>> "Any type that is a Collection, whose elements are NSObjects or their
>> subclasses conforming to SomeProtocol."
>>
>>
>>- Bound static protocol. This is the same as a self-contained static
>>protocol, but with a leading " as " which binds the protocol to a
>>generic typealias. The name can be then be used in subsequent clauses to
>>build constraints.
>>
>>
>> Example: Any> .IntegerLiteralType == T.Element>.
>> "Any type that is a Collection, and also can be built from an integer
>> literal, in which the collection elements are the same type as the type of
>> the integer used for the integer literal conformance."
>>
>> There will be rules to prevent recursive nesting. For example, if generic
>> typealiases are allowed, they cannot refer to each other in a circular
>> manner (like how structs can't contain themeselves, and you can't create a
>> cyclic graph of enums containing themselves).
>>
>> How an existential can be used depends on what guarantees are provided by
>> the clauses. For example, 'Any' can't be used for much; if there
>> were any methods on Equatable that did 

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

[Brent Royal-Gordon via swift-evolution]

> On the other hand: What's the point of "raw-value enums"? Are they just a 
> bridge-technogy, or is it ok to use them to store constants?

I think of RawRepresentable (the protocol behind rawValue) as a serialization 
mechanism, basically the Swift standard library's answer to NSCoding. Thus, 
rawValue is a way to serialize your enum into an Int or String you know how to 
read and write from disk. More broadly, I often apply RawRepresentable to 
structs and have them return plist- or JSON-compatible dictionaries. 

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

Responses inline. Thanks for taking the time to read through and comment,
your feedback is incredibly useful!

On Tue, May 17, 2016 at 12:41 PM, Matthew Johnson 
wrote:

>
> On May 17, 2016, at 1:52 PM, Austin Zheng  wrote:
>
> I put together the skeleton of a proposal detailing enhancements to how
> associated types can be referenced in Swift 3+. It's certainly not ready
> for submission, but I think it gets across my ideas pretty well. Would love
> to gather feedback and especially improvements.
>
> Be unsparing; whatever form this feature takes will profoundly affect how
> Swift developers program for years, so it needs to be done right.
>
> See below:
>
> *Proposal*
>
> An existential type is defined using the "Any<...>" construct. Existential
> types can be nested.
>
> The empty existential type "Any<>" is typealiased to 'Any’.
>
>
> Also, Any is equivalent to SomeProtocol.
>

Yes. protocol<> currently also behaves like this.


>
>
> Within the angle brackets are zero or more 'clauses'. Clauses are
> separated by semicolons. (This is so commas can be used in where
> constraints, below. Better ideas are welcome. Maybe it's not necessary; we
> can use commas exclusively.)
>
>
> I’m not a fan of the semicolon idea.  I don’t see any reason for this.
> The `where` keyword separates the protocol list from the constraints just
> fine.  The list on either side should be able to use commas with no problem
> (or line breaks if that proposal goes through).
>
>
I'm leaning towards getting rid of the commas, but would like to write out
a few 'dummy' examples to see if there are any readability issues that
arise.

>
> There are five different possible clauses:
>
>
>- 'class'. Must be the first clause, if present. Places a constraint
>on the existential to be any class type. (Implies: Only one can exist.
>Mutually exclusive with class name clause.)
>
>
> (In the future a follow-up proposal should add in 'struct' or 'value' as a
> counterpart.)
>
>
> If we’re going to allow `struct` we should also allow `enum`.  `value`
> would allow either of those.
>
>
Of course. A future proposal can allow list members to discuss the exact
details as to how struct, value, or enum specifiers should work.

>
>
>- Class name. Must be the first clause, if present. (Implies: Only one
>can exist. Mutually exclusive with 'class'.) Places a constraint on the
>existential (not really an existential anymore) to be an instance of the
>class, or one of its subclasses.
>
> It is still be an existential if it includes protocol requirements that
> the class does not fulfill.  For example, you might have Any SomeProtocol> where UIView does not conform to SomeProtocol, but various
> subclasses do.
>
>
Fair enough. (I don't think the way things work would be affected.)


> Your proposal doesn’t discuss composing Any in the way that Adrian’s did
> like this:
>
> typealias Foo = Any
> Any
>

I didn't think it needed to be discussed. An Any<...> existential type is a
type 'expression' just like any other, and should be allowed to participate
in other Any<...>s.


>
> I like the idea of composition as it allows us to factor out constraints.
> If we are going to do that we should allow a class to be specified in the
> composition as long is it is a subclass of all class requirements of Any
> types it composes.  For example, this should be allowed:
>
> typealias Bar = Any
>
> This is still one class requirement for Bar, it just refines the class
> requirement of Foo to be SubclassOfSomeClass rather than just SomeClass.
>

This is a good point. There should be clarification as to how special cases
of Any<...> used in another Any<...> behave. For example, like you said
Any> should be valid. This
will go into any proposal that emerges from the discussion.


>
> Example: Any
> "Any UIViewController or subclass which also satisfies the table view data
> source and delegate protocols"
>
>- Dynamic protocol. This is entirely composed of the name of a
>protocol which has no associated types or Self requirement.
>
> Example: Any
> "Any type which conforms to both the CustomStringConvertible and
> BooleanType protocols"
>
> I'm going to use 'static protocol' to refer to a protocol with associated
> types or self requirements. Feel free to propose a more sound name.
>
>
>- Self-contained static protocol, simple. This is composed of the name
>of a static protocol, optionally followed by a 'where' clause in which the
>associated types can be constrained (with any of the three basic
>conformance types: subclassing, protocol conformance, or type equality).
>Associated types are referred to with a leading dot.
>

Re: [swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Feel free to add as much of this proposal into yours as you want.

The trend is towards smaller proposals and introducing change in stages.  Since 
Adrian’s proposal is almost ready it’s probably best to move ahead with it 
as-is and follow up with generalized existentials (yours), and then possibly a 
third on “opening” existentials.

> 
> Austin
> 
> On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution 
> > wrote:
> +1 for extending my proposal and making `Any<>` even more a powerful beast. :)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> I put together the skeleton of a proposal detailing enhancements to how 
>> associated types can be referenced in Swift 3+. It's certainly not ready for 
>> submission, but I think it gets across my ideas pretty well. Would love to 
>> gather feedback and especially improvements.
>> 
>> Be unsparing; whatever form this feature takes will profoundly affect how 
>> Swift developers program for years, so it needs to be done right.
>> 
>> See below:
>> 
>> Proposal
>> 
>> An existential type is defined using the "Any<...>" construct. Existential 
>> types can be nested.
>> 
>> The empty existential type "Any<>" is typealiased to 'Any'.
>> 
>> Within the angle brackets are zero or more 'clauses'. Clauses are separated 
>> by semicolons. (This is so commas can be used in where constraints, below. 
>> Better ideas are welcome. Maybe it's not necessary; we can use commas 
>> exclusively.)
>> 
>> There are five different possible clauses:
>> 
>> 'class'. Must be the first clause, if present. Places a constraint on the 
>> existential to be any class type. (Implies: Only one can exist. Mutually 
>> exclusive with class name clause.)
>> 
>> (In the future a follow-up proposal should add in 'struct' or 'value' as a 
>> counterpart.)
>> 
>> Class name. Must be the first clause, if present. (Implies: Only one can 
>> exist. Mutually exclusive with 'class'.) Places a constraint on the 
>> existential (not really an existential anymore) to be an instance of the 
>> class, or one of its subclasses.
>> Example: Any
>> "Any UIViewController or subclass which also satisfies the table view data 
>> source and delegate protocols"
>> Dynamic protocol. This is entirely composed of the name of a protocol which 
>> has no associated types or Self requirement.
>> 
>> Example: Any
>> "Any type which conforms to both the CustomStringConvertible and BooleanType 
>> protocols"
>> 
>> I'm going to use 'static protocol' to refer to a protocol with associated 
>> types or self requirements. Feel free to propose a more sound name.
>> 
>> Self-contained static protocol, simple. This is composed of the name of a 
>> static protocol, optionally followed by a 'where' clause in which the 
>> associated types can be constrained (with any of the three basic conformance 
>> types: subclassing, protocol conformance, or type equality). Associated 
>> types are referred to with a leading dot.
>> 
>> Example: Any> .Generator.Element : SomeProtocol>
>> "Any type that is a Collection, whose elements are NSObjects or their 
>> subclasses conforming to SomeProtocol."
>> 
>> Bound static protocol. This is the same as a self-contained static protocol, 
>> but with a leading " as " which binds the protocol to a generic 
>> typealias. The name can be then be used in subsequent clauses to build 
>> constraints.
>> 
>> Example: Any> .IntegerLiteralType == T.Element>.
>> "Any type that is a Collection, and also can be built from an integer 
>> literal, in which the collection elements are the same type as the type of 
>> the integer used for the integer literal conformance."
>> 
>> There will be rules to prevent recursive nesting. For example, if generic 
>> typealiases are allowed, they cannot refer to each other in a circular 
>> manner (like how structs can't contain themeselves, and you can't create a 
>> cyclic graph of enums containing themselves).
>> 
>> How an existential can be used depends on what guarantees are provided by 
>> the clauses. For example, 'Any' can't be used for much; if there 
>> were any methods on Equatable that did not use the associated types at all 
>> you'd be able to call them, but that's about it. However, 'Any> where .Self == String>' would allow for == to be called on instances. (This 
>> is a stupid example, since Any is 
>> equivalent to 'String', but there are almost certainly useful examples one 
>> could come up with.)
>> 
>> In order of increasing 'power':
>> Don't constrain any associated types. You can pass around Anys, 
>> but that's about it.
>> Constrain 

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

Feel free to add as much of this proposal into yours as you want.

Austin

On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for extending my proposal and making `Any<>` even more a powerful
> beast. :)
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> I put together the skeleton of a proposal detailing enhancements to how
> associated types can be referenced in Swift 3+. It's certainly not ready
> for submission, but I think it gets across my ideas pretty well. Would love
> to gather feedback and especially improvements.
>
> Be unsparing; whatever form this feature takes will profoundly affect how
> Swift developers program for years, so it needs to be done right.
>
> See below:
>
> *Proposal*
>
> An existential type is defined using the "Any<...>" construct. Existential
> types can be nested.
>
> The empty existential type "Any<>" is typealiased to 'Any'.
>
> Within the angle brackets are zero or more 'clauses'. Clauses are
> separated by semicolons. (This is so commas can be used in where
> constraints, below. Better ideas are welcome. Maybe it's not necessary; we
> can use commas exclusively.)
>
> There are five different possible clauses:
>
>
>- 'class'. Must be the first clause, if present. Places a constraint
>on the existential to be any class type. (Implies: Only one can exist.
>Mutually exclusive with class name clause.)
>
>
> (In the future a follow-up proposal should add in 'struct' or 'value' as a
> counterpart.)
>
>
>- Class name. Must be the first clause, if present. (Implies: Only one
>can exist. Mutually exclusive with 'class'.) Places a constraint on the
>existential (not really an existential anymore) to be an instance of the
>class, or one of its subclasses.
>
> Example: Any
> "Any UIViewController or subclass which also satisfies the table view data
> source and delegate protocols"
>
>- Dynamic protocol. This is entirely composed of the name of a
>protocol which has no associated types or Self requirement.
>
>
> Example: Any
> "Any type which conforms to both the CustomStringConvertible and
> BooleanType protocols"
>
> I'm going to use 'static protocol' to refer to a protocol with associated
> types or self requirements. Feel free to propose a more sound name.
>
>
>- Self-contained static protocol, simple. This is composed of the name
>of a static protocol, optionally followed by a 'where' clause in which the
>associated types can be constrained (with any of the three basic
>conformance types: subclassing, protocol conformance, or type equality).
>Associated types are referred to with a leading dot.
>
>
> Example: Any .Generator.Element : SomeProtocol>
> "Any type that is a Collection, whose elements are NSObjects or their
> subclasses conforming to SomeProtocol."
>
>
>- Bound static protocol. This is the same as a self-contained static
>protocol, but with a leading " as " which binds the protocol to a
>generic typealias. The name can be then be used in subsequent clauses to
>build constraints.
>
>
> Example: Any .IntegerLiteralType == T.Element>.
> "Any type that is a Collection, and also can be built from an integer
> literal, in which the collection elements are the same type as the type of
> the integer used for the integer literal conformance."
>
> There will be rules to prevent recursive nesting. For example, if generic
> typealiases are allowed, they cannot refer to each other in a circular
> manner (like how structs can't contain themeselves, and you can't create a
> cyclic graph of enums containing themselves).
>
> How an existential can be used depends on what guarantees are provided by
> the clauses. For example, 'Any' can't be used for much; if there
> were any methods on Equatable that did not use the associated types at all
> you'd be able to call them, but that's about it. However, 'Any where .Self == String>' would allow for == to be called on instances. (This
> is a stupid example, since Any is
> equivalent to 'String', but there are almost certainly useful examples one
> could come up with.)
>
> In order of increasing 'power':
>
>- Don't constrain any associated types. You can pass around
>Anys, but that's about it.
>- Constrain associated types to conform to protocols.
>- Fully constrain associated types.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing 

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

[Leonardo Pessoa via swift-evolution]

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 use
let if the overall computation is constant or not. IMO, let isn't really
the most appropriate keyword to use for properties.

- Leonardo

On 13 May 2016 at 04:44, Andru Felipe Zuniga via swift-evolution <
swift-evolution@swift.org> wrote:

> It would be useful for clarification of a computed property being constant
> in extensions. For example:
>
> extension SKSpriteNode {
> static let type: String {
> return “Sprite”
> }
> }
>
> Andru
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 1:52 PM, Austin Zheng  wrote:
> 
> I put together the skeleton of a proposal detailing enhancements to how 
> associated types can be referenced in Swift 3+. It's certainly not ready for 
> submission, but I think it gets across my ideas pretty well. Would love to 
> gather feedback and especially improvements.
> 
> Be unsparing; whatever form this feature takes will profoundly affect how 
> Swift developers program for years, so it needs to be done right.
> 
> See below:
> 
> Proposal
> 
> An existential type is defined using the "Any<...>" construct. Existential 
> types can be nested.
> 
> The empty existential type "Any<>" is typealiased to 'Any’.

Also, Any is equivalent to SomeProtocol.

> 
> Within the angle brackets are zero or more 'clauses'. Clauses are separated 
> by semicolons. (This is so commas can be used in where constraints, below. 
> Better ideas are welcome. Maybe it's not necessary; we can use commas 
> exclusively.)

I’m not a fan of the semicolon idea.  I don’t see any reason for this.  The 
`where` keyword separates the protocol list from the constraints just fine.  
The list on either side should be able to use commas with no problem (or line 
breaks if that proposal goes through).

> 
> There are five different possible clauses:
> 
> 'class'. Must be the first clause, if present. Places a constraint on the 
> existential to be any class type. (Implies: Only one can exist. Mutually 
> exclusive with class name clause.)
> 
> (In the future a follow-up proposal should add in 'struct' or 'value' as a 
> counterpart.)

If we’re going to allow `struct` we should also allow `enum`.  `value` would 
allow either of those.

> 
> Class name. Must be the first clause, if present. (Implies: Only one can 
> exist. Mutually exclusive with 'class'.) Places a constraint on the 
> existential (not really an existential anymore) to be an instance of the 
> class, or one of its subclasses.
It is still be an existential if it includes protocol requirements that the 
class does not fulfill.  For example, you might have Any 
where UIView does not conform to SomeProtocol, but various subclasses do.

Your proposal doesn’t discuss composing Any in the way that Adrian’s did like 
this:

typealias Foo = Any
Any

I like the idea of composition as it allows us to factor out constraints.  If 
we are going to do that we should allow a class to be specified in the 
composition as long is it is a subclass of all class requirements of Any types 
it composes.  For example, this should be allowed:

typealias Bar = Any

This is still one class requirement for Bar, it just refines the class 
requirement of Foo to be SubclassOfSomeClass rather than just SomeClass.

> Example: Any
> "Any UIViewController or subclass which also satisfies the table view data 
> source and delegate protocols"
> Dynamic protocol. This is entirely composed of the name of a protocol which 
> has no associated types or Self requirement.
> Example: Any
> "Any type which conforms to both the CustomStringConvertible and BooleanType 
> protocols"
> 
> I'm going to use 'static protocol' to refer to a protocol with associated 
> types or self requirements. Feel free to propose a more sound name.
> 
> Self-contained static protocol, simple. This is composed of the name of a 
> static protocol, optionally followed by a 'where' clause in which the 
> associated types can be constrained (with any of the three basic conformance 
> types: subclassing, protocol conformance, or type equality). Associated types 
> are referred to with a leading dot.
Please do not introduce terms “dynamic protocol” and “static protocol”.  We 
want to support existentials of protocols that have self or associated type 
requirements.  The dynamic vs static distinction is a limitation of the current 
implementation of Swift and doesn’t make sense for the long term vision.

> 
> Example: Any .Generator.Element : SomeProtocol>
> "Any type that is a Collection, whose elements are NSObjects or their 
> subclasses conforming to SomeProtocol.”

Swift does not allow disjunction of requirements.  Only conjunctions are 
supported.  That means the correct reading is:

"Any type that is a Collection, whose elements are NSObjects and their 
subclasses conforming to SomeProtocol.”

> 
> Bound static protocol. This is the same as a self-contained static protocol, 
> but with a leading " as " which binds the protocol to a generic 
> typealias. The name can be then be used in subsequent clauses to build 
> constraints.
> 
> Example: Any .IntegerLiteralType == T.Element>.
> "Any type that is a Collection, and also can be built from an integer 
> literal, in which the collection elements are the same type as the type of 
> the 

Re: [swift-evolution] [Idea] if let value!

[L Mihalkovic via swift-evolution]

interestingly enough, it looks like a truly simple task... the grammar has 2 
types of BindingKind at that location BK_Let and BK_Var, which means that a 
single shorthand notation will assume one of the other, which means that if it 
does assume one, then it better be explicit about it, or alternatively there 
ought to be 2 shorthands for the 2 binding kinds. i.e. :

if unwrapped_var  {
}

and 

if unwrapped_let  {
}

or perhaps even easier to express as:

if let!  {
   //  is unwrapped LET
}

and 

if var!  {
   //  is unwrapped VAR
}

>From what I could understand of the compiler, these would seem like localized 
>small scale changes, but unfortunately still entirely out of the scope of 3.0 
>( not to mention probably still not bringing the clarity chris identified as 
>main blocker).

Ideas like this one, that are both simple in scope but out of the main focus 
might still be worth collecting somewhere as a series of  “if you would like to 
get familiar with the compiler codebase to try and help at a future date with 
more serious items, we suggest that you look into finding the least intrusive 
way to implement any of these features.. we guaranty that there is a simple way 
to build them”. They might prove a good training ground for would be helpers.


Apologies for taking your time.
/LM


> On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope > > wrote:
>> 
>> I always thought a new keyword made more sense here:
>> 
>> if let rebind someValue { 
>>  //use shadowed unwrapped value in here
>> }
>> 
>> if let bind someValue {
>>  //use shadowed unwrapped value in here
>> }
>> 
>> 
>> if let unwrapped someValue {
>> 
>> }
>> 
>> Something along those lines?
> 
> I wouldn’t want to see something like this replace the existing `if let` 
> because it doesn’t handle cases where you bind a new name to the result of an 
> expression that returns an optional.
> 
> If we did consider something like this it would be simple syntactic sugar for 
> `if let x = x`.  Being syntactic sugar for something that is already not too 
> bad means it would need to be as concise as possible.  If you want to 
> advocate something like this, maybe consider just `if unwrap`:
> 
> if unwrap someValue {
> }
> 
> 
> 
>> 
>> Brandon
>> 
>> 
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>>> > wrote:
>>> 
>>> Here’s a idea, what if you could use a symbol to denote that you want the 
>>> same name used?
>>> 
>>> Here’s an interesting sign from music: 
>>> https://en.wikipedia.org/wiki/Repeat_sign 
>>> 
>>> 
>>> Then you can write (one) of these:
>>> 
>>> if let |: = mySomeValue {
>>>   // Use unwrapped
>>> }
>>> 
>>> if let mySomeValue = :| {
>>>   // Use unwrapped
>>> }
>>> 
>>> Not sure which one is more clear. Just a totally random idea! I’m not sure 
>>> about the above symbols, but it would help in other places too from memory 
>>> to not have to write the same variable name twice.
>>> 
 On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
> > wrote:
> 
> While I've sometimes (early on) wished for a shorter-hand syntax for that 
> construct, I've never been able to think of something that I thought was 
> better. I've gotten to the point where I don't particularly mind it 
> anymore.
> 
> Regarding the exclamation point specifically, seeing one of those in an 
> expression context says to me "this thing will die horribly if it is 
> nil/throws an error". Using it in this context where that's not the case 
> would probably go against users' expectations.
 
 Agree.  If we are going have syntax similar to pattern matching it should 
 be the same as pattern matching.  This would mean using ‘?' rather than 
 ‘!’.  However, we already have generalized pattern matching with `if case` 
 for that.  This topic has been debated extensively.
 
> 
> 
> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
> > wrote:
> On 17.05.2016 16:51, Johan Jensen wrote:
>  > This was one of the first and most commonly suggested ideas, when the 
> Swift
>  > Evolution mailing list first started.
>  > Chris Lattner sums it up
>  >
>   
> >
>  > in one of those threads:
> 

Re: [swift-evolution] Enhanced existential types proposal discussion

[Adrian Zubarev via swift-evolution]

+1 for extending my proposal and making `Any<>` even more a powerful beast. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution 
(swift-evolution@swift.org) schrieb:

I put together the skeleton of a proposal detailing enhancements to how 
associated types can be referenced in Swift 3+. It's certainly not ready for 
submission, but I think it gets across my ideas pretty well. Would love to 
gather feedback and especially improvements.

Be unsparing; whatever form this feature takes will profoundly affect how Swift 
developers program for years, so it needs to be done right.

See below:

Proposal

An existential type is defined using the "Any<...>" construct. Existential 
types can be nested.

The empty existential type "Any<>" is typealiased to 'Any'.

Within the angle brackets are zero or more 'clauses'. Clauses are separated by 
semicolons. (This is so commas can be used in where constraints, below. Better 
ideas are welcome. Maybe it's not necessary; we can use commas exclusively.)

There are five different possible clauses:

'class'. Must be the first clause, if present. Places a constraint on the 
existential to be any class type. (Implies: Only one can exist. Mutually 
exclusive with class name clause.)

(In the future a follow-up proposal should add in 'struct' or 'value' as a 
counterpart.)

Class name. Must be the first clause, if present. (Implies: Only one can exist. 
Mutually exclusive with 'class'.) Places a constraint on the existential (not 
really an existential anymore) to be an instance of the class, or one of its 
subclasses.
Example: Any
"Any UIViewController or subclass which also satisfies the table view data 
source and delegate protocols"
Dynamic protocol. This is entirely composed of the name of a protocol which has 
no associated types or Self requirement.

Example: Any
"Any type which conforms to both the CustomStringConvertible and BooleanType 
protocols"

I'm going to use 'static protocol' to refer to a protocol with associated types 
or self requirements. Feel free to propose a more sound name.

Self-contained static protocol, simple. This is composed of the name of a 
static protocol, optionally followed by a 'where' clause in which the 
associated types can be constrained (with any of the three basic conformance 
types: subclassing, protocol conformance, or type equality). Associated types 
are referred to with a leading dot.

Example: Any
"Any type that is a Collection, whose elements are NSObjects or their 
subclasses conforming to SomeProtocol."

Bound static protocol. This is the same as a self-contained static protocol, 
but with a leading " as " which binds the protocol to a generic 
typealias. The name can be then be used in subsequent clauses to build 
constraints.

Example: Any.
"Any type that is a Collection, and also can be built from an integer literal, 
in which the collection elements are the same type as the type of the integer 
used for the integer literal conformance."

There will be rules to prevent recursive nesting. For example, if generic 
typealiases are allowed, they cannot refer to each other in a circular manner 
(like how structs can't contain themeselves, and you can't create a cyclic 
graph of enums containing themselves).

How an existential can be used depends on what guarantees are provided by the 
clauses. For example, 'Any' can't be used for much; if there were 
any methods on Equatable that did not use the associated types at all you'd be 
able to call them, but that's about it. However, 'Any' would allow for == to be called on instances. (This is a stupid 
example, since Any is equivalent to 'String', 
but there are almost certainly useful examples one could come up with.)

In order of increasing 'power':
Don't constrain any associated types. You can pass around Anys, but 
that's about it.
Constrain associated types to conform to protocols.
Fully constrain associated types.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

I put together the skeleton of a proposal detailing enhancements to how
associated types can be referenced in Swift 3+. It's certainly not ready
for submission, but I think it gets across my ideas pretty well. Would love
to gather feedback and especially improvements.

Be unsparing; whatever form this feature takes will profoundly affect how
Swift developers program for years, so it needs to be done right.

See below:

*Proposal*

An existential type is defined using the "Any<...>" construct. Existential
types can be nested.

The empty existential type "Any<>" is typealiased to 'Any'.

Within the angle brackets are zero or more 'clauses'. Clauses are separated
by semicolons. (This is so commas can be used in where constraints, below.
Better ideas are welcome. Maybe it's not necessary; we can use commas
exclusively.)

There are five different possible clauses:


   - 'class'. Must be the first clause, if present. Places a constraint on
   the existential to be any class type. (Implies: Only one can exist.
   Mutually exclusive with class name clause.)


(In the future a follow-up proposal should add in 'struct' or 'value' as a
counterpart.)


   - Class name. Must be the first clause, if present. (Implies: Only one
   can exist. Mutually exclusive with 'class'.) Places a constraint on the
   existential (not really an existential anymore) to be an instance of the
   class, or one of its subclasses.

Example: Any
"Any UIViewController or subclass which also satisfies the table view data
source and delegate protocols"

   - Dynamic protocol. This is entirely composed of the name of a protocol
   which has no associated types or Self requirement.


Example: Any
"Any type which conforms to both the CustomStringConvertible and
BooleanType protocols"

I'm going to use 'static protocol' to refer to a protocol with associated
types or self requirements. Feel free to propose a more sound name.


   - Self-contained static protocol, simple. This is composed of the name
   of a static protocol, optionally followed by a 'where' clause in which the
   associated types can be constrained (with any of the three basic
   conformance types: subclassing, protocol conformance, or type equality).
   Associated types are referred to with a leading dot.


Example: Any
"Any type that is a Collection, whose elements are NSObjects or their
subclasses conforming to SomeProtocol."


   - Bound static protocol. This is the same as a self-contained static
   protocol, but with a leading " as " which binds the protocol to a
   generic typealias. The name can be then be used in subsequent clauses to
   build constraints.


Example: Any.
"Any type that is a Collection, and also can be built from an integer
literal, in which the collection elements are the same type as the type of
the integer used for the integer literal conformance."

There will be rules to prevent recursive nesting. For example, if generic
typealiases are allowed, they cannot refer to each other in a circular
manner (like how structs can't contain themeselves, and you can't create a
cyclic graph of enums containing themselves).

How an existential can be used depends on what guarantees are provided by
the clauses. For example, 'Any' can't be used for much; if there
were any methods on Equatable that did not use the associated types at all
you'd be able to call them, but that's about it. However, 'Any' would allow for == to be called on instances. (This
is a stupid example, since Any is
equivalent to 'String', but there are almost certainly useful examples one
could come up with.)

In order of increasing 'power':

   - Don't constrain any associated types. You can pass around
   Anys, but that's about it.
   - Constrain associated types to conform to protocols.
   - Fully constrain associated types.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

With semantic versioning, the API changes would require the next version to be 
called 3.0. The challenge is to not attach stability/maturity ‘feelings’ to 
semantic version numbers.

I don’t think people should attach meaning to Swift being 3.0 any more than 
they do to Chrome being 50.0

If we insist 3.0 is not just a sign of an incompatible API but a sign of 
maturity, then we will have no releases until the “maturity” feature-set gets 
in. Which means we will lose a great deal of real world use and feedback into 
language design and evolution.

-DW

> On May 17, 2016, at 12:05 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> I do agree with what you are saying, but in a way it seems to also be saying 
> that the version number set by Apple is a bit rushed. A language reaching 3.0 
> state and not having nailed down ABI stability sounds a lot different than 
> Swift 0.95 or Swift 1.5 being at the same state and I do not think it would 
> say anything bad about the language if it only hit 1.0 when it reaches ABI 
> stability. 
> 
> It would be sad if the argument were "people would not use Swift if it were 
> still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere 
> near the unstable mess KDE 4.0 was, but they had that very same justification 
> for using the 4.0 version number).
> 
> Sent from my iPhone
> 
>> On 17 May 2016, at 14:38, Rod Brown  wrote:
>> 
>> While on the face of it, you are correct, the goals have changed 
>> dramatically, I think you are being unfair.
>> 
>> Swift 3 initial scope was determined prior to the input of the Swift 
>> Evolution community, just as it was being Open Sourced. As we have explored 
>> the language in many discussions, it has been clear there are other areas of 
>> the language that needed clean and polish before a stable ABI can be 
>> established.
>> 
>> It appears that this work is more involved than the Swift Team initially 
>> envisioned. The fact they are open to changing timelines and ensuring we get 
>> fundamentals of the language sorted is a testament to their commitment to 
>> the quality of Swift as a whole.
>> 
>> Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
>> pipeline that both break source and change the language fundamentally. I 
>> think it's far too much to ask that they get this work done rushed, and also 
>> pile on ABI compatibility goals at the last minute. Do we really want to 
>> rush this and get it wrong?
>> 
>> I applaud the team in making a tough decision that these changes should come 
>> before we start working on the ABI.
>> 
>> - Rod
>> 
>>> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
  wrote:
 
 Quite sad we could not get into ABI stability for Swift 3... but are we 
 talking Swift 3.1 or 4.0?
>>> 
>>> 
>>> Disappointing is my first thought, in fact worrying. Two years after the 
>>> language was announced, the ABI is still not stable.
>>> 
>>> Of the original Swift 3 goals, it looks like many will not be met. There 
>>> were seven goals and only two are still in the Readme file[1]. On the 
>>> assumption that the other five were all dropped because they will not be 
>>> achieved in Swift 3, this looks like failure.
>>> 
>>> I’ve been following the evolution list on and off since it started and it 
>>> hasn’t felt like failure. In fact, it felt like important progress has been 
>>> made and the language will be hugely better for it, but I do hope that the 
>>> development team does take the opportunity to review the release in light 
>>> of the original goals to see if there are any opportunities to improve the 
>>> development process for the next release.
>>> 
>>> 
>>> [1] 
>>> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>>>  compared to 
>>> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
>>> 
>>> 
>>> 
 
 Sent from my iPhone
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I really would like to understand what you was trying to tell me. :) My English 
is a little rusty to understand every piece of someone's thought.

By any chance someone could propose your ideas as an enhancement/upgrade of my 
`Any<>` mechanism later on? I mean like Joe did with removing `.self` which 
implies the ability of parsing expressions after 'as' and 'is' instead of just 
types.

I’d update my document soon at let you guys have a quick look over it before 
I’ll submit a pull request. :)

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Mai 2016 bei 20:02:35, Douglas Gregor (dgre...@apple.com) schrieb:


On May 17, 2016, at 10:40 AM, Adrian Zubarev  
wrote:

You don’t seem to be tackling the case of “A Collection whose Element type is 
String”. If we’re generalizing the current “protocol<>” notion, why not make it 
as powerful as a generic signature, with the ability to specify same-type 
constraints and conformances on associated types?

- Doug

Which part of the manifesto did I left out? ^^ Could you provide a quick pseudo 
code example?

Do you mean something like `Any`? I’m not 
sure where I should consider such a scenario, maybe at future directions?

That’s the part I’m referring to, yes. I just realized that your proposal isn’t 
lifting the restrictions on protocols with Self types or associated types, so 
my suggestion doesn’t make sense for your proposal without a significant 
increase in scope.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 17, 2016, at 1:02 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>>> On May 17, 2016, at 10:40 AM, Adrian Zubarev 
>>>  wrote:
>>> 
>>> You don’t seem to be tackling the case of “A Collection whose Element type 
>>> is String”. If we’re generalizing the current “protocol<>” notion, why not 
>>> make it as powerful as a generic signature, with the ability to specify 
>>> same-type constraints and conformances on associated types?
>>> 
>>> - Doug
>> 
>> Which part of the manifesto did I left out? ^^ Could you provide a quick 
>> pseudo code example?
>> 
>> Do you mean something like `Any`? I’m 
>> not sure where I should consider such a scenario, maybe at future directions?
> 
> That’s the part I’m referring to, yes. I just realized that your proposal 
> isn’t lifting the restrictions on protocols with Self types or associated 
> types, so my suggestion doesn’t make sense for your proposal without a 
> significant increase in scope.

Another related issue is having the Any type conform to all of the protocols it 
contains (should be easier than here than in the general case since there are 
no Self or associated types).  Would that be appropriate to add or do you think 
that would be a separate proposal?

> 
>   - Doug
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 17, 2016, at 1:11 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> I'd like to take a shot at writing such a proposal. At some point improved 
> existential support will need to go through review, so we might as well.
> 

Really happy to see this get started.  I'm willing to help if you need it...

> Austin
> 
>> On Tue, May 17, 2016 at 11:02 AM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
 On May 17, 2016, at 10:40 AM, Adrian Zubarev 
  wrote:
 
 You don’t seem to be tackling the case of “A Collection whose Element type 
 is String”. If we’re generalizing the current “protocol<>” notion, why not 
 make it as powerful as a generic signature, with the ability to specify 
 same-type constraints and conformances on associated types?
 
 - Doug
>>> 
>>> Which part of the manifesto did I left out? ^^ Could you provide a quick 
>>> pseudo code example?
>>> 
>>> Do you mean something like `Any`? I’m 
>>> not sure where I should consider such a scenario, maybe at future 
>>> directions?
>> 
>> That’s the part I’m referring to, yes. I just realized that your proposal 
>> isn’t lifting the restrictions on protocols with Self types or associated 
>> types, so my suggestion doesn’t make sense for your proposal without a 
>> significant increase in scope.
>> 
>>  - Doug
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Small Enhancement Request for Swift Protocol

[Andrew Trick via swift-evolution]

> On May 14, 2016, at 7:49 AM, Sreejith K R via swift-evolution 
>  wrote:
> 
> Hello All,
> 
> 
> I would like to suggest an enhancement for the swift protocol would really 
> like this feature to be reviewed.
> 
> Enhancement Description : 
> 
> Currently it is not possible to invoke  the default implementation of a 
> particular protocol (EG: SampleProtocolParent achieved using protocol 
> extension)  inside   another protocol extention(Eg: SampleProtocolSub) that 
> inherits from the former protocol. Please look  into the SampleProtocolSub 
> extension as shown below. Also the same behavior is observed  while a class 
> implements the protocol(Please look  into the Test class that implements 
> SampleProtocolSub as shown below ). 
> 
>  This behavior is something similar to the usage of super keyword while 
> overriding a method. 
> 
> protocol SampleProtocolParent{
> func testFunction();
> 
> }
> extension SampleProtocolParent{
> func testFunction(){
> print("hello my super implementation")
> }
> 
> }
> protocol SampleProtocolSub:SampleProtocolParent{
> 
> 
> }
> 
> extension SampleProtocolSub{
> func testFunction(){
>/* need to call testFunction implementation of the parent 
> SampleProtocolParent as well here. Is this a possible feature  ?*/
> print("hello my current and new implementation")
> }
> 
> }
> 
> class Test:SampleProtocolSub{
> func testFunction(){
> 
> /* need to call testFunction implmentaion of the parent 
> SampleProtocolParent as well here. Is this a possible feature  ?*/
> print("hello my current and new new new implementaion")
> }
> }

I also want this feature, but haven’t seen any proposed syntax.
-Andy

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

[Due to popular demand ;-) in the discussion of SE-0084: Allow trailing commas 
in parameter lists and tuples]

The option to skip semicolons for statements followed by a newline is only a 
tiny convinience, yet it is one of the most favored differences to C (and one 
of the most annoying things to remember when you have to switch from Swift to 
do some coding in Objective-C).
While lists of statements don't need a special separator character anymore, 
other lists still rely on commas to separate items:
- method parameters
- array and dictionary literals
- tuples
[anything else?]

SE-0084 targets to make it easier to reorder list elements by allowing an 
additional comma after the last element; afaics, the same can be achieved by 
making all of those commas optional, as long as there is a newline to separate 
the next item (without those newlines, SE-0084 makes less sense as well).

This change is not incompatible with SE-0084, but imho it doesn't make much 
sense to combine those features (at least in actual source code).

So, first question:
What are the downsides of this change? (question zero is "are there any other 
places where comma-separeted lists could be turned into newline-separated 
lists?"...)

Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

I do agree with what you are saying, but in a way it seems to also be saying 
that the version number set by Apple is a bit rushed. A language reaching 3.0 
state and not having nailed down ABI stability sounds a lot different than 
Swift 0.95 or Swift 1.5 being at the same state and I do not think it would say 
anything bad about the language if it only hit 1.0 when it reaches ABI 
stability. 

It would be sad if the argument were "people would not use Swift if it were 
still v0.9" as it brings back memories of the KDE 4.0 jump (Swift is nowhere 
near the unstable mess KDE 4.0 was, but they had that very same justification 
for using the 4.0 version number).

Sent from my iPhone

> On 17 May 2016, at 14:38, Rod Brown  wrote:
> 
> While on the face of it, you are correct, the goals have changed 
> dramatically, I think you are being unfair.
> 
> Swift 3 initial scope was determined prior to the input of the Swift 
> Evolution community, just as it was being Open Sourced. As we have explored 
> the language in many discussions, it has been clear there are other areas of 
> the language that needed clean and polish before a stable ABI can be 
> established.
> 
> It appears that this work is more involved than the Swift Team initially 
> envisioned. The fact they are open to changing timelines and ensuring we get 
> fundamentals of the language sorted is a testament to their commitment to the 
> quality of Swift as a whole.
> 
> Looking at Swift 3 as compared to Swift 2, there are massive changes in the 
> pipeline that both break source and change the language fundamentally. I 
> think it's far too much to ask that they get this work done rushed, and also 
> pile on ABI compatibility goals at the last minute. Do we really want to rush 
> this and get it wrong?
> 
> I applaud the team in making a tough decision that these changes should come 
> before we start working on the ABI.
> 
> - Rod
> 
>> On 17 May 2016, at 10:35 PM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> Quite sad we could not get into ABI stability for Swift 3... but are we 
>>> talking Swift 3.1 or 4.0?
>> 
>> 
>> Disappointing is my first thought, in fact worrying. Two years after the 
>> language was announced, the ABI is still not stable.
>> 
>> Of the original Swift 3 goals, it looks like many will not be met. There 
>> were seven goals and only two are still in the Readme file[1]. On the 
>> assumption that the other five were all dropped because they will not be 
>> achieved in Swift 3, this looks like failure.
>> 
>> I’ve been following the evolution list on and off since it started and it 
>> hasn’t felt like failure. In fact, it felt like important progress has been 
>> made and the language will be hugely better for it, but I do hope that the 
>> development team does take the opportunity to review the release in light of 
>> the original goals to see if there are any opportunities to improve the 
>> development process for the next release.
>> 
>> 
>> [1] 
>> https://github.com/apple/swift-evolution/blob/d6e62467b03435bdc4b3bd473c3dcffb9fdd6a71/README.md
>>  compared to 
>> https://github.com/apple/swift-evolution/blob/f11d2e970521f5df0f7510f89ee9c7decb3fa394/README.md
>> 
>> 
>> 
>>> 
>>> Sent from my iPhone
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Douglas Gregor via swift-evolution]

> On May 17, 2016, at 10:40 AM, Adrian Zubarev 
>  wrote:
> 
>> You don’t seem to be tackling the case of “A Collection whose Element type 
>> is String”. If we’re generalizing the current “protocol<>” notion, why not 
>> make it as powerful as a generic signature, with the ability to specify 
>> same-type constraints and conformances on associated types?
>> 
>> - Doug
> 
> Which part of the manifesto did I left out? ^^ Could you provide a quick 
> pseudo code example?
> 
> Do you mean something like `Any`? I’m not 
> sure where I should consider such a scenario, maybe at future directions?

That’s the part I’m referring to, yes. I just realized that your proposal isn’t 
lifting the restrictions on protocols with Self types or associated types, so 
my suggestion doesn’t make sense for your proposal without a significant 
increase in scope.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

You don’t seem to be tackling the case of “A Collection whose Element type is 
String”. If we’re generalizing the current “protocol<>” notion, why not make it 
as powerful as a generic signature, with the ability to specify same-type 
constraints and conformances on associated types?

- Doug

Which part of the manifesto did I left out? ^^ Could you provide a quick pseudo 
code example?

Do you mean something like `Any`? I’m not 
sure where I should consider such a scenario, maybe at future directions?

If you’d like me to think about some specific cases I may have missed, I’d be 
happy if you could point the right reading (or specific section of it). 

If `Any<>` could get more powerful so let it be. :)

I’m about to rewrite a few things to match `Any<>`.

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andru Felipe Zuniga via swift-evolution]

It would be useful for clarification of a computed property being constant in 
extensions. For example:

extension SKSpriteNode {
static let type: String {
return “Sprite”
}
}

Andru



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Is SE-0088 (Modernize libdispatch for Swift 3 naming conventions) open for comments?

[Josh Osborne via swift-evolution]

I see the active review dates of May 10 to 17, but I don’t see any messages 
about it on here.

If comments are welcome at this time, read on.   If not, please remind me what 
the process is (and maybe read on anyway?)!

Interoperation:
  If I have an existing ObjC (or just C) code baae that uses 
dispatch_get_specific, how does it interoperate with Swift code and 
DispatchSpecificKey?   How do I annotate my void* keys to bridge them into 
Swift?  (I don’t know of any library that used dispatch keys in API, but I do 
know of plenty that use them internally and it would hinder Swift migration to 
have an all-or-nothing migration here!)


Apparently Incomplete (perfectly understandable if I’m jumping the gun and 
commenting early):

DispatchGroup:
  I can see it has been renamed, and what the equivalent of 
dispatch_group_async is, but I don’t see dispatch_group_wait or 
dispatch_group_notify’s new names anywhere.

DispatchSemaphore:
  Again I see the new name, but I don’t see 

Bikeshed:
  queue.asynchronously(…) oh dear god so much typing…um, I mean, er, “async is 
a term of art, and perfectly appropriate here”
  queue.synchronously(…) yeah, that is a lot of letters…and “sync” is a 
perfectly fine term of art, can we use it?

Color Me Impressed:
  “ all without adding runtime overhead” and we have the 
DispatchQueue.asynchronously taking 3 arguments with default values.   Can the 
Swift compiler really turn a call with all the arguments in the default state 
into a dispatch_async call without runtime overhead of checking for 
nil/.unspecified, and []?  (not “can” = “sure, someday”, but “yeah, it does 
that sort of thing, maybe even here”)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea] "guard not let" optional binding

[John Morgan via swift-evolution]

I've occasionally hit this problem but I don’t think this warrants a
language addition, as it can be overcome in other ways. I would move the
expensive calculation into its own private method and rewrite your example
like this:

return cachedValue ?? calculatedValue()

In my opinion that would fit better with the single responsibility
principle and make unit testing easier.

John

> -1 as there IMO some confusion between all these `not` and `else` and the
> meaning of the expression at all is not obvious for me: "check that not
> allowed to assign _someExpensiveResult to some instance cachedValue,
> otherwise return something"
>
> This really looks nice, clean and obvious :
>
> guard cachedValue == nil else {
> // here you need just to fast return unwrapped value of cachedValue
> // so, IMO unwrapping it in this block is OK
> return cachedValue!
> }
> // here you want to have cachedValue == nil, so you'll need to unwrap
> it(after assignment) in any case.
>
> What I can see as improvement in this direction, something like this:
> guard cachedValue == nil else let cachedValue! {
> // here you can use unwrapped cachedValue
> return cachedValue
> }
>
>
> Hmm... Btw, what about improving in optional binding: It is common to
> shadow optional value name with unwrapped value with same name:
>
> if let value = value {...} // too much noise
>
> What about introduce such syntax:
>
> if let value! {
> // unwrapped value here
> }
>
> Seems like clear and obvious about what does this mean. Opinions? (before
I
> drop this to separate thread)
>
>
> On 14.05.2016 8:52, Karl via swift-evolution wrote:
> > If we want to check that an optional has a value and bail if it
doesn't, we have the helpful pattern:
> >
> > guard let x = x else { throw SomeError }
> >
> > However, it is also fairly common that you want to check that an
optional *is* nil, and still bail if it isn’t (maybe using the value that
you now know exists), e.g:
> >
> > guard cachedValue == nil else { return cachedValue! }
> > cachedValue = //… expensive calculation
> >
> > It seems a little bit “unfair” that we have this lovely clean `let`
syntax when checking for Optional.Some, but we to have to do this ugly
manual check against nil and explicit unwrap when checking for
Optional.None. There is literally no other way to satisfy the guard
statement; our optional bindings only go one-way can’t be evaluated.
> >
> > What about if we introduced a “not” modifier to optional bindings?
> >
> > guard not let cachedValue = _someExpensiveResult else { return
cachedValue }
> >
> > This obviously wouldn’t make sense for “if let…” switching, as the
variables get bound in the ‘else’ block and the code wouldn’t be very
readable. For the special case of a guard statement, though, which only has
an ‘else’ block, it does make some sense.
> >
> > If we had something like this, certainly in my code, I’d be able to
eliminate almost all (maybe even all) remaining force-unwraps of optionals;
that’s great! It’d be amazing if the language was expressive enough that
you could go without ever having to force-unwrap an optional. And it just
makes sense.
> >
> > Thoughts?
> >
> > Karl
> > ___
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Small Enhancement Request for Swift Protocol

[Sreejith K R via swift-evolution]

Hello All,


I would like to suggest an enhancement for the swift protocol would really
like this feature to be reviewed.

Enhancement Description :

Currently it is not possible to invoke  the default implementation of a
particular protocol (EG: SampleProtocolParent achieved using protocol
extension)  inside   another protocol extention(Eg: SampleProtocolSub) that
inherits from the former protocol. Please look  into the SampleProtocolSub
extension as shown below. Also the same behavior is observed  while a class
implements the protocol(Please look  into the Test class that implements
SampleProtocolSub as shown below ).

 This behavior is something similar to the usage of super keyword while
overriding a method.

protocol SampleProtocolParent{
func testFunction();

}
extension SampleProtocolParent{
func testFunction(){
print("hello my super implementation")
}

}
protocol SampleProtocolSub:SampleProtocolParent{


}

extension SampleProtocolSub{
func testFunction(){
   /* need to call testFunction implementation of the parent
SampleProtocolParent as well here. Is this a possible feature  ?*/
print("hello my current and new implementation")
}

}

class Test:SampleProtocolSub{
func testFunction(){

/* need to call testFunction implmentaion of the parent
SampleProtocolParent as well here. Is this a possible feature  ?*/
print("hello my current and new new new implementaion")
}
}

Thanks,
Sreejith K R
KonyDeveloperGroup

Mobile Dev Blog 
Linkedin 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Support for coding styles and "swift-format" tool

[Daniel Martín via swift-evolution]

As Swift is getting traction in more and more platforms outside of 
Apple, we can expect that many coding styles different from what Apple 
imposes with SourceKit's indenting rules will emerge. According to 
https://bugs.swift.org/browse/SR-146, we now have decoupled indenting 
logic from SourceKit into its own library, and a "swift-format" tool is 
in the making.


I am working on adding support for different coding styles to libIDE. 
For example, with my changes you could decide how a case label should be 
indented with respect to its parent switch context, among other things. 
The current, hard coded indenting decisions in libIDE could be named the 
"Apple" style, just like Clang supports Google, LLVM, Mozilla, coding 
styles for C++. Also, this is something that can be supported by 
external tools like Xcode quite easily.


Do you think this is a good feature to have?

--
Daniel Martín
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Make access control private by default.

[Knut Lorenzen via swift-evolution]

I think internal as default is bad, because it discourages encapsulation.

Building scalable software components relies on hiding implementation details 
to create layers of abstraction. It’s a fundamental principle of 
object-oriented software design. Most other OOP languages have private default.

The linked doc doesn’t explain the advantages of internal as default in detail:

> By default, most entities in a source file have internal access. This 
> optimizes for the most common case—a single-target 
> application project—while not accidentally revealing entities to clients of a 
> framework module.

Optimizes for what? Build time? Brevity?

Knut

> Have your read
> https://github.com/apple/swift/blob/master/docs/AccessControl.rst?
> 
> I prefer the current rationale behind "internal" by default.
> 
> Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[David Waite via swift-evolution]

I don’t think the API of types have to be bulletproof from the start, but it 
shouldn’t have core usage limitations based on Objective C. One example would 
be if I have to deal with NSNumber/NSString/NSArray/NSDictionary to fully use 
the API, such as NSAttributedString or NSError.

The issue is that Foundation is both the objective-c compatibility base and the 
cross-platform foundational library for Swift. These goals conflict. Without an 
idea of how the Swift flavor of Foundation will evolve in the future to deal 
with this conflict, it is hard to evaluate this other than saying “will be 
confusing why some Objective-C things have prefixes and others don’t” and “will 
cause conflicts with non-Apple foundational libraries”.

-DW


> On May 17, 2016, at 7:41 AM, Matt Whiteside via swift-evolution 
>  wrote:
> 
> I meant to say that it sounds like a good idea to leave the ’NS’ prefix on 
> types that were auto-translated, and remove it from those that have been 
> rewritten by hand for swift.
> 
> -Matt
> 
>> On May 16, 2016, at 21:24, Matt Whiteside > > wrote:
>> 
>> This sounds like a good idea.
>> 
>> -Matt
>> 
>>> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution 
>>> > wrote:
>>> 
>>> 
 Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution 
 >:
 
 
> What is your evaluation of the proposal?
 Personally I’m a -1; I’d prefer to see the NS prefix remain on types that 
 have been translated automatically with minimal human interaction, in 
 favour of dropping the prefix for types that have received more attention 
 to establish a Swift-ier style, but migrating these into a new module 
 instead.
>>> 
>>> I strongly agree with keeping NS prefix on API that has not been 
>>> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. 
>>> Second step, systematically improve Foundation to the point where it feels 
>>> like this fundamental part of the language is as easy to use and idiomatic 
>>> as the standard library itself. At that point I’d be very much for dropping 
>>> the prefixes.
>>> 
 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
 Since it’s a basic API that most developers will be interacting with then 
 yes, even though the change is fairly minor, it definitely bears 
 consideration.
 
> Does this proposal fit well with the feel and direction of Swift?
 Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at 
 the same time this is why I’d like to keep the current convention for 
 existing (unchanged) types, as it makes it much clearer that these are 
 things that weren’t originally designed for Swift and thus won’t behave 
 quite as you might expect.
>>> 
>>> Completely agree
>>> 
 
> If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
 I’ve worked in languages where libraries had different styles of 
 name-spacing, and while it was annoying to have a mixture, I think it was 
 fine, especially for libraries that are older, as the prefix name-spacing 
 style makes it absolutely clear that this is an older API.
 
>>> 
>>> Yes, we should be clear this is an older API, also to add motivation on 
>>> introducing a more modern one (even if at first it just wraps Foundation 
>>> with a more Swift-like API)
>>> 
> How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
 
 Quick read of the proposal, kept an eye on the discussion leading up to it 
 though.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Douglas Gregor via swift-evolution]

> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> So basically everyone start to like by the core team suggested `Any<>` name 
> of the proposed mechanism. I’ll rename it when I get home. ;)

Definitely happy to see this proposal being discussed (and happier if it uses 
“Any<>” :)).

> 
>> I don't think Either is a good name.  That implies 2 cases (either this or 
>> that).  Maybe 'OneOf' would be better.
> 
> Since that might be or be not a different proposal some day I guess we’d be 
> safe to call it `OneOf` for the time being.
> 
> Would you mind to go over the rules I suggested? Do we need the ability to 
> provide multiple reference/value types? I’d say no we don’t, to reduce 
> confusion (see my proposal).
> 
> https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-mechanism-to-combine-types-and-protocols.md
>  
> 
You don’t seem to be tackling the case of “A Collection whose Element type is 
String”. If we’re generalizing the current “protocol<>” notion, why not make it 
as powerful as a generic signature, with the ability to specify same-type 
constraints and conformances on associated types?

- Doug

> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Mai 2016 bei 15:34:10, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On May 17, 2016, at 5:12 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
 But don't you mean the union type of all possible Collection types when 
 you write Any?
 
 I suggested `all<>` for the intersection type, and `any<>` for the union 
 type, so that would be the same, wouldn't it?
>>> 
>>> Thats exactly how I understand out situation by now. I was confused by 
>>> Thorsten's `intersection` first, but now I see that he meant the 
>>> intersection between dynamic type and the whole set of constraints provided 
>>> by `All<…>`. I thought about about the constraints union compared to the 
>>> dynamic type, which is most likely the same thing.
>>> 
>>> In my proposal I reserved the name `Any<>` for future directions, but noted 
>>> that we still might choose `Any<…>` for the proposed `All<…>` and then name 
>>> `Any<…>` described by Thorsten as `Either<…>`.
>>> 
>> 
>> I agree with Brent's concept of Any.  That feels Swifty, following the 
>> convention established by the type-erasing wrappers currently in the 
>> standard library.  
>> 
>> I don't think Either is a good name.  That implies 2 cases (either this or 
>> that).  Maybe 'OneOf' would be better.
>>> 
  >> We've been over this a few times before on the list. I personally like 
 naming this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", 
 and "AnySequence". I also see Thorsten (and in the past Brent's?) argument 
 for calling it "all" or "All", because it's enforcing multiple constraints.
>>> 
 > 
 > I have suggested `all<>` in the past, but I now favor `Any`, because 
 > that allows it to be unified with the universal supertype `Any`, 
 > `Any`, and things like `Any` to forge the One 
 > Existential Syntax to rule them all.
>>> 
>>> I considered `Any<>` as an alternative and personally I don’t have anything 
>>> against that little change. I still don’t like `AnyObject` because it uses 
>>> `Object` instead of `Class`, where `AnyClass` is `AnyObject.Type`. This is 
>>> way to confusing if you ask me. I’d rename both into `ClassInstance` == 
>>> `AnyObject` and `ClassType` == `AnyClass`. If Swift one day might introduce 
>>> `struct` and `enum` keywords that are generalized like `class` (could be) 
>>> what name would you choose? Compared to `AnyClass` typealias `AnyStruct` 
>>> would be `AnyXYZ.Type`. The only type I like which uses `Any` as its prefix 
>>> is `Any` itself. 
>>> 
>>> But I guess this is something the core team will decide.
>>> 
>>> If there is no feedback towards the document I wrote anymore, I’ll submit a 
>>> pull request later this day. (Note: I’ll add some small changes in the 
>>> alternatives section about dropping the restriction of a single 
>>> reference/value type within the angle brackets).
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 17. Mai 2016 bei 07:17:21, Thorsten Seitz via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 

Re: [swift-evolution] [Idea] if let value!

[Austin Zheng via swift-evolution]

A case can be made, of course. My personal opinion is that I don't want to see 
it in the language at any point. Others are free to agree or disagree.

Austin

> On May 17, 2016, at 9:21 AM, Matthew Johnson  wrote:
> 
> 
>> On May 17, 2016, at 11:18 AM, Austin Zheng  wrote:
>> 
>>> 
>>> If people really want to pursue further sugar here I think it would be 
>>> worthwhile to explore a direction that hasn’t already been debated 
>>> extensively.  That is why I suggested thinking about `if unwrap`.  That 
>>> said, I really don’t think current state is too bad.  It’s definitely not 
>>> worth expending community energy on this when we clearly have more 
>>> important things to focus on (like completing generics and ABI).
>>> 
>> 
>> 
>> I agree with Matthew. A marginal increase in developer convenience is, to 
>> me, not worth the additional complexity of special purpose syntax.
> 
> I think it’s fair to make a case for the special purpose syntax (which may or 
> may not be accepted).  I just don’t think now is the right time to have a 
> debate about it.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

On 17.05.2016 19:08, Matthew Johnson wrote:

it might be worth looking at other aspects of how your code is structured.


All is good, if it is in *my* code ;-) But I often see this pattern in 
*others* code and I don't want to see it in others code :-)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 11:18 AM, Austin Zheng  wrote:
> 
>> 
>> If people really want to pursue further sugar here I think it would be 
>> worthwhile to explore a direction that hasn’t already been debated 
>> extensively.  That is why I suggested thinking about `if unwrap`.  That 
>> said, I really don’t think current state is too bad.  It’s definitely not 
>> worth expending community energy on this when we clearly have more important 
>> things to focus on (like completing generics and ABI).
>> 
> 
> 
> I agree with Matthew. A marginal increase in developer convenience is, to me, 
> not worth the additional complexity of special purpose syntax.

I think it’s fair to make a case for the special purpose syntax (which may or 
may not be accepted).  I just don’t think now is the right time to have a 
debate about it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

On 17.05.2016 18:58, Matthew Johnson wrote:

That said, I really don’t think current state is too bad.  It’s
definitely not worth expending community energy on this when we clearly
have more important things to focus on (like completing generics and
ABI).


Well.. Although I agree that this is not 'big deal' feature, I believe it 
will slightly improve the experience of coding in Swift, similar to other 
small features.


Must we stop to discuss anything else than "completing generics and ABI"?
Or it is worth to discuss interesting features even if it will not be 
included in Swift 3.0 ? (I.e. probably can be included in later versions).

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Austin Zheng via swift-evolution]

> 
> If people really want to pursue further sugar here I think it would be 
> worthwhile to explore a direction that hasn’t already been debated 
> extensively.  That is why I suggested thinking about `if unwrap`.  That said, 
> I really don’t think current state is too bad.  It’s definitely not worth 
> expending community energy on this when we clearly have more important things 
> to focus on (like completing generics and ABI).
> 


I agree with Matthew. A marginal increase in developer convenience is, to me, 
not worth the additional complexity of special purpose syntax.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 11:06 AM, Vladimir.S  wrote:
> 
> On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote:
>> Being syntactic sugar for something that is already not too bad
> 
> Well.. Personally I feel like construction `if let someMyValue = someMyValue` 
> is bad exactly because of this the same repeated name. Anywhere I see 
> repeated code, I feel like this is not good.

I generally agree, but it’s pretty trivial repetition in this case.  And like 
others have noted, if you need to do this often it might be worth looking at 
other aspects of how your code is structured.

> 
>> means it
>> would need to be as concise as possible.  If you want to advocate something
>> like this, maybe consider just `if unwrap`:
>> 
>> if unwrap someValue {
>> }
>> 
> 
> Yes, IMO the best idea for this feature for this moment. Clear and explicit. 
> Why not?

If immediate consensus forms, sure why not?  But I don’t think it’s worth 
extended discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

Regards
LM
(From mobile)

> On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope  wrote:
>> 
>> I always thought a new keyword made more sense here:
>> 
>> if let rebind someValue { 
>>  //use shadowed unwrapped value in here
>> }
>> 
>> if let bind someValue {
>>  //use shadowed unwrapped value in here
>> }
>> 
>> 
>> if let unwrapped someValue {
>> 
>> }
>> 
>> Something along those lines?
> 
> I wouldn’t want to see something like this replace the existing `if let` 
> because it doesn’t handle cases where you bind a new name to the result of an 
> expression that returns an optional.
> 
> If we did consider something like this it would be simple syntactic sugar for 
> `if let x = x`.  Being syntactic sugar for something that is already not too 
> bad means it would need to be as concise as possible.  If you want to 
> advocate something like this, maybe consider just `if unwrap`:
> 
> if unwrap someValue {
> }
> 
> 

+25. Will look at the parser to see what the impl cost is (although chris has 
clearly stated that pure sugaring is not yet on the agenda to prevent creating 
cruft rather than addressing the root causes)


> 
>> 
>> Brandon
>> 
>> 
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>>>  wrote:
>>> 
>>> Here’s a idea, what if you could use a symbol to denote that you want the 
>>> same name used?
>>> 
>>> Here’s an interesting sign from music: 
>>> https://en.wikipedia.org/wiki/Repeat_sign
>>> 
>>> Then you can write (one) of these:
>>> 
>>> if let |: = mySomeValue {
>>>   // Use unwrapped
>>> }
>>> 
>>> if let mySomeValue = :| {
>>>   // Use unwrapped
>>> }
>>> 
>>> Not sure which one is more clear. Just a totally random idea! I’m not sure 
>>> about the above symbols, but it would help in other places too from memory 
>>> to not have to write the same variable name twice.
>>> 
> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> While I've sometimes (early on) wished for a shorter-hand syntax for that 
> construct, I've never been able to think of something that I thought was 
> better. I've gotten to the point where I don't particularly mind it 
> anymore.
> 
> Regarding the exclamation point specifically, seeing one of those in an 
> expression context says to me "this thing will die horribly if it is 
> nil/throws an error". Using it in this context where that's not the case 
> would probably go against users' expectations.
 
 Agree.  If we are going have syntax similar to pattern matching it should 
 be the same as pattern matching.  This would mean using ‘?' rather than 
 ‘!’.  However, we already have generalized pattern matching with `if case` 
 for that.  This topic has been debated extensively.
 
> 
> 
>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
>>  wrote:
>> On 17.05.2016 16:51, Johan Jensen wrote:
>>  > This was one of the first and most commonly suggested ideas, when the 
>> Swift
>>  > Evolution mailing list first started.
>>  > Chris Lattner sums it up
>>  >
>> 
>>  > in one of those threads:
>>  >
>>  >> This is commonly requested - the problem is that while it does help
>>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>>  >
>>  > — Johan
>> 
>> Oh, thank you for letting this know.
>> 
>> Well, I totally disagree with Chris. And as soon as there was no 
>> 'official'
>> proposal and 'official' decision, I'd like to discuss this more.
>> 
>> I saw a lot of code like
>> if let mySomeValue = mySomeValue {} in sources and even in books.
>> Plus, I really believe that
>> if let mySomeValue! {..} is better in any way: readability, less space 
>> for
>> errors(when you need to repeat the same name) etc
>> 
>> FWIW, I suggest more explicit variant:
>> if let value! {...} // with exclamation mark
>> In that "old" proposal there was `if let value {...}`, was not so clear.
>> 
>> I can't accept an argument that you can use another name - as usually
>> 'good' name is already 'crafted' for the instance and you want to use it 
>> in
>> next code.
>> Otherwise, we need a 'best practice' to name optional variables with some
>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>> use such approach.
>> Additionally, when you shadow optional value 

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote:

 Being syntactic sugar for something that is already not too bad


Well.. Personally I feel like construction `if let someMyValue = 
someMyValue` is bad exactly because of this the same repeated name. 
Anywhere I see repeated code, I feel like this is not good.



means it
would need to be as concise as possible.  If you want to advocate something
like this, maybe consider just `if unwrap`:

if unwrap someValue {
}



Yes, IMO the best idea for this feature for this moment. Clear and 
explicit. Why not?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:50 AM, Vladimir.S  wrote:
> 
> Could you clarify how to use `if case` to achieve the same target as proposed 
> `if let value!` ?
> (btw, probably `if let value? {..}` will be better)

You don’t get the same implicit match that this idea proposes, but you do get 
the full power of pattern matching.  And you get to use the ? pattern. 

let i: Int? = 42
if case let i? = i {
}

The differences in the suggestion here is to allow you to drop case and 
implicitly match on the value currently bound to the name in the pattern, 
rebinding using the pattern if a match happens.

If people really want to pursue further sugar here I think it would be 
worthwhile to explore a direction that hasn’t already been debated extensively. 
 That is why I suggested thinking about `if unwrap`.  That said, I really don’t 
think current state is too bad.  It’s definitely not worth expending community 
energy on this when we clearly have more important things to focus on (like 
completing generics and ABI).

> 
> On 17.05.2016 18:18, Matthew Johnson wrote:
>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
>>> > wrote:
>>> 
>>> While I've sometimes (early on) wished for a shorter-hand syntax for that
>>> construct, I've never been able to think of something that I thought was
>>> better. I've gotten to the point where I don't particularly mind it anymore.
>>> 
>>> Regarding the exclamation point specifically, seeing one of those in an
>>> expression context says to me "this thing will die horribly if it is
>>> nil/throws an error". Using it in this context where that's not the case
>>> would probably go against users' expectations.
>> 
>> Agree.  If we are going have syntax similar to pattern matching it should
>> be the same as pattern matching.  This would mean using ‘?' rather than
>> ‘!’.  However, we already have generalized pattern matching with `if case`
>> for that.  This topic has been debated extensively.
>> 
>>> 
>>> 
>>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution
>>> > wrote:
>>> 
>>>On 17.05.2016 16:51, Johan Jensen wrote:
>>> > This was one of the first and most commonly suggested ideas, when
>>>the Swift
>>> > Evolution mailing list first started.
>>> > Chris Lattner sums it up
>>> >
>>>
>>> 
>>> > in one of those threads:
>>> >
>>> >> This is commonly requested - the problem is that while it does help
>>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>>> >
>>> > — Johan
>>> 
>>>Oh, thank you for letting this know.
>>> 
>>>Well, I totally disagree with Chris. And as soon as there was no
>>>'official'
>>>proposal and 'official' decision, I'd like to discuss this more.
>>> 
>>>I saw a lot of code like
>>>if let mySomeValue = mySomeValue {} in sources and even in books.
>>>Plus, I really believe that
>>>if let mySomeValue! {..} is better in any way: readability, less
>>>space for
>>>errors(when you need to repeat the same name) etc
>>> 
>>>FWIW, I suggest more explicit variant:
>>>if let value! {...} // with exclamation mark
>>>In that "old" proposal there was `if let value {...}`, was not so clear.
>>> 
>>>I can't accept an argument that you can use another name - as usually
>>>'good' name is already 'crafted' for the instance and you want to use
>>>it in
>>>next code.
>>>Otherwise, we need a 'best practice' to name optional variables with some
>>>prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>>>mySomeValueOpt` will have a sense. But as I understand, we don't want to
>>>use such approach.
>>>Additionally, when you shadow optional value with same name - you are
>>>*protecting* yourself from using optional value inside block of unwrapped
>>>code. IMO it is a good idea.
>>>And want we or don't want, we already have this practice widely. So I
>>>believe this(my) proposal will improve the code.
>>> 
>>>I'd like to get opinion of the community regarding this feature.
>>> 
>>>On 17.05.2016 16:51, Johan Jensen wrote:
>>>> This was one of the first and most commonly suggested ideas, when
>>>the Swift
>>>> Evolution mailing list first started.
>>>> Chris Lattner sums it up
>>>>
>>>
>>> 
>>>> in one of those threads:
>>>>
>>>>> This is commonly requested - the problem is that while it does help
>>>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>>>
>>>> — Johan
>>>>
>>>> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>>>> 

Re: [swift-evolution] [Idea] if let value!

[Brandon Knope via swift-evolution]

It’s not just about being concise, but reducing repeated code:

It would be syntactic sugar for this:
if case .Some(let optional) = optional {

}

But yes, unwrap makes much more sense.

At the end of the day, I am not too bothered by if let syntax, but if we could 
clear up some of the repetitive code and all the =’s while still remaining 
clear, I would not oppose it!

Brandon

> On May 17, 2016, at 11:48 AM, Matthew Johnson  wrote:
> 
> 
>> On May 17, 2016, at 10:41 AM, Brandon Knope > > wrote:
>> 
>> I always thought a new keyword made more sense here:
>> 
>> if let rebind someValue { 
>>  //use shadowed unwrapped value in here
>> }
>> 
>> if let bind someValue {
>>  //use shadowed unwrapped value in here
>> }
>> 
>> 
>> if let unwrapped someValue {
>> 
>> }
>> 
>> Something along those lines?
> 
> I wouldn’t want to see something like this replace the existing `if let` 
> because it doesn’t handle cases where you bind a new name to the result of an 
> expression that returns an optional.
> 
> If we did consider something like this it would be simple syntactic sugar for 
> `if let x = x`.  Being syntactic sugar for something that is already not too 
> bad means it would need to be as concise as possible.  If you want to 
> advocate something like this, maybe consider just `if unwrap`:
> 
> if unwrap someValue {
> }
> 
> 
> 
>> 
>> Brandon
>> 
>> 
>>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>>> > wrote:
>>> 
>>> Here’s a idea, what if you could use a symbol to denote that you want the 
>>> same name used?
>>> 
>>> Here’s an interesting sign from music: 
>>> https://en.wikipedia.org/wiki/Repeat_sign 
>>> 
>>> 
>>> Then you can write (one) of these:
>>> 
>>> if let |: = mySomeValue {
>>>   // Use unwrapped
>>> }
>>> 
>>> if let mySomeValue = :| {
>>>   // Use unwrapped
>>> }
>>> 
>>> Not sure which one is more clear. Just a totally random idea! I’m not sure 
>>> about the above symbols, but it would help in other places too from memory 
>>> to not have to write the same variable name twice.
>>> 
 On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
> > wrote:
> 
> While I've sometimes (early on) wished for a shorter-hand syntax for that 
> construct, I've never been able to think of something that I thought was 
> better. I've gotten to the point where I don't particularly mind it 
> anymore.
> 
> Regarding the exclamation point specifically, seeing one of those in an 
> expression context says to me "this thing will die horribly if it is 
> nil/throws an error". Using it in this context where that's not the case 
> would probably go against users' expectations.
 
 Agree.  If we are going have syntax similar to pattern matching it should 
 be the same as pattern matching.  This would mean using ‘?' rather than 
 ‘!’.  However, we already have generalized pattern matching with `if case` 
 for that.  This topic has been debated extensively.
 
> 
> 
> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
> > wrote:
> On 17.05.2016 16:51, Johan Jensen wrote:
>  > This was one of the first and most commonly suggested ideas, when the 
> Swift
>  > Evolution mailing list first started.
>  > Chris Lattner sums it up
>  >
>   
> >
>  > in one of those threads:
>  >
>  >> This is commonly requested - the problem is that while it does help
>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>  >
>  > — Johan
> 
> Oh, thank you for letting this know.
> 
> Well, I totally disagree with Chris. And as soon as there was no 
> 'official'
> proposal and 'official' decision, I'd like to discuss this more.
> 
> I saw a lot of code like
> if let mySomeValue = mySomeValue {} in sources and even in books.
> Plus, I really believe that
> if let mySomeValue! {..} is better in any way: readability, less space for
> errors(when you need to repeat the same name) etc
> 
> FWIW, I suggest more explicit variant:
> if let value! {...} // with exclamation mark
> In that "old" proposal there was `if let value {...}`, was not so clear.
> 
> I can't accept an argument that you can use another name - as usually
> 'good' name is already 

Re: [swift-evolution] [Idea] if let value!

[Vladimir.S via swift-evolution]

Could you clarify how to use `if case` to achieve the same target as 
proposed `if let value!` ?

(btw, probably `if let value? {..}` will be better)

On 17.05.2016 18:18, Matthew Johnson wrote:



On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution
> wrote:

While I've sometimes (early on) wished for a shorter-hand syntax for that
construct, I've never been able to think of something that I thought was
better. I've gotten to the point where I don't particularly mind it anymore.

Regarding the exclamation point specifically, seeing one of those in an
expression context says to me "this thing will die horribly if it is
nil/throws an error". Using it in this context where that's not the case
would probably go against users' expectations.


Agree.  If we are going have syntax similar to pattern matching it should
be the same as pattern matching.  This would mean using ‘?' rather than
‘!’.  However, we already have generalized pattern matching with `if case`
for that.  This topic has been debated extensively.




On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution
> wrote:

On 17.05.2016 16:51, Johan Jensen wrote:
 > This was one of the first and most commonly suggested ideas, when
the Swift
 > Evolution mailing list first started.
 > Chris Lattner sums it up
 >


 > in one of those threads:
 >
 >> This is commonly requested - the problem is that while it does help
 > reduce boilerplate, it runs counter to the goal of improving clarity.
 >
 > — Johan

Oh, thank you for letting this know.

Well, I totally disagree with Chris. And as soon as there was no
'official'
proposal and 'official' decision, I'd like to discuss this more.

I saw a lot of code like
if let mySomeValue = mySomeValue {} in sources and even in books.
Plus, I really believe that
if let mySomeValue! {..} is better in any way: readability, less
space for
errors(when you need to repeat the same name) etc

FWIW, I suggest more explicit variant:
if let value! {...} // with exclamation mark
In that "old" proposal there was `if let value {...}`, was not so clear.

I can't accept an argument that you can use another name - as usually
'good' name is already 'crafted' for the instance and you want to use
it in
next code.
Otherwise, we need a 'best practice' to name optional variables with some
prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
mySomeValueOpt` will have a sense. But as I understand, we don't want to
use such approach.
Additionally, when you shadow optional value with same name - you are
*protecting* yourself from using optional value inside block of unwrapped
code. IMO it is a good idea.
And want we or don't want, we already have this practice widely. So I
believe this(my) proposal will improve the code.

I'd like to get opinion of the community regarding this feature.

On 17.05.2016 16:51, Johan Jensen wrote:
> This was one of the first and most commonly suggested ideas, when
the Swift
> Evolution mailing list first started.
> Chris Lattner sums it up
>


> in one of those threads:
>
>> This is commonly requested - the problem is that while it does help
> reduce boilerplate, it runs counter to the goal of improving clarity.
>
> — Johan
>
> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
> 
>> wrote:
>
> It is common to shadow optional value name with unwrapped value
with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to
achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org 
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org 

Re: [swift-evolution] `once` keyword for use with loops

[Haravikk via swift-evolution]

This only works with the example exactly as-is, I think a fairer re-write would 
be something like the following:

func toCSV(values:[CustomStringConvertible]) -> String {
var gen = values.generate()

var result = gen.next()?.description ?? ""
while let value = gen.next() { result += ", \(value)" }
return result
}

toCSV([1, 2, 3, 4, 5])

For brevity I opted to use nil-coalescing and a default value to handle the 
first (potentially nil) element cleanly.

I’m undecided about whether I want the feature or not; as shown the example can 
actually be handled very neatly already, so it doesn’t really highlight a need 
for the feature. One thing I like about it though is the ability to possibly 
eliminate the need for a generator and use a for in loop instead, like so:

func toCSV(values:[CustomStringConvertible]) -> String {
var result = ""
for value in values {
once { result += "\(value)"; continue }
result += ", \(value)"
}
return result
}

But this isn’t really much of a saving. I can’t think of a real-world example 
offhand that can better demonstrate a use for this; ideally you’d want to use 
several once {} blocks, or do something in the loop that requires other 
statements in the loop, i.e- you use the once to avoid duplicating statements 
in the loop while processing the first element.

> On 17 May 2016, at 07:13, Robert Widmann via swift-evolution 
>  wrote:
> 
> Not to doubt the usefulness of this proposal in general, but your example is 
> subsumed by simply declaring 
> 
> var result = "\(gen.next()!)"
> 
> and proceeding with the rest of the example sans `once`.  I think you'll also 
> have to address how this is any different from dispatch_once or a DSL over 
> the same.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> 2016/05/17 0:03、Nicholas Maccharoli via swift-evolution 
> > のメッセージ:
> 
>> ​Hello Swift Evolution,
>> 
>> Its not uncommon to have to do a piece of work only once or on the first 
>> iteration of 
>> a loop.
>> Take for example producing a comma separated string from an Array:
>> 
>> var result = ""
>> 
>> let values = [1, 2, 3, 4, 5]
>> 
>> var gen = values.generate()
>> 
>> 
>> 
>> if let first = gen.next() {
>> 
>> result += "\(first)"
>> 
>> while let value = gen.next() {
>> 
>> 
>> result += ", "
>> 
>> result += "\(value)"
>> 
>> }
>> 
>> }
>> 
>> 
>> 
>> Since on the first iteration we want to skip putting a comma in front we use 
>> an `if let` to grab the first element and then embed a `while let` inside 
>> the `if let` to handle the rest.
>> 
>> 
>> 
>> Another way to do this could be using a bool to keep track of the first 
>> iteration:
>> 
>> 
>> 
>> var first = true
>> 
>> while let value = gen.next() {
>> 
>> if first {
>> 
>> result += "\(value)"
>> 
>> first = false
>> 
>> continue
>> 
>> } else {
>> 
>> result += ", "
>> 
>> result += "\(value)"
>> 
>> }
>> 
>> 
>> }
>> 
>> 
>> 
>> These approaches work, but I think there may be a way to do this with less 
>> noise.
>> 
>> If there was a keyword to execute a block of code only on the first 
>> iteration of a loop I think that would make code like this more concise.
>> 
>> If there was a keyword like `once` then the same thing could be achieved 
>> with something like:
>> 
>> 
>> 
>> while let value = gen.next() {
>> 
>> once {
>> 
>> result += "\(value)"
>> 
>> continue
>> 
>> }
>> 
>> result += ", "
>> 
>> result += "\(value)"
>> 
>> 
>> }
>> 
>> 
>> 
>> How does it sound?
>> 
>> 
>> 
>> - Nick
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:41 AM, Brandon Knope  wrote:
> 
> I always thought a new keyword made more sense here:
> 
> if let rebind someValue { 
>   //use shadowed unwrapped value in here
> }
> 
> if let bind someValue {
>   //use shadowed unwrapped value in here
> }
> 
> 
> if let unwrapped someValue {
> 
> }
> 
> Something along those lines?

I wouldn’t want to see something like this replace the existing `if let` 
because it doesn’t handle cases where you bind a new name to the result of an 
expression that returns an optional.

If we did consider something like this it would be simple syntactic sugar for 
`if let x = x`.  Being syntactic sugar for something that is already not too 
bad means it would need to be as concise as possible.  If you want to advocate 
something like this, maybe consider just `if unwrap`:

if unwrap someValue {
}



> 
> Brandon
> 
> 
>> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>> > wrote:
>> 
>> Here’s a idea, what if you could use a symbol to denote that you want the 
>> same name used?
>> 
>> Here’s an interesting sign from music: 
>> https://en.wikipedia.org/wiki/Repeat_sign 
>> 
>> 
>> Then you can write (one) of these:
>> 
>> if let |: = mySomeValue {
>>   // Use unwrapped
>> }
>> 
>> if let mySomeValue = :| {
>>   // Use unwrapped
>> }
>> 
>> Not sure which one is more clear. Just a totally random idea! I’m not sure 
>> about the above symbols, but it would help in other places too from memory 
>> to not have to write the same variable name twice.
>> 
>>> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 
 On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
 > wrote:
 
 While I've sometimes (early on) wished for a shorter-hand syntax for that 
 construct, I've never been able to think of something that I thought was 
 better. I've gotten to the point where I don't particularly mind it 
 anymore.
 
 Regarding the exclamation point specifically, seeing one of those in an 
 expression context says to me "this thing will die horribly if it is 
 nil/throws an error". Using it in this context where that's not the case 
 would probably go against users' expectations.
>>> 
>>> Agree.  If we are going have syntax similar to pattern matching it should 
>>> be the same as pattern matching.  This would mean using ‘?' rather than 
>>> ‘!’.  However, we already have generalized pattern matching with `if case` 
>>> for that.  This topic has been debated extensively.
>>> 
 
 
 On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
 > wrote:
 On 17.05.2016 16:51, Johan Jensen wrote:
  > This was one of the first and most commonly suggested ideas, when the 
 Swift
  > Evolution mailing list first started.
  > Chris Lattner sums it up
  >
 >
  > in one of those threads:
  >
  >> This is commonly requested - the problem is that while it does help
  > reduce boilerplate, it runs counter to the goal of improving clarity.
  >
  > — Johan
 
 Oh, thank you for letting this know.
 
 Well, I totally disagree with Chris. And as soon as there was no 'official'
 proposal and 'official' decision, I'd like to discuss this more.
 
 I saw a lot of code like
 if let mySomeValue = mySomeValue {} in sources and even in books.
 Plus, I really believe that
 if let mySomeValue! {..} is better in any way: readability, less space for
 errors(when you need to repeat the same name) etc
 
 FWIW, I suggest more explicit variant:
 if let value! {...} // with exclamation mark
 In that "old" proposal there was `if let value {...}`, was not so clear.
 
 I can't accept an argument that you can use another name - as usually
 'good' name is already 'crafted' for the instance and you want to use it in
 next code.
 Otherwise, we need a 'best practice' to name optional variables with some
 prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
 mySomeValueOpt` will have a sense. But as I understand, we don't want to
 use such approach.
 Additionally, when you shadow optional value with same name - you are
 *protecting* yourself from using optional value inside block of unwrapped
 code. IMO it is a good idea.
 And want we or don't want, we already have this practice widely. So I
 believe this(my) proposal will improve the code.

Re: [swift-evolution] [Idea] if let value!

[Brandon Knope via swift-evolution]

I always thought a new keyword made more sense here:

if let rebind someValue { 
//use shadowed unwrapped value in here
}

if let bind someValue {
//use shadowed unwrapped value in here
}


if let unwrapped someValue {

}

Something along those lines?

Brandon


> On May 17, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> Here’s a idea, what if you could use a symbol to denote that you want the 
> same name used?
> 
> Here’s an interesting sign from music: 
> https://en.wikipedia.org/wiki/Repeat_sign 
> 
> 
> Then you can write (one) of these:
> 
> if let |: = mySomeValue {
>   // Use unwrapped
> }
> 
> if let mySomeValue = :| {
>   // Use unwrapped
> }
> 
> Not sure which one is more clear. Just a totally random idea! I’m not sure 
> about the above symbols, but it would help in other places too from memory to 
> not have to write the same variable name twice.
> 
>> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> 
>>> While I've sometimes (early on) wished for a shorter-hand syntax for that 
>>> construct, I've never been able to think of something that I thought was 
>>> better. I've gotten to the point where I don't particularly mind it anymore.
>>> 
>>> Regarding the exclamation point specifically, seeing one of those in an 
>>> expression context says to me "this thing will die horribly if it is 
>>> nil/throws an error". Using it in this context where that's not the case 
>>> would probably go against users' expectations.
>> 
>> Agree.  If we are going have syntax similar to pattern matching it should be 
>> the same as pattern matching.  This would mean using ‘?' rather than ‘!’.  
>> However, we already have generalized pattern matching with `if case` for 
>> that.  This topic has been debated extensively.
>> 
>>> 
>>> 
>>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
>>> > wrote:
>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>>  > This was one of the first and most commonly suggested ideas, when the 
>>> Swift
>>>  > Evolution mailing list first started.
>>>  > Chris Lattner sums it up
>>>  >
>>> >>  
>>> >
>>>  > in one of those threads:
>>>  >
>>>  >> This is commonly requested - the problem is that while it does help
>>>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>>>  >
>>>  > — Johan
>>> 
>>> Oh, thank you for letting this know.
>>> 
>>> Well, I totally disagree with Chris. And as soon as there was no 'official'
>>> proposal and 'official' decision, I'd like to discuss this more.
>>> 
>>> I saw a lot of code like
>>> if let mySomeValue = mySomeValue {} in sources and even in books.
>>> Plus, I really believe that
>>> if let mySomeValue! {..} is better in any way: readability, less space for
>>> errors(when you need to repeat the same name) etc
>>> 
>>> FWIW, I suggest more explicit variant:
>>> if let value! {...} // with exclamation mark
>>> In that "old" proposal there was `if let value {...}`, was not so clear.
>>> 
>>> I can't accept an argument that you can use another name - as usually
>>> 'good' name is already 'crafted' for the instance and you want to use it in
>>> next code.
>>> Otherwise, we need a 'best practice' to name optional variables with some
>>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>>> use such approach.
>>> Additionally, when you shadow optional value with same name - you are
>>> *protecting* yourself from using optional value inside block of unwrapped
>>> code. IMO it is a good idea.
>>> And want we or don't want, we already have this practice widely. So I
>>> believe this(my) proposal will improve the code.
>>> 
>>> I'd like to get opinion of the community regarding this feature.
>>> 
>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>> > This was one of the first and most commonly suggested ideas, when the 
>>> > Swift
>>> > Evolution mailing list first started.
>>> > Chris Lattner sums it up
>>> > >> >  
>>> > >
>>> > in one of those threads:
>>> >
>>> >> This is commonly requested - the problem is that while it does help
>>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>>> >
>>> > — Johan
>>> >
>>> > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via 

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

Now *that* reminds me of the _ voodoo in perl... and i was under the impression 
that magic symbols are not highly regarded in swift (which I really 
appreciate!!)

Regards
LM
(From mobile)

> On May 17, 2016, at 5:31 PM, Patrick Smith via swift-evolution 
>  wrote:
> 
> Here’s a idea, what if you could use a symbol to denote that you want the 
> same name used?
> 
> Here’s an interesting sign from music: 
> https://en.wikipedia.org/wiki/Repeat_sign
> 
> Then you can write (one) of these:
> 
> if let |: = mySomeValue {
>   // Use unwrapped
> }
> 
> if let mySomeValue = :| {
>   // Use unwrapped
> }
> 
> Not sure which one is more clear. Just a totally random idea! I’m not sure 
> about the above symbols, but it would help in other places too from memory to 
> not have to write the same variable name twice.
> 
>>> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>>>  wrote:
>>> 
>>> While I've sometimes (early on) wished for a shorter-hand syntax for that 
>>> construct, I've never been able to think of something that I thought was 
>>> better. I've gotten to the point where I don't particularly mind it anymore.
>>> 
>>> Regarding the exclamation point specifically, seeing one of those in an 
>>> expression context says to me "this thing will die horribly if it is 
>>> nil/throws an error". Using it in this context where that's not the case 
>>> would probably go against users' expectations.
>> 
>> Agree.  If we are going have syntax similar to pattern matching it should be 
>> the same as pattern matching.  This would mean using ‘?' rather than ‘!’.  
>> However, we already have generalized pattern matching with `if case` for 
>> that.  This topic has been debated extensively.
>> 
>>> 
>>> 
 On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
  wrote:
 On 17.05.2016 16:51, Johan Jensen wrote:
  > This was one of the first and most commonly suggested ideas, when the 
 Swift
  > Evolution mailing list first started.
  > Chris Lattner sums it up
  >
 
  > in one of those threads:
  >
  >> This is commonly requested - the problem is that while it does help
  > reduce boilerplate, it runs counter to the goal of improving clarity.
  >
  > — Johan
 
 Oh, thank you for letting this know.
 
 Well, I totally disagree with Chris. And as soon as there was no 'official'
 proposal and 'official' decision, I'd like to discuss this more.
 
 I saw a lot of code like
 if let mySomeValue = mySomeValue {} in sources and even in books.
 Plus, I really believe that
 if let mySomeValue! {..} is better in any way: readability, less space for
 errors(when you need to repeat the same name) etc
 
 FWIW, I suggest more explicit variant:
 if let value! {...} // with exclamation mark
 In that "old" proposal there was `if let value {...}`, was not so clear.
 
 I can't accept an argument that you can use another name - as usually
 'good' name is already 'crafted' for the instance and you want to use it in
 next code.
 Otherwise, we need a 'best practice' to name optional variables with some
 prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
 mySomeValueOpt` will have a sense. But as I understand, we don't want to
 use such approach.
 Additionally, when you shadow optional value with same name - you are
 *protecting* yourself from using optional value inside block of unwrapped
 code. IMO it is a good idea.
 And want we or don't want, we already have this practice widely. So I
 believe this(my) proposal will improve the code.
 
 I'd like to get opinion of the community regarding this feature.
 
 On 17.05.2016 16:51, Johan Jensen wrote:
 > This was one of the first and most commonly suggested ideas, when the 
 > Swift
 > Evolution mailing list first started.
 > Chris Lattner sums it up
 > 
 > in one of those threads:
 >
 >> This is commonly requested - the problem is that while it does help
 > reduce boilerplate, it runs counter to the goal of improving clarity.
 >
 > — Johan
 >
 > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
 > > wrote:
 >
 > It is common to shadow optional value name with unwrapped value with
 > same name:
 >
 > if let someGoodValue = someGoodValue {...}
 >
 > What if we'll have a syntax to not repeat the variable name to 
 > achieve
 > the 

Re: [swift-evolution] `once` keyword for use with loops

[Joe Groff via swift-evolution]

> On May 16, 2016, at 11:03 PM, Nicholas Maccharoli via swift-evolution 
>  wrote:
> 
> ​Hello Swift Evolution,
> 
> Its not uncommon to have to do a piece of work only once or on the first 
> iteration of 
> a loop.
> Take for example producing a comma separated string from an Array:
> 
> var result = ""
> 
> let values = [1, 2, 3, 4, 5]
> 
> var gen = values.generate()
> 
> 
> 
> if let first = gen.next() {
> 
> result += "\(first)"
> 
> while let value = gen.next() {
> 
> 
> result += ", "
> 
> result += "\(value)"
> 
> }
> 
> }
> 
> 
> 
> Since on the first iteration we want to skip putting a comma in front we use 
> an `if let` to grab the first element and then embed a `while let` inside the 
> `if let` to handle the rest.
> 
> 
> 
> Another way to do this could be using a bool to keep track of the first 
> iteration:
> 
> 
> 
> var first = true
> 
> while let value = gen.next() {
> 
> if first {
> 
> result += "\(value)"
> 
> first = false
> 
> continue
> 
> } else {
> 
> result += ", "
> 
> result += "\(value)"
> 
> }
> 
> 
> }
> 
> 
> 
> These approaches work, but I think there may be a way to do this with less 
> noise.
> 
> If there was a keyword to execute a block of code only on the first iteration 
> of a loop I think that would make code like this more concise.
> 
> If there was a keyword like `once` then the same thing could be achieved with 
> something like:
> 
> 
> 
> while let value = gen.next() {
> 
> once {
> 
> result += "\(value)"
> 
> continue
> 
> }
> 
> result += ", "
> 
> result += "\(value)"
> 
> 
> }
> 
> 
> 
> How does it sound?

IMO, a better approach would be to write an 'interleave' combinator, like this:

func interleave(_ x: S, between: () -> (), each: 
S.GeneratorType.Element -> ()) {
  var generator = x.generate()
  if let first = generator.next() {
each(first)
while let rest = generator.next() {
  between()
  each(rest)
}
  }
}

-Joe

> 
> 
> 
> - Nick
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

+1 Missed this one for a long time :) 

-- 
Adrian Zubarev 

Am 17. Mai 2016 um 16:25:10, David Hart via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

> 
> +1 Seems like it could enable very powerful behaviour going forward
> 
> > On 16 May 2016, at 23:06, Joe Groff via swift-evolution 
> >  wrote:
> > 
> > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what 
> > you'd expect, but does lead to problems when an 'as' expression appears as 
> > part of a comparison:
> > 
> > 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter 
> > list Int64
> > 
> > Looking to the future, many people have also expressed interest in the 
> > ability to do dynamic type checks against metatype values, not only static 
> > types, as in:
> > 
> > class Base {}
> > class DerivedA {}
> > class DerivedB {}
> > 
> > var x: Base.Type = DerivedA
> > 
> > DerivedA() as? x // succeeds
> > DerivedB() as? x // fails
> > 
> > If we accept 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md,
> >  dropping the '.self' requirement to refer to type objects, then I think we 
> > should also change 'is' and 'as' to parse the expression grammar on their 
> > right-hand side, leaving it up to the normal expression disambiguation rule 
> > to handle angle brackets. This solves the '20 as Int64 < x' problem, and 
> > prepares us to support dynamic is/as queries in the future. (To be clear, 
> > designing dynamic queries should be its own discussion.) What do you all 
> > think?
> > 
> > -Joe
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] if let value!

[LM via swift-evolution]

FWIW, agreed that more complex guard statements with shorter methods avoid the 
issue altogether (reminds me of using unless for similar purpose in perl).

Regards
LM
(From mobile)

> On May 17, 2016, at 5:15 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> Yep - same here. I think I was one of the first to propose we find some 
> solution to this on the list back when it first started, and oddly enough, 
> with more Swift experience comes less and less feeling of this even being a 
> problem. I think as you start thinking more “in Swift” you start structuring 
> your code differently, using guards, changing the nature of the flow, and 
> suddenly these situations come up less often.
> 
> l8r
> Sean
> 
> 
>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>>  wrote:
>> 
>> While I've sometimes (early on) wished for a shorter-hand syntax for that 
>> construct, I've never been able to think of something that I thought was 
>> better. I've gotten to the point where I don't particularly mind it anymore.
>> 
>> Regarding the exclamation point specifically, seeing one of those in an 
>> expression context says to me "this thing will die horribly if it is 
>> nil/throws an error". Using it in this context where that's not the case 
>> would probably go against users' expectations.
>> 
>> 
>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
>>  wrote:
>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>> This was one of the first and most commonly suggested ideas, when the Swift
>>> Evolution mailing list first started.
>>> Chris Lattner sums it up
>> 
>>> in one of those threads:
>>> 
 This is commonly requested - the problem is that while it does help
>>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>> 
>>> — Johan
>> 
>> Oh, thank you for letting this know.
>> 
>> Well, I totally disagree with Chris. And as soon as there was no 'official'
>> proposal and 'official' decision, I'd like to discuss this more.
>> 
>> I saw a lot of code like
>> if let mySomeValue = mySomeValue {} in sources and even in books.
>> Plus, I really believe that
>> if let mySomeValue! {..} is better in any way: readability, less space for
>> errors(when you need to repeat the same name) etc
>> 
>> FWIW, I suggest more explicit variant:
>> if let value! {...} // with exclamation mark
>> In that "old" proposal there was `if let value {...}`, was not so clear.
>> 
>> I can't accept an argument that you can use another name - as usually
>> 'good' name is already 'crafted' for the instance and you want to use it in
>> next code.
>> Otherwise, we need a 'best practice' to name optional variables with some
>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>> use such approach.
>> Additionally, when you shadow optional value with same name - you are
>> *protecting* yourself from using optional value inside block of unwrapped
>> code. IMO it is a good idea.
>> And want we or don't want, we already have this practice widely. So I
>> believe this(my) proposal will improve the code.
>> 
>> I'd like to get opinion of the community regarding this feature.
>> 
>>> On 17.05.2016 16:51, Johan Jensen wrote:
>>> This was one of the first and most commonly suggested ideas, when the Swift
>>> Evolution mailing list first started.
>>> Chris Lattner sums it up
>>> 
>>> in one of those threads:
>>> 
 This is commonly requested - the problem is that while it does help
>>> reduce boilerplate, it runs counter to the goal of improving clarity.
>>> 
>>> — Johan
>>> 
>>> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>>> > wrote:
>>> 
>>>It is common to shadow optional value name with unwrapped value with
>>>same name:
>>> 
>>>if let someGoodValue = someGoodValue {...}
>>> 
>>>What if we'll have a syntax to not repeat the variable name to achieve
>>>the same target:
>>> 
>>>if let someGoodValue! {...}
>>> 
>>>What do you think?
>>>___
>>>swift-evolution mailing list
>>>swift-evolution@swift.org 
>>>https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing 

Re: [swift-evolution] [Idea] if let value!

[Patrick Smith via swift-evolution]

Here’s a idea, what if you could use a symbol to denote that you want the same 
name used?

Here’s an interesting sign from music: https://en.wikipedia.org/wiki/Repeat_sign

Then you can write (one) of these:

if let |: = mySomeValue {
  // Use unwrapped
}

if let mySomeValue = :| {
  // Use unwrapped
}

Not sure which one is more clear. Just a totally random idea! I’m not sure 
about the above symbols, but it would help in other places too from memory to 
not have to write the same variable name twice.

> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> While I've sometimes (early on) wished for a shorter-hand syntax for that 
>> construct, I've never been able to think of something that I thought was 
>> better. I've gotten to the point where I don't particularly mind it anymore.
>> 
>> Regarding the exclamation point specifically, seeing one of those in an 
>> expression context says to me "this thing will die horribly if it is 
>> nil/throws an error". Using it in this context where that's not the case 
>> would probably go against users' expectations.
> 
> Agree.  If we are going have syntax similar to pattern matching it should be 
> the same as pattern matching.  This would mean using ‘?' rather than ‘!’.  
> However, we already have generalized pattern matching with `if case` for 
> that.  This topic has been debated extensively.
> 
>> 
>> 
>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
>> > wrote:
>> On 17.05.2016 16:51, Johan Jensen wrote:
>>  > This was one of the first and most commonly suggested ideas, when the 
>> Swift
>>  > Evolution mailing list first started.
>>  > Chris Lattner sums it up
>>  >
>> >  
>> >
>>  > in one of those threads:
>>  >
>>  >> This is commonly requested - the problem is that while it does help
>>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>>  >
>>  > — Johan
>> 
>> Oh, thank you for letting this know.
>> 
>> Well, I totally disagree with Chris. And as soon as there was no 'official'
>> proposal and 'official' decision, I'd like to discuss this more.
>> 
>> I saw a lot of code like
>> if let mySomeValue = mySomeValue {} in sources and even in books.
>> Plus, I really believe that
>> if let mySomeValue! {..} is better in any way: readability, less space for
>> errors(when you need to repeat the same name) etc
>> 
>> FWIW, I suggest more explicit variant:
>> if let value! {...} // with exclamation mark
>> In that "old" proposal there was `if let value {...}`, was not so clear.
>> 
>> I can't accept an argument that you can use another name - as usually
>> 'good' name is already 'crafted' for the instance and you want to use it in
>> next code.
>> Otherwise, we need a 'best practice' to name optional variables with some
>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>> use such approach.
>> Additionally, when you shadow optional value with same name - you are
>> *protecting* yourself from using optional value inside block of unwrapped
>> code. IMO it is a good idea.
>> And want we or don't want, we already have this practice widely. So I
>> believe this(my) proposal will improve the code.
>> 
>> I'd like to get opinion of the community regarding this feature.
>> 
>> On 17.05.2016 16:51, Johan Jensen wrote:
>> > This was one of the first and most commonly suggested ideas, when the Swift
>> > Evolution mailing list first started.
>> > Chris Lattner sums it up
>> > > >  
>> > >
>> > in one of those threads:
>> >
>> >> This is commonly requested - the problem is that while it does help
>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>> >
>> > — Johan
>> >
>> > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>> >  
>> > >> 
>> > wrote:
>> >
>> > It is common to shadow optional value name with unwrapped value with
>> > same name:
>> >
>> > if let someGoodValue = someGoodValue {...}
>> >
>> > What if we'll have a syntax to not repeat the variable name to achieve
>> > the same target:
>> >
>> > if let someGoodValue! {...}
>> >
>> > What do you think?
>> > ___
>> > swift-evolution mailing 

Re: [swift-evolution] [Idea] if let value!

[Matthew Johnson via swift-evolution]

> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> While I've sometimes (early on) wished for a shorter-hand syntax for that 
> construct, I've never been able to think of something that I thought was 
> better. I've gotten to the point where I don't particularly mind it anymore.
> 
> Regarding the exclamation point specifically, seeing one of those in an 
> expression context says to me "this thing will die horribly if it is 
> nil/throws an error". Using it in this context where that's not the case 
> would probably go against users' expectations.

Agree.  If we are going have syntax similar to pattern matching it should be 
the same as pattern matching.  This would mean using ‘?' rather than ‘!’.  
However, we already have generalized pattern matching with `if case` for that.  
This topic has been debated extensively.

> 
> 
> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
> > wrote:
> On 17.05.2016 16:51, Johan Jensen wrote:
>  > This was one of the first and most commonly suggested ideas, when the Swift
>  > Evolution mailing list first started.
>  > Chris Lattner sums it up
>  >
>   
> >
>  > in one of those threads:
>  >
>  >> This is commonly requested - the problem is that while it does help
>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>  >
>  > — Johan
> 
> Oh, thank you for letting this know.
> 
> Well, I totally disagree with Chris. And as soon as there was no 'official'
> proposal and 'official' decision, I'd like to discuss this more.
> 
> I saw a lot of code like
> if let mySomeValue = mySomeValue {} in sources and even in books.
> Plus, I really believe that
> if let mySomeValue! {..} is better in any way: readability, less space for
> errors(when you need to repeat the same name) etc
> 
> FWIW, I suggest more explicit variant:
> if let value! {...} // with exclamation mark
> In that "old" proposal there was `if let value {...}`, was not so clear.
> 
> I can't accept an argument that you can use another name - as usually
> 'good' name is already 'crafted' for the instance and you want to use it in
> next code.
> Otherwise, we need a 'best practice' to name optional variables with some
> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
> mySomeValueOpt` will have a sense. But as I understand, we don't want to
> use such approach.
> Additionally, when you shadow optional value with same name - you are
> *protecting* yourself from using optional value inside block of unwrapped
> code. IMO it is a good idea.
> And want we or don't want, we already have this practice widely. So I
> believe this(my) proposal will improve the code.
> 
> I'd like to get opinion of the community regarding this feature.
> 
> On 17.05.2016 16:51, Johan Jensen wrote:
> > This was one of the first and most commonly suggested ideas, when the Swift
> > Evolution mailing list first started.
> > Chris Lattner sums it up
> >  >  
> > >
> > in one of those threads:
> >
> >> This is commonly requested - the problem is that while it does help
> > reduce boilerplate, it runs counter to the goal of improving clarity.
> >
> > — Johan
> >
> > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
> >  
> > >> 
> > wrote:
> >
> > It is common to shadow optional value name with unwrapped value with
> > same name:
> >
> > if let someGoodValue = someGoodValue {...}
> >
> > What if we'll have a syntax to not repeat the variable name to achieve
> > the same target:
> >
> > if let someGoodValue! {...}
> >
> > What do you think?
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org  
> > >
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> >
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution