Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 16 Jun 2017, at 01:55, Xiaodi Wu  wrote:
> 
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
 On 16 Jun 2017, at 00:41, David Hart  wrote:
 
 
 On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
 
 
 On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever 
 you tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the 
>>> root of the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a 
>>> variable the same as a reserved keyword and require backticks. (A 
>>> previous suggestion to enforce capitalization falls down with full 
>>> Unicode support and complicates interop where imported C structures 
>>> might be lowercase and constants might be all caps.) No need to treat 
>>> built-in types specially; it’s equally a problem with types imported 
>>> from other libraries, which can be shadowed freely today. For full 
>>> source compatibility this can be a warning instead of an error–should 
>>> be sufficient as long as it’s brought to the user’s attention. In fact, 
>>> probably most appropriate as a warning, since the _compiler_ knows 
>>> exactly what’s going on, it’s the human that might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element 
>> names in patterns are very rarely used and not worth the added 
>> complexity and confusing. Going back to the old: “Would be add it to 
>> Swift if it did not exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with 
> source compatibility the bar is now much higher.
 
 Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
 system capability that no one uses.  I have no data to show that though.
 
> Is the feature harmful?
 
 Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
 that swift has a meaning for that very syntax in other contexts, and that 
 this is completely different meaning.  People absolutely would get 
 confused by this if they encountered it in real code that they themselves 
 didn't write, and I'm not aware of any good (non theoretical) use for it.
 
> My point is, not on its own it isn’t: warning on variables shadowing 
> types is sufficient to resolve the problems shown here.
 
 Again, my concern is that this is a confusing and misleading feature which 
 complicates and potentially prevents composing other features in the 
 future.
 
 
> 
> How strange that we’re talking about this issue in a thread about SE-0110.
 
 This came up in the discussion about 110 because we were exploring whether 
 it was plausible to expand the function parameter grammar to support 
 destructuring in the position where a name goes.  There are many concerns 
 about whether this is a good idea, but he existence of this in the tuple 
 destructuring pattern grammar is pretty much a showstopper.
 
> If anything, the response to that proposal should be a cautionary tale 
> that users can take poorly to removing features, sometimes in 
> unanticipated ways.
 
 Agreed, it may be too late to correct this (certainly we can't outright 
 remove it in Swift 4 if someone is using it for something important).  
 However if it turns out that it really isn't used, then warning about it 
 in 4 and removing it shortly after may be possible.
>>> 
>>> And I think its difficult to make the parallel between the two. SE-0110 
>>> basically impacted everybody calling higher-order functions on Dictionary 
>>> (+ more users from libraries like RxSwift), which makes an enormous 
>>> proportion of the Swift community. On the other hand, despite the enormous 
>>> amount of time I have sinked into learning, discussing and enjoying Swift, 
>>> I never come upon the tuple element name syntax in patterns until Robert 
>>> pointed to it out on twitter several weeks ago.
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>> when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; prospectively, 
> it was thought to be a minor change, even after review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel  wrote:

> On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
>
>> On 16 Jun 2017, at 00:41, David Hart  wrote:
>>
>>
>> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>>
>>
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> o
>>
>> >
 >   let (a : Int, b : Float) = foo()


 I think it would be better if the compiler raised a warning whenever
 you tried to redefine a builtin type.
>>>
>>>
>>> That’s essentially my preferred solution as well, as it gets to the root
>>> of the confusion.
>>>
>>> Naming a variable the same as a type should be similar to naming a
>>> variable the same as a reserved keyword and require backticks. (A previous
>>> suggestion to enforce capitalization falls down with full Unicode support
>>> and complicates interop where imported C structures might be lowercase and
>>> constants might be all caps.) No need to treat built-in types specially;
>>> it’s equally a problem with types imported from other libraries, which can
>>> be shadowed freely today. For full source compatibility this can be a
>>> warning instead of an error–should be sufficient as long as it’s brought to
>>> the user’s attention. In fact, probably most appropriate as a warning,
>>> since the _compiler_ knows exactly what’s going on, it’s the human that
>>> might be confused.
>>>
>>>
>>> I kind of agree with all you say. But I also feel that tuple element
>>> names in patterns are very rarely used and not worth the added complexity
>>> and confusing. Going back to the old: “Would be add it to Swift if it did
>>> not exist?”, I would say no.
>>>
>>
>> That was the standard for removing features before Swift 3, but with
>> source compatibility the bar is now much higher.
>>
>>
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
>> system capability that no one uses.  I have no data to show that though.
>>
>> Is the feature harmful?
>>
>>
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
>> that swift has a meaning for that very syntax in other contexts, and that
>> this is completely different meaning.  People absolutely would get confused
>> by this if they encountered it in real code that they themselves didn't
>> write, and I'm not aware of any good (non theoretical) use for it.
>>
>> My point is, not on its own it isn’t: warning on variables shadowing
>> types is sufficient to resolve the problems shown here.
>>
>>
>> Again, my concern is that this is a confusing and misleading feature
>> which complicates and potentially prevents composing other features in the
>> future.
>>
>>
>>
>> How strange that we’re talking about this issue in a thread about
>> SE-0110.
>>
>>
>> This came up in the discussion about 110 because we were exploring
>> whether it was plausible to expand the function parameter grammar to
>> support destructuring in the position where a name goes.  There are many
>> concerns about whether this is a good idea, but he existence of this in the
>> tuple destructuring pattern grammar is pretty much a showstopper.
>>
>> If anything, the response to that proposal should be a cautionary tale
>> that users can take poorly to removing features, sometimes in unanticipated
>> ways.
>>
>>
>> Agreed, it may be too late to correct this (certainly we can't outright
>> remove it in Swift 4 if someone is using it for something important).
>> However if it turns out that it really isn't used, then warning about it in
>> 4 and removing it shortly after may be possible.
>>
>>
>> And I think its difficult to make the parallel between the two. SE-0110
>> basically impacted everybody calling higher-order functions on Dictionary
>> (+ more users from libraries like RxSwift), which makes an enormous
>> proportion of the Swift community. On the other hand, despite the enormous
>> amount of time I have sinked into learning, discussing and enjoying Swift,
>> I never come upon the tuple element name syntax in patterns until Robert
>> pointed to it out on twitter several weeks ago.
>>
>>
>> By the way, I’m not attempting to deduce that nobody uses this feature by
>> the fact I didn’t know about it. But I think it’s one interesting datapoint
>> when comparing it to SE-0110.
>>
>
>
> SE-0110, **in retrospect**, has had impacts on a lot of users;
> prospectively, it was thought to be a minor change, even after review and
> acceptance.
>
> Keep in mind that this proposed change would also eliminate inline tuple
> shuffle. For instance, the following code will cease to compile:
>
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: Double, g: Double, b: Double, a: Double)) {
>   print(color)
> }
> f(color: x)
>
> It is an open question how frequently this is used. But like implicit
> tuple 

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel via swift-evolution]

> On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>let (a : Int, b : Float) = foo()
> 
> ?

Sorry, but I'm utterly confused: the output from the Core Team meeting about 
regressions caused by restrictions imposed in SE-0110 is that... the compiler 
should add more restrictions??

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Revisiting SE-0110

[Víctor Pimentel via swift-evolution]

On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution 
 wrote:
> 
> On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:
 On 16 Jun 2017, at 00:41, David Hart  wrote:
 
 
 On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
 
 
 On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever 
 you tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the 
>>> root of the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a 
>>> variable the same as a reserved keyword and require backticks. (A 
>>> previous suggestion to enforce capitalization falls down with full 
>>> Unicode support and complicates interop where imported C structures 
>>> might be lowercase and constants might be all caps.) No need to treat 
>>> built-in types specially; it’s equally a problem with types imported 
>>> from other libraries, which can be shadowed freely today. For full 
>>> source compatibility this can be a warning instead of an error–should 
>>> be sufficient as long as it’s brought to the user’s attention. In fact, 
>>> probably most appropriate as a warning, since the _compiler_ knows 
>>> exactly what’s going on, it’s the human that might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element 
>> names in patterns are very rarely used and not worth the added 
>> complexity and confusing. Going back to the old: “Would be add it to 
>> Swift if it did not exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with 
> source compatibility the bar is now much higher.
 
 Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
 system capability that no one uses.  I have no data to show that though.
 
> Is the feature harmful?
 
 Yes, absolutely.  The shadowing isn't the thing that bothers me, it is 
 that swift has a meaning for that very syntax in other contexts, and that 
 this is completely different meaning.  People absolutely would get 
 confused by this if they encountered it in real code that they themselves 
 didn't write, and I'm not aware of any good (non theoretical) use for it.
 
> My point is, not on its own it isn’t: warning on variables shadowing 
> types is sufficient to resolve the problems shown here.
 
 Again, my concern is that this is a confusing and misleading feature which 
 complicates and potentially prevents composing other features in the 
 future.
 
 
> 
> How strange that we’re talking about this issue in a thread about SE-0110.
 
 This came up in the discussion about 110 because we were exploring whether 
 it was plausible to expand the function parameter grammar to support 
 destructuring in the position where a name goes.  There are many concerns 
 about whether this is a good idea, but he existence of this in the tuple 
 destructuring pattern grammar is pretty much a showstopper.
 
> If anything, the response to that proposal should be a cautionary tale 
> that users can take poorly to removing features, sometimes in 
> unanticipated ways.
 
 Agreed, it may be too late to correct this (certainly we can't outright 
 remove it in Swift 4 if someone is using it for something important).  
 However if it turns out that it really isn't used, then warning about it 
 in 4 and removing it shortly after may be possible.
>>> 
>>> And I think its difficult to make the parallel between the two. SE-0110 
>>> basically impacted everybody calling higher-order functions on Dictionary 
>>> (+ more users from libraries like RxSwift), which makes an enormous 
>>> proportion of the Swift community. On the other hand, despite the enormous 
>>> amount of time I have sinked into learning, discussing and enjoying Swift, 
>>> I never come upon the tuple element name syntax in patterns until Robert 
>>> pointed to it out on twitter several weeks ago.
>> 
>> By the way, I’m not attempting to deduce that nobody uses this feature by 
>> the fact I didn’t know about it. But I think it’s one interesting datapoint 
>> when comparing it to SE-0110.
> 
> 
> SE-0110, **in retrospect**, has had impacts on a lot of users; prospectively, 
> it was thought to be a minor change, even after review and acceptance.
> 
> Keep in mind that this proposed change would also eliminate inline tuple 
> shuffle. For instance, the following code will cease to compile:
> 
> let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
> func f(color: (r: 

Re: [swift-evolution] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 17:43 David Hart  wrote:

> On 16 Jun 2017, at 00:41, David Hart  wrote:
>
>
> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
>
>
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> o
>
> >
>>> >   let (a : Int, b : Float) = foo()
>>>
>>>
>>> I think it would be better if the compiler raised a warning whenever you
>>> tried to redefine a builtin type.
>>
>>
>> That’s essentially my preferred solution as well, as it gets to the root
>> of the confusion.
>>
>> Naming a variable the same as a type should be similar to naming a
>> variable the same as a reserved keyword and require backticks. (A previous
>> suggestion to enforce capitalization falls down with full Unicode support
>> and complicates interop where imported C structures might be lowercase and
>> constants might be all caps.) No need to treat built-in types specially;
>> it’s equally a problem with types imported from other libraries, which can
>> be shadowed freely today. For full source compatibility this can be a
>> warning instead of an error–should be sufficient as long as it’s brought to
>> the user’s attention. In fact, probably most appropriate as a warning,
>> since the _compiler_ knows exactly what’s going on, it’s the human that
>> might be confused.
>>
>>
>> I kind of agree with all you say. But I also feel that tuple element
>> names in patterns are very rarely used and not worth the added complexity
>> and confusing. Going back to the old: “Would be add it to Swift if it did
>> not exist?”, I would say no.
>>
>
> That was the standard for removing features before Swift 3, but with
> source compatibility the bar is now much higher.
>
>
> Completely agreed.  My belief on this is that it is a legacy Swift 1 type
> system capability that no one uses.  I have no data to show that though.
>
> Is the feature harmful?
>
>
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is
> that swift has a meaning for that very syntax in other contexts, and that
> this is completely different meaning.  People absolutely would get confused
> by this if they encountered it in real code that they themselves didn't
> write, and I'm not aware of any good (non theoretical) use for it.
>
> My point is, not on its own it isn’t: warning on variables shadowing types
> is sufficient to resolve the problems shown here.
>
>
> Again, my concern is that this is a confusing and misleading feature which
> complicates and potentially prevents composing other features in the future.
>
>
>
> How strange that we’re talking about this issue in a thread about SE-0110.
>
>
> This came up in the discussion about 110 because we were exploring whether
> it was plausible to expand the function parameter grammar to support
> destructuring in the position where a name goes.  There are many concerns
> about whether this is a good idea, but he existence of this in the tuple
> destructuring pattern grammar is pretty much a showstopper.
>
> If anything, the response to that proposal should be a cautionary tale
> that users can take poorly to removing features, sometimes in unanticipated
> ways.
>
>
> Agreed, it may be too late to correct this (certainly we can't outright
> remove it in Swift 4 if someone is using it for something important).
> However if it turns out that it really isn't used, then warning about it in
> 4 and removing it shortly after may be possible.
>
>
> And I think its difficult to make the parallel between the two. SE-0110
> basically impacted everybody calling higher-order functions on Dictionary
> (+ more users from libraries like RxSwift), which makes an enormous
> proportion of the Swift community. On the other hand, despite the enormous
> amount of time I have sinked into learning, discussing and enjoying Swift,
> I never come upon the tuple element name syntax in patterns until Robert
> pointed to it out on twitter several weeks ago.
>
>
> By the way, I’m not attempting to deduce that nobody uses this feature by
> the fact I didn’t know about it. But I think it’s one interesting datapoint
> when comparing it to SE-0110.
>


SE-0110, **in retrospect**, has had impacts on a lot of users;
prospectively, it was thought to be a minor change, even after review and
acceptance.

Keep in mind that this proposed change would also eliminate inline tuple
shuffle. For instance, the following code will cease to compile:

let x = (a: 1.0, r: 0.5, g: 0.5, b: 0.5)
func f(color: (r: Double, g: Double, b: Double, a: Double)) {
  print(color)
}
f(color: x)

It is an open question how frequently this is used. But like implicit tuple
destructuring, it currently Just Works(TM) and users may not realize
they’re making use of the feature until it’s gone.



> -Chris
>
>
> `let (a : Int, b : Float) = foo()` is confusing but if you were to use
>>> your own type (e.g., `struct S {}` and replace Int and Float with S) you
>>> would get a compiler 

Re: [swift-evolution] Revisiting SE-0110

[Brent Royal-Gordon via swift-evolution]

> On Jun 15, 2017, at 10:28 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> My belief on this is that it is a legacy Swift 1 type system capability that 
> no one uses.  I have no data to show that though.


Tangential and perhaps a terrible idea, but: It's 2017. Can we instrument the 
compiler to tell us which weird, rare features people actually use?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 16 Jun 2017, at 00:41, David Hart  wrote:
> 
> 
>> On 15 Jun 2017, at 19:28, Chris Lattner > > wrote:
>> 
>> 
>> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>> > o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever you 
 tried to redefine a builtin type.
 
 That’s essentially my preferred solution as well, as it gets to the root 
 of the confusion.
 
 Naming a variable the same as a type should be similar to naming a 
 variable the same as a reserved keyword and require backticks. (A previous 
 suggestion to enforce capitalization falls down with full Unicode support 
 and complicates interop where imported C structures might be lowercase and 
 constants might be all caps.) No need to treat built-in types specially; 
 it’s equally a problem with types imported from other libraries, which can 
 be shadowed freely today. For full source compatibility this can be a 
 warning instead of an error–should be sufficient as long as it’s brought 
 to the user’s attention. In fact, probably most appropriate as a warning, 
 since the _compiler_ knows exactly what’s going on, it’s the human that 
 might be confused.
>>> 
>>> I kind of agree with all you say. But I also feel that tuple element names 
>>> in patterns are very rarely used and not worth the added complexity and 
>>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>>> exist?”, I would say no.
>>> 
>>> That was the standard for removing features before Swift 3, but with source 
>>> compatibility the bar is now much higher.
>> 
>> Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
>> system capability that no one uses.  I have no data to show that though.
>> 
>>> Is the feature harmful?
>> 
>> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
>> swift has a meaning for that very syntax in other contexts, and that this is 
>> completely different meaning.  People absolutely would get confused by this 
>> if they encountered it in real code that they themselves didn't write, and 
>> I'm not aware of any good (non theoretical) use for it.
>> 
>>> My point is, not on its own it isn’t: warning on variables shadowing types 
>>> is sufficient to resolve the problems shown here.
>> 
>> Again, my concern is that this is a confusing and misleading feature which 
>> complicates and potentially prevents composing other features in the future.
>> 
>> 
>>> 
>>> How strange that we’re talking about this issue in a thread about SE-0110.
>> 
>> This came up in the discussion about 110 because we were exploring whether 
>> it was plausible to expand the function parameter grammar to support 
>> destructuring in the position where a name goes.  There are many concerns 
>> about whether this is a good idea, but he existence of this in the tuple 
>> destructuring pattern grammar is pretty much a showstopper.
>> 
>>> If anything, the response to that proposal should be a cautionary tale that 
>>> users can take poorly to removing features, sometimes in unanticipated ways.
>> 
>> Agreed, it may be too late to correct this (certainly we can't outright 
>> remove it in Swift 4 if someone is using it for something important).  
>> However if it turns out that it really isn't used, then warning about it in 
>> 4 and removing it shortly after may be possible.
> 
> And I think its difficult to make the parallel between the two. SE-0110 
> basically impacted everybody calling higher-order functions on Dictionary (+ 
> more users from libraries like RxSwift), which makes an enormous proportion 
> of the Swift community. On the other hand, despite the enormous amount of 
> time I have sinked into learning, discussing and enjoying Swift, I never come 
> upon the tuple element name syntax in patterns until Robert pointed to it out 
> on twitter several weeks ago.

By the way, I’m not attempting to deduce that nobody uses this feature by the 
fact I didn’t know about it. But I think it’s one interesting datapoint when 
comparing it to SE-0110.

>> -Chris
>> 
>>> 
 `let (a : Int, b : Float) = foo()` is confusing but if you were to use 
 your own type (e.g., `struct S {}` and replace Int and Float with S) you 
 would get a compiler error. If the compiler warned you that you were 
 reassigning Int and Float, you’d probably avoid that problem. Or, for a 
 more extreme fix, we could make reassigning builtin types illegal since 
 there is pretty much no valid reason to do that.
 
 
 > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
 > > wrote:
 >
 >
 >
 > Sent from my iPad
 >
 >> On Jun 14, 

Re: [swift-evolution] Revisiting SE-0110

[David Hart via swift-evolution]

> On 15 Jun 2017, at 19:28, Chris Lattner  wrote:
> 
> 
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
> > o
>>> >
>>> >   let (a : Int, b : Float) = foo()
>>> 
>>> 
>>> I think it would be better if the compiler raised a warning whenever you 
>>> tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the root of 
>>> the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a variable 
>>> the same as a reserved keyword and require backticks. (A previous 
>>> suggestion to enforce capitalization falls down with full Unicode support 
>>> and complicates interop where imported C structures might be lowercase and 
>>> constants might be all caps.) No need to treat built-in types specially; 
>>> it’s equally a problem with types imported from other libraries, which can 
>>> be shadowed freely today. For full source compatibility this can be a 
>>> warning instead of an error–should be sufficient as long as it’s brought to 
>>> the user’s attention. In fact, probably most appropriate as a warning, 
>>> since the _compiler_ knows exactly what’s going on, it’s the human that 
>>> might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element names 
>> in patterns are very rarely used and not worth the added complexity and 
>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>> exist?”, I would say no.
>> 
>> That was the standard for removing features before Swift 3, but with source 
>> compatibility the bar is now much higher.
> 
> Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
> system capability that no one uses.  I have no data to show that though.
> 
>> Is the feature harmful?
> 
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
> swift has a meaning for that very syntax in other contexts, and that this is 
> completely different meaning.  People absolutely would get confused by this 
> if they encountered it in real code that they themselves didn't write, and 
> I'm not aware of any good (non theoretical) use for it.
> 
>> My point is, not on its own it isn’t: warning on variables shadowing types 
>> is sufficient to resolve the problems shown here.
> 
> Again, my concern is that this is a confusing and misleading feature which 
> complicates and potentially prevents composing other features in the future.
> 
> 
>> 
>> How strange that we’re talking about this issue in a thread about SE-0110.
> 
> This came up in the discussion about 110 because we were exploring whether it 
> was plausible to expand the function parameter grammar to support 
> destructuring in the position where a name goes.  There are many concerns 
> about whether this is a good idea, but he existence of this in the tuple 
> destructuring pattern grammar is pretty much a showstopper.
> 
>> If anything, the response to that proposal should be a cautionary tale that 
>> users can take poorly to removing features, sometimes in unanticipated ways.
> 
> Agreed, it may be too late to correct this (certainly we can't outright 
> remove it in Swift 4 if someone is using it for something important).  
> However if it turns out that it really isn't used, then warning about it in 4 
> and removing it shortly after may be possible.

And I think its difficult to make the parallel between the two. SE-0110 
basically impacted everybody calling higher-order functions on Dictionary (+ 
more users from libraries like RxSwift), which makes an enormous proportion of 
the Swift community. On the other hand, despite the enormous amount of time I 
have sinked into learning, discussing and enjoying Swift, I never come upon the 
tuple element name syntax in patterns until Robert pointed to it out on twitter 
several weeks ago.

> -Chris
> 
>> 
>>> `let (a : Int, b : Float) = foo()` is confusing but if you were to use your 
>>> own type (e.g., `struct S {}` and replace Int and Float with S) you would 
>>> get a compiler error. If the compiler warned you that you were reassigning 
>>> Int and Float, you’d probably avoid that problem. Or, for a more extreme 
>>> fix, we could make reassigning builtin types illegal since there is pretty 
>>> much no valid reason to do that.
>>> 
>>> 
>>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>>> > > wrote:
>>> >
>>> >
>>> >
>>> > Sent from my iPad
>>> >
>>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>> >> > wrote:
>>> >>
>>> >>
>>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell >> >>> > wrote:
>>> >>>
>>> >>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> >>> some positive responses, but 

Re: [swift-evolution] Revisiting SE-0110

[Beta via swift-evolution]

It’s not just a syntactic thing we’re talking about here.  The grammar permits 
all kinds of wonky combinations of things that will parse as “TSPL Swift", but 
will fail in Sema.  In that sense, no, this feature is not documented there.

~Robert Widmann

> On Jun 15, 2017, at 12:08 PM, Kyle Murray via swift-evolution 
>  wrote:
> 
> Yes, in the sense that the grammar 
> 
>  has a production that permits the tuple element name. But there aren't any 
> examples that use labels within patterns.
> 
> 
> GRAMMAR OF A TUPLE PATTERN
> 
>  <>tuple-pattern → (­tuple-pattern-element-list 
> ­opt­)­
>  <>tuple-pattern-element-list → tuple-pattern-element 
> ­
>| tuple-pattern-element 
> ­,­tuple-pattern-element-list
>  
> ­
>  <>tuple-pattern-element → pattern 
> ­
>|  identifier 
> ­:­pattern
>  
> ­
>  <>
> 
> -Kyle
> 
>> On Jun 15, 2017, at 10:34 AM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Is this capability even documented in TSPL?
> 
> ___
> 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] Revisiting SE-0110

[Kyle Murray via swift-evolution]

Yes, in the sense that the grammar 

 has a production that permits the tuple element name. But there aren't any 
examples that use labels within patterns.


GRAMMAR OF A TUPLE PATTERN

 <>tuple-pattern → (­tuple-pattern-element-list 
­opt­)­
 <>tuple-pattern-element-list → tuple-pattern-element 
­
   | tuple-pattern-element 
­,­tuple-pattern-element-list
 
­
 <>tuple-pattern-element → pattern 
­
   |  identifier 
­:­pattern
 
­
 <>

-Kyle

> On Jun 15, 2017, at 10:34 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Is this capability even documented in TSPL?

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

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

[Gor Gyolchanyan via swift-evolution]

I agree that nested braces in parentheses are much more ugly then nested quotes 
in parentheses.
About ExressibleByStringLiteral: This is a completely orthogonal case. The 
issue is passing these string literals to functions.
The passed literal doesn't have to be string, it can be any other 
ExpressibleByStringLiteral.
This is not something that I'd like to actively push for because this really is 
not that big of a deal, but some case that happened to me a couple of times and 
given that the exact same behavior is already implemented with closures, I 
though extending it to encompass string literal would be a cheap way of making 
another popular use case easier on the eye.

> On Jun 15, 2017, at 7:49 PM, Xiaodi Wu  wrote:
> 
> Agree with David on all points. Neat idea, but not convinced it’s a win in 
> terms of tidying up code vs. increased burden of new grammar rule.
> 
> Agree also that it’s a subjective opinion. For me, ({[]}) nesting is clunky 
> both to read and write, but (“”) just doesn’t have the same issues even with 
> multiline syntax–the symbols are just so unlike each other.
> 
> Your DSL examples, if truly you’re using them often, suggest that these 
> particular types should be extended to conform to ExpressibleByStringLiteral.
> On Thu, Jun 15, 2017 at 11:16 David Hart via swift-evolution 
> > wrote:
> I totally see what you are driving at. But I just see less value in it that 
> with trailing closure. But it’s very personal.
> 
> > On 15 Jun 2017, at 13:18, Gor Gyolchanyan  > > wrote:
> >
> > Funny you should mention DSLs:
> >
> > let myQuery = sql """
> >   SELECT id, name, date
> >   FROM MyTable
> >   WHERE id > 100
> >   """
> >
> > let myLayout = NSLayoutConstraint """
> >   ...
> >   """
> >
> > let myPredicate = NSPredicate ""
> >   ...
> >   """
> >
> >> On Jun 15, 2017, at 2:05 PM, David Hart  >> > wrote:
> >>
> >> Personally, I have never felt that need.
> >>
> >> Trailing closures fill of need of making Swift a good candidate for 
> >> building DSLs, where they make the function calls look more like 
> >> first-class operations. But I don’t think that trailing strings would be 
> >> as useful.
> >>
> >> David.
> >>
> >>> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution 
> >>> > wrote:
> >>>
> >>> Good day, swift evolution community!
> >>>
> >>> I'll just get right to it...
> >>>
> >>> Did anyone else beside me wished this was a thing?
> >>>
> >>> func parse(allowSomeBehavior: Bool = true, source: String) {
> >>> // ...
> >>> }
> >>>
> >>> parse(allowSomeBehavior: false) """
> >>> This is a source string
> >>> that contains a number of lines of text
> >>> which is passed to the function `parse`
> >>> """
> >>>
> >>> parse """
> >>> The exact same thing as above
> >>> except no other parameters are specified
> >>> """
> >>>
> >>> ___
> >>> 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] Introducing role keywords to reduce hard-to-find bugs

[Philippe Hausler via swift-evolution]

I too really like this proposal; personally I can attest to how it probably 
would have saved some time and headache with the Foundation overlay as well as 
swift-corelibs-foundation (specifically when adopting Collection and friends 
for types)

Would it be reasonable to have this apply to typealiases as well? Or does not 
only make sense for functions/properties etc?

I presume this would also be something exposed in the interfaces when viewing 
APIs?

Does this perhaps have any objc protocol interaction? (e.g. do we need an 
attribute to adopt things? Or perhaps can we leverage this to address the 
disparity 'tween objc protocols and swift protocols for optional methods via 
this same mechanism?)

> On Jun 14, 2017, at 10:46 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 14 2017, Chris Lattner  > wrote:
> 
>>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution
>>>  wrote:
>>> 
>>> Some pals and I have been kicking an idea around about introducing
>>> better ways to support the compiler in protocol extensions. We want
>> 
>>> to eliminate some hard-to-detect bugs. We've been brainstorming on
>>> how to do this without affecting backward compatibility and
>>> introducing a minimal impact on keywords.
>>> 
>>> We'd love to know what you think of our idea, which is to introduce
>>> "role" keywords. Roles allow the compiler to automatically check the
>>> intended use of a extension member definition against its protocol
>>> declarations, and emit errors, warnings, and fixits as needed.  We
>>> think it's a pretty straightforward approach that, if adopted,
>>> eliminates an entire category of bugs.
>>> 
>>> The draft proposal is here:
>>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4
>>> >> >
>>> 
>>> Thanks in advance for your thoughtful feedback,
>> 
>> +1 on the idea of this.  
> 
> ditto.  IMO it also makes the protocol extension much more expressive
> and easy to read.
> 
> -- 
> -Dave
> 
> ___
> 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] Change Void meaning

[John McCall via swift-evolution]

> On Jun 14, 2017, at 4:45 AM, Jérémie Girault  
> wrote:
> @john, the proposal is the fruit of my imagination and the goal was to 
> discuss about it.
> I’m vastly open to change it with the help of anyone if it can be implemented 
> in a simple way and leads to better compatibility or syntactical improvements.
> 
> xiaodi told me that he wouldn’t be available to help me but I’m open to any 
> help and change that would represent an improvement (from the developer or 
> compiler point of view)

I'm just providing feedback.

John.

> 
> —
> very short reply expected - vsre.info 
> Jérémie Girault
> 
> On 13 juin 2017 at 19:15:18, John McCall (rjmcc...@apple.com 
> ) wrote:
> 
>> 
>>> On Jun 13, 2017, at 4:41 AM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Jun 13, 2017 at 3:06 AM, John McCall >> > wrote:
 On Jun 13, 2017, at 3:30 AM, Jérémie Girault > wrote:
 
 Exactly, 
 The reflexion behind it is: 
 
 - Let's understand that 0110 and other tuple SE are important for the 
 compiler, we do not want them to rollback
 - However we have number of regressions for generics / functional 
 programmers
 - Let’s solve this step by step like a typical problem
 
 - Step 0 is adressing this Void tuple of size zero :
 - Zero is in many problems of CS an edge case, so let’s handle this case 
 first
 - The compiler knows what Void is, and its only value (or non-value)
 - It was handled historically by the compiler because of implicit side 
 effects
 - Let’s handle it explicitely with rules in current context
 - one effect of the proposal is source compatibility
 - but the goal is to build atop and strengthen 0110, 0066 and other 
 tuple-related SE
 
>>> 
>>> There are four difficulties I see with this proposal.
>>> 
>>> The first is that it is a first step that quite clearly does not lead to 
>>> anything.  It resolves a difficulty with exactly one case of function 
>>> composition, but we would need completely different solutions to handle any 
>>> of the other compositional regressions of SE-0110.
>>> 
>>> The second is that it's a huge source of complexity for the type system.  
>>> The type checker would not be able to do even rudimentary type matching, 
>>> e.g. when checking a call, without having first resolved all of the 
>>> argument and parameter types to prove that they are not Void.  This would 
>>> probably render it impossible to type-check many programs without some 
>>> ad-hoc rule of inferring that certain types are not Void.  It would 
>>> certainly make type-checking vastly more expensive.
>>> 
>>> The third is that it is not possible to prevent values of Void from 
>>> existing, because (unlike Never, which cannot be constructed) they are 
>>> always created by returning from a Void-returning function, and a generic 
>>> function can do anything it likes with that value — turn it into an Any, 
>>> store it in an Array, whatever.  The proposal seems to only consider using 
>>> the value as a parameter.
>>> 
>>> Hang on, though. If Jérémie is interested only in addressing the issue of 
>>> Void as a parameter and his idea can be adequately carried out by inferring 
>>> a default value of Void for every parameter of type Void, this should be a 
>>> fairly self-contained change, should it not? And would the impact on the 
>>> cost of type checking really be vastly greater in that case?
>> 
>> If the proposal was phrased in terms of defaults, e.g. "trailing parameters 
>> do not require a matching argument if they have Void type", then yes, that 
>> would be implementable because it still admits a "local" reduction on call 
>> constraints, one which does not need to immediately reason about the actual 
>> types of arguments.  It is not clear that this rule allows function 
>> compositions of the sort that Jérémie is looking for, though.
>> 
>> Anyway, that is not the proposal; the proposal is that parameters — in any 
>> position — are simply removed from the parameter sequence if they have Void 
>> type.  In order to allow composition (i.e. f(g(x)), where g: X -> Void), you 
>> then need a matching rule that arguments are dropped from the argument 
>> sequence (for purposes of type-checking) if they have Void type.  Either of 
>> these rules is sufficient to turn the reduction of function-type matches 
>> into an extremely messy combinatoric matching problem where e.g. (τ0, Int) 
>> can be passed to a function taking (Int, τ1) if we can decide that τ0 == τ1 
>> == Void.
>> 
>>> This idea is now rather intriguing to me because it extends beyond just 
>>> addressing one symptom of SE-0110. Swift allows us to omit the spelling out 
>>> of return types that are Void, it allows warning-free 

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> 
> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution 
>  o
 >
 >   let (a : Int, b : Float) = foo()
 
 
 I think it would be better if the compiler raised a warning whenever you 
 tried to redefine a builtin type.
>>> 
>>> That’s essentially my preferred solution as well, as it gets to the root of 
>>> the confusion.
>>> 
>>> Naming a variable the same as a type should be similar to naming a variable 
>>> the same as a reserved keyword and require backticks. (A previous 
>>> suggestion to enforce capitalization falls down with full Unicode support 
>>> and complicates interop where imported C structures might be lowercase and 
>>> constants might be all caps.) No need to treat built-in types specially; 
>>> it’s equally a problem with types imported from other libraries, which can 
>>> be shadowed freely today. For full source compatibility this can be a 
>>> warning instead of an error–should be sufficient as long as it’s brought to 
>>> the user’s attention. In fact, probably most appropriate as a warning, 
>>> since the _compiler_ knows exactly what’s going on, it’s the human that 
>>> might be confused.
>> 
>> I kind of agree with all you say. But I also feel that tuple element names 
>> in patterns are very rarely used and not worth the added complexity and 
>> confusing. Going back to the old: “Would be add it to Swift if it did not 
>> exist?”, I would say no.
> 
> That was the standard for removing features before Swift 3, but with source 
> compatibility the bar is now much higher.

Completely agreed.  My belief on this is that it is a legacy Swift 1 type 
system capability that no one uses.  I have no data to show that though.

> Is the feature harmful?

Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
swift has a meaning for that very syntax in other contexts, and that this is 
completely different meaning.  People absolutely would get confused by this if 
they encountered it in real code that they themselves didn't write, and I'm not 
aware of any good (non theoretical) use for it.

> My point is, not on its own it isn’t: warning on variables shadowing types is 
> sufficient to resolve the problems shown here.

Again, my concern is that this is a confusing and misleading feature which 
complicates and potentially prevents composing other features in the future.


> 
> How strange that we’re talking about this issue in a thread about SE-0110.

This came up in the discussion about 110 because we were exploring whether it 
was plausible to expand the function parameter grammar to support destructuring 
in the position where a name goes.  There are many concerns about whether this 
is a good idea, but he existence of this in the tuple destructuring pattern 
grammar is pretty much a showstopper.

> If anything, the response to that proposal should be a cautionary tale that 
> users can take poorly to removing features, sometimes in unanticipated ways.

Agreed, it may be too late to correct this (certainly we can't outright remove 
it in Swift 4 if someone is using it for something important).  However if it 
turns out that it really isn't used, then warning about it in 4 and removing it 
shortly after may be possible.

-Chris

> 
 `let (a : Int, b : Float) = foo()` is confusing but if you were to use 
 your own type (e.g., `struct S {}` and replace Int and Float with S) you 
 would get a compiler error. If the compiler warned you that you were 
 reassigning Int and Float, you’d probably avoid that problem. Or, for a 
 more extreme fix, we could make reassigning builtin types illegal since 
 there is pretty much no valid reason to do that.
 
 
 > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
 >  wrote:
 >
 >
 >
 > Sent from my iPad
 >
 >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
 >>  wrote:
 >>
 >>
 >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
 >>>
 >>> What’s the status of this Chris’s double parens idea below? It 
 >>> garnered some positive responses, but the discussion seems to have 
 >>> fizzled out. Is there something needed to help nudge this along?
 >>>
 >>> What’s the likelihood of getting this fixed before Swift 4 goes live, 
 >>> and the great wave of readability regressions hits?
 >>
 >> We discussed this in the core team meeting today.  Consensus seems to 
 >> be that a change needs to be made to regain syntactic convenience here. 
 >>  Discussion was leaning towards allowing (at least) the parenthesized 
 >> form, but more discussion is needed.
 >>
 >>
 >> One (tangential) thing that came up is that tuple element names in 
 >> tuple *patterns* should probably be deprecated and removed at some 
 >> point.  Without looking, 

Re: [swift-evolution] Revisiting SE-0110

[Chris Lattner via swift-evolution]

> On Jun 15, 2017, at 10:28 AM, Chris Lattner  wrote:
> 
> 
>> Is the feature harmful?
> 
> Yes, absolutely.  The shadowing isn't the thing that bothers me, it is that 
> swift has a meaning for that very syntax in other contexts, and that this is 
> completely different meaning.  People absolutely would get confused by this 
> if they encountered it in real code that they themselves didn't write, and 
> I'm not aware of any good (non theoretical) use for it.

A different way to look at it: beyond enabling a dubious capability (inline 
tuple shuffle) the pattern matching syntax is arguably just backwards.  Thus it 
is inconsistent with the rest of Swift (e.g. tuple type syntax).  This makes it 
super confusing.

I recognize that by itself this isn't enough of a reason to make a change.  Is 
this capability even documented in TSPL?

-Chris

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

Re: [swift-evolution] Revisiting SE-0110

[Mark Lacey via swift-evolution]

> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution 
>  wrote:
> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>  let (a : Int, b : Float) = foo()
> 
> 
> I think it would be better if the compiler raised a warning whenever you 
> tried to redefine a builtin type. `let (a : Int, b : Float) = foo()` is 
> confusing but if you were to use your own type (e.g., `struct S {}` and 
> replace Int and Float with S) you would get a compiler error.

If you replace *both* Int and Float with S you would get an error, but if you 
replace one you’ll only get an error if you do this within the same scope that 
your type is defined.

There’s nothing special happening here for the stdlib types vs. your own types. 
What you’re witnessing is shadowing. You can shadow names within deeper scopes, 
e.g. this is perfectly legal:

func MyOwnInt() {
  struct Int : ExpressibleByFloatLiteral {
typealias FloatLiteralType = Double

public init(floatLiteral value: FloatLiteralType) {
  self.value = value
}

var value: FloatLiteralType
  }
  let _: Int = 7.0
}


Mark

> If the compiler warned you that you were reassigning Int and Float, you’d 
> probably avoid that problem. Or, for a more extreme fix, we could make 
> reassigning builtin types illegal since there is pretty much no valid reason 
> to do that.
> 
> 
>> On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
 
 What’s the status of this Chris’s double parens idea below? It garnered 
 some positive responses, but the discussion seems to have fizzled out. Is 
 there something needed to help nudge this along?
 
 What’s the likelihood of getting this fixed before Swift 4 goes live, and 
 the great wave of readability regressions hits?
>>> 
>>> We discussed this in the core team meeting today.  Consensus seems to be 
>>> that a change needs to be made to regain syntactic convenience here.  
>>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>>> but more discussion is needed.
>>> 
>>> 
>>> One (tangential) thing that came up is that tuple element names in tuple 
>>> *patterns* should probably be deprecated and removed at some point.  
>>> Without looking, what variables does this declare?:
>>> 
>>>  let (a : Int, b : Float) = foo()
>> 
>> Another option would be to require let to appear next to each name binding 
>> instead of allowing a single let for the whole pattern.  I personally find 
>> that much more clear despite it being a little bit more verbose.
>> 
>>> 
>>> ?
>>> 
>>> -Chris
>>> 
>>> ___
>>> 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] [Idea] Trailing Multi-Line String Literal

[Xiaodi Wu via swift-evolution]

Agree with David on all points. Neat idea, but not convinced it’s a win in
terms of tidying up code vs. increased burden of new grammar rule.

Agree also that it’s a subjective opinion. For me, ({[]}) nesting is clunky
both to read and write, but (“”) just doesn’t have the same issues even
with multiline syntax–the symbols are just so unlike each other.

Your DSL examples, if truly you’re using them often, suggest that these
particular types should be extended to conform to
ExpressibleByStringLiteral.
On Thu, Jun 15, 2017 at 11:16 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> I totally see what you are driving at. But I just see less value in it
> that with trailing closure. But it’s very personal.
>
> > On 15 Jun 2017, at 13:18, Gor Gyolchanyan  wrote:
> >
> > Funny you should mention DSLs:
> >
> > let myQuery = sql """
> >   SELECT id, name, date
> >   FROM MyTable
> >   WHERE id > 100
> >   """
> >
> > let myLayout = NSLayoutConstraint """
> >   ...
> >   """
> >
> > let myPredicate = NSPredicate ""
> >   ...
> >   """
> >
> >> On Jun 15, 2017, at 2:05 PM, David Hart  wrote:
> >>
> >> Personally, I have never felt that need.
> >>
> >> Trailing closures fill of need of making Swift a good candidate for
> building DSLs, where they make the function calls look more like
> first-class operations. But I don’t think that trailing strings would be as
> useful.
> >>
> >> David.
> >>
> >>> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> Good day, swift evolution community!
> >>>
> >>> I'll just get right to it...
> >>>
> >>> Did anyone else beside me wished this was a thing?
> >>>
> >>> func parse(allowSomeBehavior: Bool = true, source: String) {
> >>> // ...
> >>> }
> >>>
> >>> parse(allowSomeBehavior: false) """
> >>> This is a source string
> >>> that contains a number of lines of text
> >>> which is passed to the function `parse`
> >>> """
> >>>
> >>> parse """
> >>> The exact same thing as above
> >>> except no other parameters are specified
> >>> """
> >>>
> >>> ___
> >>> 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] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 11:19 David Hart  wrote:

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > One (tangential) thing that came up is that tuple element names in
>> tuple *patterns* should probably be deprecated and removed at some point.
>> Without looking, what variables does this declare?:
>> >
>> >   let (a : Int, b : Float) = foo()
>>
>>
>> I think it would be better if the compiler raised a warning whenever you
>> tried to redefine a builtin type.
>
>
> That’s essentially my preferred solution as well, as it gets to the root
> of the confusion.
>
> Naming a variable the same as a type should be similar to naming a
> variable the same as a reserved keyword and require backticks. (A previous
> suggestion to enforce capitalization falls down with full Unicode support
> and complicates interop where imported C structures might be lowercase and
> constants might be all caps.) No need to treat built-in types specially;
> it’s equally a problem with types imported from other libraries, which can
> be shadowed freely today. For full source compatibility this can be a
> warning instead of an error–should be sufficient as long as it’s brought to
> the user’s attention. In fact, probably most appropriate as a warning,
> since the _compiler_ knows exactly what’s going on, it’s the human that
> might be confused.
>
>
> I kind of agree with all you say. But I also feel that tuple element names
> in patterns are very rarely used and not worth the added complexity and
> confusing. Going back to the old: “Would be add it to Swift if it did not
> exist?”, I would say no.
>

That was the standard for removing features before Swift 3, but with source
compatibility the bar is now much higher. Is the feature harmful? My point
is, not on its own it isn’t: warning on variables shadowing types is
sufficient to resolve the problems shown here.

How strange that we’re talking about this issue in a thread about SE-0110.
If anything, the response to that proposal should be a cautionary tale that
users can take poorly to removing features, sometimes in unanticipated ways.

`let (a : Int, b : Float) = foo()` is confusing but if you were to use your
>> own type (e.g., `struct S {}` and replace Int and Float with S) you would
>> get a compiler error. If the compiler warned you that you were reassigning
>> Int and Float, you’d probably avoid that problem. Or, for a more extreme
>> fix, we could make reassigning builtin types illegal since there is pretty
>> much no valid reason to do that.
>>
>>
>> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>
>> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell 
>> wrote:
>> >>>
>> >>> What’s the status of this Chris’s double parens idea below? It
>> garnered some positive responses, but the discussion seems to have fizzled
>> out. Is there something needed to help nudge this along?
>> >>>
>> >>> What’s the likelihood of getting this fixed before Swift 4 goes live,
>> and the great wave of readability regressions hits?
>> >>
>> >> We discussed this in the core team meeting today.  Consensus seems to
>> be that a change needs to be made to regain syntactic convenience here.
>> Discussion was leaning towards allowing (at least) the parenthesized form,
>> but more discussion is needed.
>> >>
>> >>
>> >> One (tangential) thing that came up is that tuple element names in
>> tuple *patterns* should probably be deprecated and removed at some point.
>> Without looking, what variables does this declare?:
>> >>
>> >>   let (a : Int, b : Float) = foo()
>> >
>> > Another option would be to require let to appear next to each name
>> binding instead of allowing a single let for the whole pattern.  I
>> personally find that much more clear despite it being a little bit more
>> verbose.
>> >
>> >>
>> >> ?
>> >>
>> >> -Chris
>> >>
>> >> ___
>> >> 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] Revisiting SE-0110

[David Hart via swift-evolution]

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution 
> > wrote:
> > One (tangential) thing that came up is that tuple element names in tuple 
> > *patterns* should probably be deprecated and removed at some point.  
> > Without looking, what variables does this declare?:
> >
> >   let (a : Int, b : Float) = foo()
> 
> 
> I think it would be better if the compiler raised a warning whenever you 
> tried to redefine a builtin type.
> 
> That’s essentially my preferred solution as well, as it gets to the root of 
> the confusion.
> 
> Naming a variable the same as a type should be similar to naming a variable 
> the same as a reserved keyword and require backticks. (A previous suggestion 
> to enforce capitalization falls down with full Unicode support and 
> complicates interop where imported C structures might be lowercase and 
> constants might be all caps.) No need to treat built-in types specially; it’s 
> equally a problem with types imported from other libraries, which can be 
> shadowed freely today. For full source compatibility this can be a warning 
> instead of an error–should be sufficient as long as it’s brought to the 
> user’s attention. In fact, probably most appropriate as a warning, since the 
> _compiler_ knows exactly what’s going on, it’s the human that might be 
> confused.

I kind of agree with all you say. But I also feel that tuple element names in 
patterns are very rarely used and not worth the added complexity and confusing. 
Going back to the old: “Would be add it to Swift if it did not exist?”, I would 
say no.

> `let (a : Int, b : Float) = foo()` is confusing but if you were to use your 
> own type (e.g., `struct S {}` and replace Int and Float with S) you would get 
> a compiler error. If the compiler warned you that you were reassigning Int 
> and Float, you’d probably avoid that problem. Or, for a more extreme fix, we 
> could make reassigning builtin types illegal since there is pretty much no 
> valid reason to do that.
> 
> 
> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
> > > wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
> >> > wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  >>> > wrote:
> >>>
> >>> What’s the status of this Chris’s double parens idea below? It garnered 
> >>> some positive responses, but the discussion seems to have fizzled out. Is 
> >>> there something needed to help nudge this along?
> >>>
> >>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
> >>> the great wave of readability regressions hits?
> >>
> >> We discussed this in the core team meeting today.  Consensus seems to be 
> >> that a change needs to be made to regain syntactic convenience here.  
> >> Discussion was leaning towards allowing (at least) the parenthesized form, 
> >> but more discussion is needed.
> >>
> >>
> >> One (tangential) thing that came up is that tuple element names in tuple 
> >> *patterns* should probably be deprecated and removed at some point.  
> >> Without looking, what variables does this declare?:
> >>
> >>   let (a : Int, b : Float) = foo()
> >
> > Another option would be to require let to appear next to each name binding 
> > instead of allowing a single let for the whole pattern.  I personally find 
> > that much more clear despite it being a little bit more verbose.
> >
> >>
> >> ?
> >>
> >> -Chris
> >>
> >> ___
> >> 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

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

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

[David Hart via swift-evolution]

I totally see what you are driving at. But I just see less value in it that 
with trailing closure. But it’s very personal.

> On 15 Jun 2017, at 13:18, Gor Gyolchanyan  wrote:
> 
> Funny you should mention DSLs:
> 
> let myQuery = sql """
>   SELECT id, name, date
>   FROM MyTable
>   WHERE id > 100
>   """
> 
> let myLayout = NSLayoutConstraint """
>   ...
>   """
> 
> let myPredicate = NSPredicate ""
>   ...
>   """
> 
>> On Jun 15, 2017, at 2:05 PM, David Hart  wrote:
>> 
>> Personally, I have never felt that need.
>> 
>> Trailing closures fill of need of making Swift a good candidate for building 
>> DSLs, where they make the function calls look more like first-class 
>> operations. But I don’t think that trailing strings would be as useful.
>> 
>> David.
>> 
>>> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution 
>>>  wrote:
>>> 
>>> Good day, swift evolution community!
>>> 
>>> I'll just get right to it...
>>> 
>>> Did anyone else beside me wished this was a thing?
>>> 
>>> func parse(allowSomeBehavior: Bool = true, source: String) {
>>> // ...
>>> }
>>> 
>>> parse(allowSomeBehavior: false) """
>>> This is a source string
>>> that contains a number of lines of text
>>> which is passed to the function `parse`
>>> """
>>> 
>>> parse """
>>> The exact same thing as above
>>> except no other parameters are specified
>>> """
>>> 
>>> ___
>>> 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] Revisiting SE-0110

[Chris Lattner via swift-evolution]

Let me clarify: I'm only talking about removing tuple element names from the 
*pattern* grammar.  They would still be allowed on tuple types, which is what 
you are using.

-Chris

> On Jun 14, 2017, at 9:45 PM, Charlie Monroe  wrote:
> 
> 
>> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>>> 
>>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> some positive responses, but the discussion seems to have fizzled out. Is 
>>> there something needed to help nudge this along?
>>> 
>>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>>> the great wave of readability regressions hits?
>> 
>> We discussed this in the core team meeting today.  Consensus seems to be 
>> that a change needs to be made to regain syntactic convenience here.  
>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>> but more discussion is needed.
>> 
>> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>let (a : Int, b : Float) = foo()
> 
> Personally, I use this often as "anonymous structs" (which tuples IMHO are). 
> Often, there is a return type used in 1-2 methods and in such case, I feel 
> that declaring a struct MyMethorReturnStruct is unnecessary and I use tuples 
> with named elements, so that the call site can easily access the information 
> it needs, which is particularly convenient if both tuple member are of the 
> same type:
> 
> func parseName() -> (firstName: String, lastName: String)
> 
> Instead of deprecating this, would it be possible to make this a syntax for 
> generating a truly anonymous structure? It can internally have a name that 
> mangles together the element *names and types*, so:
> 
> let name = (firstName: "John", lastName: "Doe")
> 
> type(of: name) == _firstName_String_lastName_String_
> 
> Hence you would be able to pass this structure wherever it's declared exactly 
> the same, but:
> 
> func passName() -> (name1: String, name2: String) {
>return parseName() // see above for declaration
> }
> 
> will result in error as (firstName: String, lastName: String) cannot be 
> converted to (name1: String, name2: String).
> 
> 
>> 
>> ?
>> 
>> -Chris
>> 
>> ___
>> 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] Revisiting SE-0110

[Xiaodi Wu via swift-evolution]

On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> > One (tangential) thing that came up is that tuple element names in tuple
> *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >
> >   let (a : Int, b : Float) = foo()
>
>
> I think it would be better if the compiler raised a warning whenever you
> tried to redefine a builtin type.


That’s essentially my preferred solution as well, as it gets to the root of
the confusion.

Naming a variable the same as a type should be similar to naming a variable
the same as a reserved keyword and require backticks. (A previous
suggestion to enforce capitalization falls down with full Unicode support
and complicates interop where imported C structures might be lowercase and
constants might be all caps.) No need to treat built-in types specially;
it’s equally a problem with types imported from other libraries, which can
be shadowed freely today. For full source compatibility this can be a
warning instead of an error–should be sufficient as long as it’s brought to
the user’s attention. In fact, probably most appropriate as a warning,
since the _compiler_ knows exactly what’s going on, it’s the human that
might be confused.

`let (a : Int, b : Float) = foo()` is confusing but if you were to use your
> own type (e.g., `struct S {}` and replace Int and Float with S) you would
> get a compiler error. If the compiler warned you that you were reassigning
> Int and Float, you’d probably avoid that problem. Or, for a more extreme
> fix, we could make reassigning builtin types illegal since there is pretty
> much no valid reason to do that.
>
>
> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell 
> wrote:
> >>>
> >>> What’s the status of this Chris’s double parens idea below? It
> garnered some positive responses, but the discussion seems to have fizzled
> out. Is there something needed to help nudge this along?
> >>>
> >>> What’s the likelihood of getting this fixed before Swift 4 goes live,
> and the great wave of readability regressions hits?
> >>
> >> We discussed this in the core team meeting today.  Consensus seems to
> be that a change needs to be made to regain syntactic convenience here.
> Discussion was leaning towards allowing (at least) the parenthesized form,
> but more discussion is needed.
> >>
> >>
> >> One (tangential) thing that came up is that tuple element names in
> tuple *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >>
> >>   let (a : Int, b : Float) = foo()
> >
> > Another option would be to require let to appear next to each name
> binding instead of allowing a single let for the whole pattern.  I
> personally find that much more clear despite it being a little bit more
> verbose.
> >
> >>
> >> ?
> >>
> >> -Chris
> >>
> >> ___
> >> 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] Revisiting SE-0110

[Robert Bennett via swift-evolution]

> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>   let (a : Int, b : Float) = foo()


I think it would be better if the compiler raised a warning whenever you tried 
to redefine a builtin type. `let (a : Int, b : Float) = foo()` is confusing but 
if you were to use your own type (e.g., `struct S {}` and replace Int and Float 
with S) you would get a compiler error. If the compiler warned you that you 
were reassigning Int and Float, you’d probably avoid that problem. Or, for a 
more extreme fix, we could make reassigning builtin types illegal since there 
is pretty much no valid reason to do that.


> On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>>> 
>>> What’s the status of this Chris’s double parens idea below? It garnered 
>>> some positive responses, but the discussion seems to have fizzled out. Is 
>>> there something needed to help nudge this along?
>>> 
>>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>>> the great wave of readability regressions hits?
>> 
>> We discussed this in the core team meeting today.  Consensus seems to be 
>> that a change needs to be made to regain syntactic convenience here.  
>> Discussion was leaning towards allowing (at least) the parenthesized form, 
>> but more discussion is needed.
>> 
>> 
>> One (tangential) thing that came up is that tuple element names in tuple 
>> *patterns* should probably be deprecated and removed at some point.  Without 
>> looking, what variables does this declare?:
>> 
>>   let (a : Int, b : Float) = foo()
> 
> Another option would be to require let to appear next to each name binding 
> instead of allowing a single let for the whole pattern.  I personally find 
> that much more clear despite it being a little bit more verbose.
> 
>> 
>> ?
>> 
>> -Chris
>> 
>> ___
>> 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] Revisiting SE-0110

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell  wrote:
>> 
>> What’s the status of this Chris’s double parens idea below? It garnered some 
>> positive responses, but the discussion seems to have fizzled out. Is there 
>> something needed to help nudge this along?
>> 
>> What’s the likelihood of getting this fixed before Swift 4 goes live, and 
>> the great wave of readability regressions hits?
> 
> We discussed this in the core team meeting today.  Consensus seems to be that 
> a change needs to be made to regain syntactic convenience here.  Discussion 
> was leaning towards allowing (at least) the parenthesized form, but more 
> discussion is needed.
> 
> 
> One (tangential) thing that came up is that tuple element names in tuple 
> *patterns* should probably be deprecated and removed at some point.  Without 
> looking, what variables does this declare?:
> 
>let (a : Int, b : Float) = foo()

Another option would be to require let to appear next to each name binding 
instead of allowing a single let for the whole pattern.  I personally find that 
much more clear despite it being a little bit more verbose.

> 
> ?
> 
> -Chris
> 
> ___
> 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] Trailing Multi-Line String Literal

[Gor Gyolchanyan via swift-evolution]

Funny you should mention DSLs:

let myQuery = sql """
SELECT id, name, date
FROM MyTable
WHERE id > 100
"""

let myLayout = NSLayoutConstraint """
...
"""

let myPredicate = NSPredicate ""
...
"""

> On Jun 15, 2017, at 2:05 PM, David Hart  wrote:
> 
> Personally, I have never felt that need.
> 
> Trailing closures fill of need of making Swift a good candidate for building 
> DSLs, where they make the function calls look more like first-class 
> operations. But I don’t think that trailing strings would be as useful.
> 
> David.
> 
>> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution 
>>  wrote:
>> 
>> Good day, swift evolution community!
>> 
>> I'll just get right to it...
>> 
>> Did anyone else beside me wished this was a thing?
>> 
>> func parse(allowSomeBehavior: Bool = true, source: String) {
>>  // ...
>> }
>> 
>> parse(allowSomeBehavior: false) """
>>  This is a source string
>>  that contains a number of lines of text
>>  which is passed to the function `parse`
>>  """
>> 
>> parse """
>>  The exact same thing as above
>>  except no other parameters are specified
>>  """
>> 
>> ___
>> 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] Trailing Multi-Line String Literal

[David Hart via swift-evolution]

Personally, I have never felt that need.

Trailing closures fill of need of making Swift a good candidate for building 
DSLs, where they make the function calls look more like first-class operations. 
But I don’t think that trailing strings would be as useful.

David.

> On 15 Jun 2017, at 11:54, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> Good day, swift evolution community!
> 
> I'll just get right to it...
> 
> Did anyone else beside me wished this was a thing?
> 
> func parse(allowSomeBehavior: Bool = true, source: String) {
>   // ...
> }
> 
> parse(allowSomeBehavior: false) """
>   This is a source string
>   that contains a number of lines of text
>   which is passed to the function `parse`
>   """
> 
> parse """
>   The exact same thing as above
>   except no other parameters are specified
>   """
> 
> ___
> 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] [Idea] Trailing Multi-Line String Literal

[Gor Gyolchanyan via swift-evolution]

Good day, swift evolution community!

I'll just get right to it...

Did anyone else beside me wished this was a thing?

func parse(allowSomeBehavior: Bool = true, source: String) {
// ...
}

parse(allowSomeBehavior: false) """
This is a source string
that contains a number of lines of text
which is passed to the function `parse`
"""

parse """
The exact same thing as above
except no other parameters are specified
"""

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