Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Goffredo Marocchi via swift-evolution]

In his message Chris stated that protocols are obviously dynamic while in the 
case of protocol extensions we have default implementations (IMHO out of place 
in protocols if we see protocols are pure abstract contracts designed to 
decouple from the actual implementation) and the compiler will use a static 
implementation just because of the dressing/the type our object is casted as. 
It just feels wrong and an indication that we are now leaking implementation 
details we were trying to hide.

I think this is a compiler optimisation which should not be implicitly applied 
unless it has side effects and this example shows one of those side effects. In 
such cases, I think we should have a keyword to override the compiler with and 
strongly hint we want to enforce the compiler to use the static implementation.

Sent from my iPhone

> On 4 Jan 2016, at 02:52, Drew Crawford via swift-evolution 
>  wrote:
> 
> I offer a +1, but I have two criticisms of the proposal.
> 
> The first is that the example given in the proposal is stated a lot more 
> strongly than is true:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
>> The code above yields an error, and rightfully so, because if the real types 
>> of first and second are not equal, they cannot actually be compared.
>> 
> It is true for Swift 2 code.  However, whether this is true forever is less 
> clear.  There is a thread here discussing "existential protocols", which 
> AFAIK would make this code listing into a non-error, and in that thread 
> Douglas Gregor said:
> 
>> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
>> I think it’s very, very cool, but it’s complicated and we need a while to 
>> understand its overall effects.
> 
> As long as the door is open to allowing the syntax, I think saying something 
> strong and normative about it in an official proposal would be a mistake.  
> The example is fine, but the comment should be that this "currently errors" 
> or "surprises new programmers" or something weaker than "it's obvious to all 
> of us this shouldn't work" because it's obvious to some people that it should 
> work after all.
> 
> The second thing is that I think using the words "dynamically dispatched" or 
> "dynamically dispatched interfaces" in the body of the proposal is a mistake. 
>  It is not that interfaces "are" dynamically dispatched.  It is that they may 
> be, e.g. that the compiler may select a dynamic implementation (or it may be 
> able to find a static implementation), whereas for a protocol the compiler is 
> guaranteed to use a static implementation.  This is I think more consistent 
> with CL's position on static/dynamic in Swift generally.  So I think we 
> should find a turn of phrase like "behaves dynamically" or "has dynamic 
> dispatch semantics" rather than saying "it *is* dynamically dispatched" as if 
> we will force the optimizer to spit out a vtable when it can find a static 
> implementation.
> 
> With those two details resolved I think it is a strong proposal, and very 
> much in line with the proposal we're reviewing about separating typealias vs 
> associatedtype, which strikes at a similar confusion where we're separating 
> two different concepts into their own keywords.
> 
> 
>> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> +1 to "opening" values of existential type, I remember trying (and failing) 
>> to do this when Swift 1 came out. Being able to capture the dynamic type of 
>> an object at runtime and do stuff with it would be incredible.
>> 
>> Austin
>> 
>>> On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution 
>>>  wrote:
>>> This would be wonderful - is it something that could happen in the Swift 3 
>>> timeframe? Is it something that myself or someone else could work on a 
>>> formal proposal for?
>>> 
>>> -DW
>>> 
> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Introduction of interfaces will clean up the current blend of static and 
> dynamic protocols, and solve at least three popular issues.
> Please see:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
 
 I am *completely* against this proposal.
 
 Fundamentally, you're trying to address the limitation that protocols with 
 Self or associated type requirements can't be existential. But it's just a 
 limitation that isn't (conceptually) that hard to fix: the primary 
 operation you need to work with an existing of such a protocol is to 
 "open" a value of existential type, giving a name to the dynamic type it 
 stores. Let's invent one:
 
   func eq(x: Equatable, y: Equatable) -> Bool {
 // give the name T to the dynamic ty

Re: [swift-evolution] Customized Inline Init Closure

[Weston Catron via swift-evolution]

Thanks! Then looks very interesting and I’ll reach out to the lead there and 
see if they’re interested in working together. It definitely highlights similar 
readability issues I had outlined. I’m curious if there are compiler or other 
advantages to initializing more properties before continuing in the scope. For 
example race conditions, mulitthread support, concurrency... If you want to 
initialize more of an object than any single initializer allows being able to 
create it and set all desired properties before the system denotes it as 
officially initialized might be helpful. This would make a distinction between 
the init then { // do something} model verses init with { // do this to create 
it }.

-Weston

> On Jan 3, 2016, at 9:09 PM, Adriano Ferreira  wrote:
> 
> Hey there!
> 
> As a suggestion, check out this simple yet very interesting project called 
> Then  by @devxoul.
> 
> Best,
> 
> — A
> 
>> On Jan 3, 2016, at 1:37 AM, Weston Catron via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Ability to write an initializer while initializing an object.
>> 
>> Example
>> 
>> let name = “John Apple”;
>> let person = Person {
>> self.name = nameInput.first() + " " + nameInput.last()
>> self.dob = dateInput.datetime()
>> If (self.age() > 18) {
>> self.taxableStatus = INDEPENDANT
>> } else {
>> self.taxableStatus = DEPENDANT
>> }
>> };
>> 
>> Helpful examples: Objects with many required parameters that are defaulted 
>> in the initializers. 
>> 
>> SKLabelNode
>> 
>> let label = SKLabelNode(text: "Example") 
>> label.position = CGPoint(x: 0, y: 250); 
>> label.fontSize = 34; 
>> label.fontColor = UIColor.blackColor() 
>> self.addChild(label);
>> 
>> Can become:
>> 
>> let label = SKLabelNode(text: self.package!.title) {
>> self.position = CGPoint(x: 0, y: 250)
>> self.fontSize = 34
>> self.fontColor = UIColor.blackColor() 
>> }
>> self.addChild(label)
>> 
>> Readability Instead of a large amount of code setting up temporary variables 
>> to pass into an initializer, all initializing code could be wrapped in a 
>> closure.
>> 
>> Flexibility Instead of exhaustive initializers covering many use cases. 
>> Simpler initializers can be extended as needed. This can also encourage 
>> required properties over optional ones that are immediately defined. 
>> 
>> Compiler Warnings Closures react the same as initializers within classes, 
>> warning users of incomplete implementation of required properties.
>> 
>> Possible disadvantages:
>> 
>> Sloppy Coding Instead of writing complete initializers programmers can just 
>> rely on in-line initializers.  
>> 
>> Tried Before I found this feature is also available in C# 
>> (https://msdn.microsoft.com/en-us/library/bb397680.aspx 
>> ). Not sure if it 
>> was helpful then but many languages since don't appear to use it. 
>> 
>> -Weston
>> 
>> ___
>> 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]: Free the '$' Symbol!

[John Joyce via swift-evolution]

I have been thinking about this topic a lot, but not '$' symbol, rather the 
tools to create DSLs within Swift to enable productive & meaningful special 
casing. (Ruby's Rake vs Make/GNUMake come to mind a lot, or Ruby's Sinatra web 
framework come to mind, perhaps Python's Flask to  a lesser extent, and in 
general the way things can be constructed for tools like HTTP handling or 
similar.)

I think native Regular Expressions will enable a lot of things, but if it were 
possible to have more flexibility in the operator space, a lot could be 
possible.
My thinking is along the lines of class or struct internal operators or pseudo 
operators.
The infix operator pattern allows functions without parens. If these can be 
written to be human language characters, this enables many interesting DSL 
behaviors.

>From thinking about Regular Expression support and how many languages use / to 
>delimit Regular Expression literals, and provide special scoping rules that 
>make escaping \ unnecessary, perhaps there is something to the scoping rules 
>that might be more flexible, long-term?

Apologies if I have wandered off a bit on a tangent but the DSL space seems to 
tie these together potentially.

I would posit that making human language characters available rather than 
symbols will have a much greater productivity and creativity impact. (and also 
likely more accessible by virtue of being potentially readable, literally) 

The alternatives at the moment all seem to come back to either stringly-typed 
dictionaries or to enums + boilerplate.


> On Jan 4, 2016, at 12:17 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> 
> -Chris
> 
> On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch  > wrote:
> 
>> Is it considered infeasible for any characters to be allowed in both 
>> identifiers and operators?
>> 
>> On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
>> > mailto:swift-evolution@swift.org>> wrote:
>> >
>> >> Swift currently does not allow operators to use $ - I assume because the 
>> >> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
>> >> why an entire class of identifiers has been eliminated, so I propose $ 
>> >> instead be reclassified as an `operator-character` so it can be used 
>> >> mixed in with other such characters, but prevents the introduction of 
>> >> `$Identifier`-style declarations that might conflict with implicit 
>> >> parameters.
>> >
>> > I believe the reason you don't see any other $ variables is that they're 
>> > reserved for the debugger and REPL.
>> >
>> >   brent@Brents-MacBook-Pro ~/D/Code> swift
>> >   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
>> > clang-700.1.81). Type :help for assistance.
>> > 1> "foo"
>> >   $R0: String = "foo"
>> > 2> print($R0)
>> >   foo
>> 
>> Right.  That said, our current operator space (particularly the unicode 
>> segments covered) is not super well considered.  It would be great for 
>> someone to take a more systematic pass over them to rationalize things.
>> 
>> -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] Customized Inline Init Closure

[Weston Catron via swift-evolution]

I believe you’re referring to this 
https://gist.github.com/erica/eb32feb22ba99629285a 
 currently being developed. 
I was initially limiting this proposal to initializers, specifically overriding 
them verses immediately following them. This is an important distinction 
because it would require required properties, verses the initializers still 
taking care of this. This doesn’t make it in opposition to method cascading, it 
might possibly be a nice addition. It also appears like self is not maintained 
(in that method cascading proposal anyhow), self is just not required unless 
variables names overlap. Below is my exercise in keeping self.

Perhaps this alternative would work: 

class Foo {
var name:String

init (name:String) {
self.name = name
}
}

class Fee {
var name:String = "Fee-fi"
static func createFoo (name:String) -> Foo {
let foo = Foo {
foo.name = self.name + "-" + name
}
return foo;
}
}

let name = "fo-fum"

let other = Fee.createFoo(name);
print(other.name) // "Fee-fi-fo-fum"

let another = Foo {
// name = self.name // Ambiguous, self isn't defined.
// self.name = name // Simplist, but isn't clear within scopes that contain 
self (like class functions) It would require a common javascript work around 
for this, saving a `that = this;` before the closure.
another.name = name // Clear, another is only required when names overlap 
in scope.
// print((self == nil)) // true
}

This has restrictions. An initializer can’t be used directly within a return 
for example:

class Fee {
var name:String = "Fee-fi"
static func createFoo (name:String) -> Foo {
return Foo {
return.name = self.name + "-" + name
}
}
}

That is admittedly awkward, bad form, but not technically wrong.

Unless there is a better alternative, keeping self the same inside the closure 
as outside seems difficult to do, but not impossible.

-Weston

> On Jan 3, 2016, at 7:39 AM, Tino Heth <2...@gmx.de> wrote:
> 
> Something similar has been discussed ("method cascading"), and I hope the 
> feature will be considered for Swift 4(?).
> It is a little bit different, though:
> "self" would not change its meaning (which imho is a plus), and the syntax is 
> different.
> 
> Tino

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

Re: [swift-evolution] Declaring a function that always returns nil

[Andrew Duncan via swift-evolution]

Yep, this has transformed from an evolution question to a how-to answer. 
exit(1).

Thanks Jack and Jaden for pointing out the retrospectively obvious. Just 
couldn’t see my own nose.

I liked Jeff’s Optional gambit though. Félix, je regrette that your name 
doesn’t start with ‘J’.

> On 3 Jan, 2016, at 20:36, Félix Cloutier 

> wrote:
> 
> IMO, this is the best way to approach it.
> 
> Félix
> 
>> Le 3 janv. 2016 à 22:54:17, Jack Lawrence via swift-evolution 
>>  a écrit :
>> 
>> You could also use type inference on the return type:
>> 
>>   1> func returnsNil(errCode: Int) -> T? { 
>>   2. print(errCode) 
>>   3. return nil 
>>   4. } 
>>   5> func returnsAnOptional() -> Int? { 
>>   6. return returnsNil(5) 
>>   7. }
>> 
>> 
>>> On Jan 3, 2016, at 7:51 PM, Jeff Kelley via swift-evolution 
>>>  wrote:
>>> 
>>> Just spit-balling here, but couldn’t you do this with a generic extension 
>>> on Optional?
>>> 
 extension Optional {
 func returnsNil(errorCode: Int) -> Wrapped? {
 logError(errorCode)
 return nil
 }
 }
>>> 
>>> 
>>> Jeff Kelley
>>> 
>>> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
>>> 
 On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution 
  wrote:
 
 It should be possible to declare a function that returns only nil, and 
 have its return type be substitutable for any function that returns and 
 Optional. This is something like having a bottom type but not really. What 
 I mean is:
 
 func returnsNil(errCode:Int) -> nil {
logError(errCode) // A side-effect. Not FP, sosumi.
return nil
 }
 
 func returnAOptional() -> A? {
// Bla bla. We discover an error so we decide to bail and return nil.
return returnsNil(errCode) // Would be legal.
 }
 func returnsBOptional() -> B? {
// Bla bla. We discover an error so we decide to bail and return nil.
return returnsNil(errCode)  // Would also be legal.
 }
 
 I seek a return type that conforms to any Optional -- I think that implies 
 it *must* (or correct me here) be nil.
 
 Now perhaps this is already possible with wizardry from the Next Level. 
 (There always is one.)
>>>  ___
>>> 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] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 9:14 PM, Drew Crawford  wrote:
> 
> Sure, here's the start of the thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>  
> 
Thanks.  Joe was basically saying is that associated types would be 
automatically bound to the existential for their constraints, or Any if there 
are no constraints.  

He didn’t specifically mention anything about Self, but I suppose Self 
requirements could also be automatically bound to Any if the existential type 
doesn’t specify anything more specific, although I’m not sure I would like that 
behavior.

Self is what would apply in the case of:

> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>   if first < second {
> return -1
>   }
>   //...
> }
If Self were automatically bound to Any what would this do?  Would it compile 
and invoke a `<` operator that takes two Any parameters?  That doesn’t seem to 
make sense to me.  It certainly wouldn’t guarantee you get the correct behavior 
if first and second were both Int for example.


> 
> 
>> On Jan 3, 2016, at 9:10 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Jan 3, 2016, at 9:08 PM, Drew Crawford >> > wrote:
>>> 
 Existentials for protocols with Self and / or associated type requirements 
 would require bindings for Self and / or the associated type(s).  At least 
 when you use a member that contains Self and / or an associated type in 
 its signature.  So the previous example will always fail to compile. 
>>> 
>>> Not true.  Joe Groff:
>> 
>> Can you point me to the source?  I would like more context around these 
>> comments.
>> 
>>> 
 This seems like it would be addressed just by allowing Factory to be used 
 as a dynamic type, with its Product type generalized to Any. We'll be set 
 up to support that with some runtime work to store associated types in 
 protocol witness tables (which is also necessary to fix cyclic 
 conformances, one of our Swift 3 goals).
>>> 
>>> 
 Yeah, when generalizing a protocol type, we ought to be able to either 
 generalize the associated types to their upper bounds, for use cases like 
 yours, or constrain them to specific types, for the AnyGenerator kind 
 of case.
>> 
> 

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

Re: [swift-evolution] Declaring a function that always returns nil

[Félix Cloutier via swift-evolution]

IMO, this is the best way to approach it.

Félix

> Le 3 janv. 2016 à 22:54:17, Jack Lawrence via swift-evolution 
>  a écrit :
> 
> You could also use type inference on the return type:
> 
>   1> func returnsNil(errCode: Int) -> T? { 
>   2. print(errCode) 
>   3. return nil 
>   4. } 
>   5> func returnsAnOptional() -> Int? { 
>   6. return returnsNil(5) 
>   7. }
> 
> 
>> On Jan 3, 2016, at 7:51 PM, Jeff Kelley via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Just spit-balling here, but couldn’t you do this with a generic extension on 
>> Optional?
>> 
>>> extension Optional {
>>> func returnsNil(errorCode: Int) -> Wrapped? {
>>> logError(errorCode)
>>> return nil
>>> }
>>> }
>> 
>> 
>> 
>> Jeff Kelley
>> 
>> slauncha...@gmail.com  | @SlaunchaMan 
>>  | jeffkelley.org 
>>> On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> It should be possible to declare a function that returns only nil, and have 
>>> its return type be substitutable for any function that returns and 
>>> Optional. This is something like having a bottom type but not really. What 
>>> I mean is:
>>> 
>>> func returnsNil(errCode:Int) -> nil {
>>>logError(errCode) // A side-effect. Not FP, sosumi.
>>>return nil
>>> }
>>> 
>>> func returnAOptional() -> A? {
>>>// Bla bla. We discover an error so we decide to bail and return nil.
>>>return returnsNil(errCode) // Would be legal.
>>> }
>>> func returnsBOptional() -> B? {
>>>// Bla bla. We discover an error so we decide to bail and return nil.
>>>return returnsNil(errCode)  // Would also be legal.
>>> }
>>> 
>>> I seek a return type that conforms to any Optional -- I think that implies 
>>> it *must* (or correct me here) be nil.
>>> 
>>> Now perhaps this is already possible with wizardry from the Next Level. 
>>> (There always is one.)
>>  ___
>> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Chris Lattner via swift-evolution]

On Jan 3, 2016, at 3:43 PM, Tino Heth <2...@gmx.de> wrote:
>>> Swift has proven it can thrive in secrecy, so I don't think the whole open 
>>> community is a necessity — but as it is now, we should hold transparency in 
>>> high esteem and not start faking democracy.
>> 
>> I’m confused, what are you saying?  No decision has been made here, I’m not 
>> aware of any “secrecy” issue.
> Sorry, it could be that my words don't express exactly what I wanted to say.

No problem at all, I just wanted to clarify your meaning and intention, thanks!

> For me (I guess for others as well :) the decision process is a black box, 
> but I expect the proposals have impact on it — so proposers have some 
> responsibility.
> Loïc and I already had a short conversation, and I have no accusations 
> against him, but rather wanted to criticize a tool that can be 
> instrumentalized easily:
> There has been a poll about which keyword to choose as replacement, and that 
> made his proposal the target for my word of warning…
> 
> I guess most of us agree that surveys have to be taken with a grain of salt, 
> and I think their use should be discouraged for most situations.
> Polls itself can be manipulated in many ways (bias of the author, fake 
> votes…), and there are no rules how to handle the result (an author could 
> cite a survey that supports his standpoint, but he might as well ignore a 
> result he doesn't like).
> 
> Of course, the core team is not bound to the result of any vote, but bad 
> decisions aren't my main concern:
> I don't know how this community will evolve, but I guess there will be 
> natural controversy in the future, there will be temptation to support 
> opinions with unfair methods — and there will be people suspecting or 
> accusing others of using such methods…
> 
> All those bad things are most likely unavoidable, but clear rules could help 
> keeping them at bay.

There is no simple answer here.  Core team members are humans and have 
different things that impact and motivate them.  We intentionally want Swift to 
have a common “center of gravity” and be an “opinionated” language, rather than 
fall to the “design by committee” approach that leads to a watered-down design. 
 This means that decisions are really all shades of gray and cannot be 
specified or predicted by algorithm.  We aim to be as transparent as possible, 
and explain the rationale for decisions when they come out.

That said, I and many other people on the team are highly motivated and 
effected by clear descriptions of problems being solved, and why current 
approaches are wrong.  Particularly moving are things written by people who are 
clearly familiar with Swift as it stands, and who speak to why a change will 
make Swift better.   Someone saying “I saw thing X in language Y, so we should 
transplant it to Swift” - with no further justification - is not very 
motivating, because Swift is much different than any other language Y, and so 
the tradeoffs that make it compelling in Y may not translate over to make it 
compelling in Swift.

> So, I hope my language has been better this time, and that Swift grows up to 
> be a healthy open source project with a great community! (and to make sure I 
> don't get things wrong again: It is already quite healthy and great ;-) 

Me too.  We are definitely all new to this and learning as we go along.  I’m 
sure that we’ll all make mistakes, but we aim to learn from them and adapt & 
change when we do.  Please have patience as this inevitably happens, it is 
because we’re just humans, and all jointly trying to make Swift as great as we 
can!

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

Re: [swift-evolution] Declaring a function that always returns nil

[Jeff Kelley via swift-evolution]

Cleaned up a bit after I tried to actually use it:

> extension Optional {
> static func returnsNil(errorCode: Int) -> Wrapped? {
> logError(errorCode)
> return nil
> }
> }
> 
> extension Int {
> func foo() -> Int? {
> return .returnsNil(12)
> }
> }

You could write it as Optional.returnsNil(12), but the compiler can infer the 
type.


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  | 
jeffkelley.org 
> On Jan 3, 2016, at 10:51 PM, Jeff Kelley  wrote:
> 
> Just spit-balling here, but couldn’t you do this with a generic extension on 
> Optional?
> 
>> extension Optional {
>> func returnsNil(errorCode: Int) -> Wrapped? {
>> logError(errorCode)
>> return nil
>> }
>> }
> 
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
>> On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> It should be possible to declare a function that returns only nil, and have 
>> its return type be substitutable for any function that returns and Optional. 
>> This is something like having a bottom type but not really. What I mean is:
>> 
>> func returnsNil(errCode:Int) -> nil {
>>logError(errCode) // A side-effect. Not FP, sosumi.
>>return nil
>> }
>> 
>> func returnAOptional() -> A? {
>>// Bla bla. We discover an error so we decide to bail and return nil.
>>return returnsNil(errCode) // Would be legal.
>> }
>> func returnsBOptional() -> B? {
>>// Bla bla. We discover an error so we decide to bail and return nil.
>>return returnsNil(errCode)  // Would also be legal.
>> }
>> 
>> I seek a return type that conforms to any Optional -- I think that implies 
>> it *must* (or correct me here) be nil.
>> 
>> Now perhaps this is already possible with wizardry from the Next Level. 
>> (There always is one.)

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

Re: [swift-evolution] Declaring a function that always returns nil

[Jack Lawrence via swift-evolution]

You could also use type inference on the return type:

  1> func returnsNil(errCode: Int) -> T? { 
  2. print(errCode) 
  3. return nil 
  4. } 
  5> func returnsAnOptional() -> Int? { 
  6. return returnsNil(5) 
  7. }


> On Jan 3, 2016, at 7:51 PM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> Just spit-balling here, but couldn’t you do this with a generic extension on 
> Optional?
> 
>> extension Optional {
>> func returnsNil(errorCode: Int) -> Wrapped? {
>> logError(errorCode)
>> return nil
>> }
>> }
> 
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com  | @SlaunchaMan 
>  | jeffkelley.org 
>> On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> It should be possible to declare a function that returns only nil, and have 
>> its return type be substitutable for any function that returns and Optional. 
>> This is something like having a bottom type but not really. What I mean is:
>> 
>> func returnsNil(errCode:Int) -> nil {
>>logError(errCode) // A side-effect. Not FP, sosumi.
>>return nil
>> }
>> 
>> func returnAOptional() -> A? {
>>// Bla bla. We discover an error so we decide to bail and return nil.
>>return returnsNil(errCode) // Would be legal.
>> }
>> func returnsBOptional() -> B? {
>>// Bla bla. We discover an error so we decide to bail and return nil.
>>return returnsNil(errCode)  // Would also be legal.
>> }
>> 
>> I seek a return type that conforms to any Optional -- I think that implies 
>> it *must* (or correct me here) be nil.
>> 
>> Now perhaps this is already possible with wizardry from the Next Level. 
>> (There always is one.)
>  ___
> 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] use standard syntax instead of "do" and "repeat"

[Tyler Fleming Cloutier via swift-evolution]

> On Jan 3, 2016, at 7:38 PM, Matthew Johnson  > wrote:
> 
>> 
>> On Jan 3, 2016, at 9:31 PM, Tyler Fleming Cloutier via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Please see inline comments.
>> 
>> 
>>> On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Indeed both are reasonable but perhaps suboptimal. Consider the following 
>>> potential changes.
>>> 
>>> 
>>> // Assume this code is included for the below examples.
>>> func myThrowingFunc() throws -> String {
>>> if drand48() < 0.5 {
>>> throw NSError(domain: "", code: 0, userInfo: nil)
>>> }
>>> return ""
>>> }
>>> let str: String
>>> 
>>> 
>>> 
>>> The current syntax is very clear and straightforward. 
>>> 
>>> // Current syntax
>>> do {
>>> str = try myThrowingFunc().stringByAppendingString("appended")
>>> } catch {
>>> str = "Default"
>>> print("caught!")
>>> }
>>> 
>>> There are two potential issues with it however. The first is that it is 
>>> quite verbose, and the second is that the try is actually marking two 
>>> function calls, one which throws and one which does not. In this fake 
>>> example it’s clear that myThrowingFunc throws, but in general try is not 
>>> marking a single point of failure.
>>> 
>>> 
>>> 
>>> One change might be to simply rename do blocks that can throw to try 
>>> blocks. 
>>> 
>>> // Create try blocks which encapsulate potentially throwing code.
>>> try {
>>> str = try myThrowingFunc().stringByAppendingString("appended")
>>> } catch {
>>> str = "Default"
>>> print("caught!")
>>> }
>>> 
>>> The motivation for doing this would be to clarify the difference between 
>>> blocks that can throw and blocks that can’t. For example, it’s helpful to 
>>> not have to scroll to the bottom of a long block to find catch, or scan 
>>> through all the lines to find the try keyword for a long block. You would 
>>> be able to see just from try that block was throwing. It would also be 
>>> similar to many other languages that use try to demarcate throwing blocks. 
>>> The problems with this are that it could be considered redundant, and is 
>>> even more verbose (by 1 character) than the current syntax. Furthermore, as 
>>> with the current syntax, try is not marking a single point of failure (and 
>>> yet now we have to try keywords).
>>> 
>>> 
>>> 
>>> Another change could be to rename do blocks that can throw to try blocks 
>>> and then not require explicit marking of try on throwing statements.
>>> 
>>> // Don't require explicit try marking within try blocks.
>>> try {
>>> str = myThrowingFunc().stringByAppendingString("appended")
>>> } catch {
>>> str = "Default"
>>> print("caught!")
>>> }
>>> 
>>> This approach retains all of the benefits of the above change, including 
>>> familiarity for those coming from other languages. Also, it no longer 
>>> requires the redundant double try syntax. In this case try is not assumed 
>>> to be marking a single potentially failing call, but a group of them. 
>>> Unfortunately, this means that it might not be clear which function is the 
>>> function that can throw, in a block of code. However, this is already 
>>> somewhat the case for chained calls in the current syntax. Certainly, only 
>>> allowing this ambiguity for chained calls reduces the potential size of the 
>>> code that is unmarked, with functional paradigms long chains are not so 
>>> uncommon.
>>> 
>>> 
>>> 
>>> The final change that I have included above is really just a shortening of 
>>> syntax and could be applied to any of the above implementations to reduce 
>>> verbosity.
>>> 
>> 
>> I have included below*
>> 
>> 
>>> // Allow catch directly on try expression.
>>> let str = try myThrowingFunc().stringByAppendingString("appended”) catch {
>>> str = "Default"
>>> print("caught!")
>>> }
>>> 
>>> This also has the added benefit of not having to open up a new scope just 
>>> to catch an error. Additionally it’s very easy to refactor into a try? 
>>> statement.
>>> 
>>> I’d really like to see how these changes might affect real world examples 
>>> and if I get some time, I will look for some and share them with the list. 
>>> That way we can really see what the effects of these changes would be 
>>> within the context of an actual use case.
>>> 
 What would you think about a solution that just inverted the default.  
 Rather than marking throwing expressions with `try` we could have a try 
 block (with optional catch clauses) where non-throwing calls are marked 
 with `do`.  The primary motivation for requiring `do` would be to prevent 
 abuse of `try` blocks by making them awkward when there is a reasonable 
 mix of throwing and non-throwing code.  A secondary benefit is that would 
 still be clear what can throw and what can’t, although this is much less 
 useful when most things can throw.
>>> 
>>> A

Re: [swift-evolution] Declaring a function that always returns nil

[Jeff Kelley via swift-evolution]

Just spit-balling here, but couldn’t you do this with a generic extension on 
Optional?

> extension Optional {
> func returnsNil(errorCode: Int) -> Wrapped? {
> logError(errorCode)
> return nil
> }
> }



Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  | 
jeffkelley.org 
> On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution 
>  wrote:
> 
> It should be possible to declare a function that returns only nil, and have 
> its return type be substitutable for any function that returns and Optional. 
> This is something like having a bottom type but not really. What I mean is:
> 
> func returnsNil(errCode:Int) -> nil {
>logError(errCode) // A side-effect. Not FP, sosumi.
>return nil
> }
> 
> func returnAOptional() -> A? {
>// Bla bla. We discover an error so we decide to bail and return nil.
>return returnsNil(errCode) // Would be legal.
> }
> func returnsBOptional() -> B? {
>// Bla bla. We discover an error so we decide to bail and return nil.
>return returnsNil(errCode)  // Would also be legal.
> }
> 
> I seek a return type that conforms to any Optional -- I think that implies it 
> *must* (or correct me here) be nil.
> 
> Now perhaps this is already possible with wizardry from the Next Level. 
> (There always is one.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Andrew Duncan via swift-evolution]

> On 3 Jan, 2016, at 10:51, David Waite  wrote:
> 
> One possible approach if it was desirable to not have this used arbitrarily 
> in place of do+try, and to avoid looking too much like exception syntax: 
> instead define rethrows blocks:
> 
>   func recognizeHandler() throws {
>   rethrows {
>accept(.on)
>recognizeName()
>recognizeFormalParamSeq()
>accept(.newline)
>recognizeCommandSeq()
>accept(.end)
>recognizeName()   
>accept(.newline)
>   }
>   }

Not bad, modulo all the subsequent reasonable comments, of course.

It is worth pointing out that (some would say) this is not error-handling at 
all. It’s a normal part of the recognizer life-cycle that it finds a syntax 
error in the source code. True, it is the (l)user’s error, but not mine. (Those 
have full-on asserts. Hey, could we have Eiffel-style contracts? Oops, new 
thread.)

What I am after here is a quick-and-clean way to unwind the stack. My throwing 
recognizer has about 200 “try” statements in it. I tried (NPI) this both with 
exceptions and with Optional return values. Hard to say which I prefer. But is 
it not more or less the same underneath the hood? I gather that Swift adds an 
extra return value for throwing functions.


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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Chris Lattner via swift-evolution]

> On Jan 3, 2016, at 6:36 PM, Matthew Johnson via swift-evolution 
>  wrote:
>>> 
>>> I agree that requiring this is not likely to result in improved error 
>>> handling and thus is not a strong argument in favor of it.
>>> 
>>> IMO the purpose of requiring “try” to be stated explicitly is that it 
>>> arguably makes code more readable.  It is immediately clear which functions 
>>> can throw and which cannot.  You don’t need to look up the signature of 
>>> every function called to determine this. My experience thus far has been 
>>> that I have really appreciated the requirement that throwing expressions be 
>>> explicitly marked. 
>> 
>> As a default it’s great.  Not having a way to opt out of individual marking 
>> for a whole block or function—because you know you’re not breaking any 
>> invariants, so which functions can throw is irrelevant, and not having a way 
>> for the compiler deduce these regions (e.g. known pure functions)—is the 
>> problem.  The recognizer code posted in an earlier message is a perfect 
>> example.  If there *was* some code where it was really important to notice 
>> failure points, you’d miss it. 
> 
> I feel like I must be missing something here.  If we are able to mark the 
> whole block with try I don’t see how we would notice any really important 
> failure points.  They would not be marked anywhere in the source:
> 
>   func recognizeHandler() throws {
> try {
> accept(.on)// .on is an enum tag for the token for the ‘on’ 
> keyword.
> recognizeName()
> recognizeFormalParamSeq()
> accept(.newline)
> recognizeCommandSeq()
> accept(.end)
> recognizeName()// Later Visitor pass checks that names match. 
> accept(.newline)
> }
>   }


Indeed.  Also, FWIW, I’d argue that maybe the root problem here is that this 
code should not be using Swift’s error handling constructs in the first place.  
An enum (or other approach) may be more appropriate.  Swift’s error handling 
design is intentionally driven by the idea that you shouldn’t use it if 
“everything throws” - in this situation, the sugar benefits of error handling 
are intentionally outweighed by the weight of the try keywords everywhere.  
This is meant to force the balance over to using more manual techniques.

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

[swift-evolution] Declaring a function that always returns nil

[Andrew Duncan via swift-evolution]

It should be possible to declare a function that returns only nil, and have its 
return type be substitutable for any function that returns and Optional. This 
is something like having a bottom type but not really. What I mean is:

func returnsNil(errCode:Int) -> nil {
logError(errCode) // A side-effect. Not FP, sosumi.
return nil
}

func returnAOptional() -> A? {
// Bla bla. We discover an error so we decide to bail and return nil.
return returnsNil(errCode) // Would be legal.
}
func returnsBOptional() -> B? {
// Bla bla. We discover an error so we decide to bail and return nil.
return returnsNil(errCode)  // Would also be legal.
}

I seek a return type that conforms to any Optional -- I think that implies it 
*must* (or correct me here) be nil.

Now perhaps this is already possible with wizardry from the Next Level. (There 
always is one.)

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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 9:31 PM, Tyler Fleming Cloutier via swift-evolution 
>  wrote:
> 
> Please see inline comments.
> 
> 
>> On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Indeed both are reasonable but perhaps suboptimal. Consider the following 
>> potential changes.
>> 
>> 
>> // Assume this code is included for the below examples.
>> func myThrowingFunc() throws -> String {
>> if drand48() < 0.5 {
>> throw NSError(domain: "", code: 0, userInfo: nil)
>> }
>> return ""
>> }
>> let str: String
>> 
>> 
>> 
>> The current syntax is very clear and straightforward. 
>> 
>> // Current syntax
>> do {
>> str = try myThrowingFunc().stringByAppendingString("appended")
>> } catch {
>> str = "Default"
>> print("caught!")
>> }
>> 
>> There are two potential issues with it however. The first is that it is 
>> quite verbose, and the second is that the try is actually marking two 
>> function calls, one which throws and one which does not. In this fake 
>> example it’s clear that myThrowingFunc throws, but in general try is not 
>> marking a single point of failure.
>> 
>> 
>> 
>> One change might be to simply rename do blocks that can throw to try blocks. 
>> 
>> // Create try blocks which encapsulate potentially throwing code.
>> try {
>> str = try myThrowingFunc().stringByAppendingString("appended")
>> } catch {
>> str = "Default"
>> print("caught!")
>> }
>> 
>> The motivation for doing this would be to clarify the difference between 
>> blocks that can throw and blocks that can’t. For example, it’s helpful to 
>> not have to scroll to the bottom of a long block to find catch, or scan 
>> through all the lines to find the try keyword for a long block. You would be 
>> able to see just from try that block was throwing. It would also be similar 
>> to many other languages that use try to demarcate throwing blocks. The 
>> problems with this are that it could be considered redundant, and is even 
>> more verbose (by 1 character) than the current syntax. Furthermore, as with 
>> the current syntax, try is not marking a single point of failure (and yet 
>> now we have to try keywords).
>> 
>> 
>> 
>> Another change could be to rename do blocks that can throw to try blocks and 
>> then not require explicit marking of try on throwing statements.
>> 
>> // Don't require explicit try marking within try blocks.
>> try {
>> str = myThrowingFunc().stringByAppendingString("appended")
>> } catch {
>> str = "Default"
>> print("caught!")
>> }
>> 
>> This approach retains all of the benefits of the above change, including 
>> familiarity for those coming from other languages. Also, it no longer 
>> requires the redundant double try syntax. In this case try is not assumed to 
>> be marking a single potentially failing call, but a group of them. 
>> Unfortunately, this means that it might not be clear which function is the 
>> function that can throw, in a block of code. However, this is already 
>> somewhat the case for chained calls in the current syntax. Certainly, only 
>> allowing this ambiguity for chained calls reduces the potential size of the 
>> code that is unmarked, with functional paradigms long chains are not so 
>> uncommon.
>> 
>> 
>> 
>> The final change that I have included above is really just a shortening of 
>> syntax and could be applied to any of the above implementations to reduce 
>> verbosity.
>> 
> 
> I have included below*
> 
> 
>> // Allow catch directly on try expression.
>> let str = try myThrowingFunc().stringByAppendingString("appended”) catch {
>> str = "Default"
>> print("caught!")
>> }
>> 
>> This also has the added benefit of not having to open up a new scope just to 
>> catch an error. Additionally it’s very easy to refactor into a try? 
>> statement.
>> 
>> I’d really like to see how these changes might affect real world examples 
>> and if I get some time, I will look for some and share them with the list. 
>> That way we can really see what the effects of these changes would be within 
>> the context of an actual use case.
>> 
>>> What would you think about a solution that just inverted the default.  
>>> Rather than marking throwing expressions with `try` we could have a try 
>>> block (with optional catch clauses) where non-throwing calls are marked 
>>> with `do`.  The primary motivation for requiring `do` would be to prevent 
>>> abuse of `try` blocks by making them awkward when there is a reasonable mix 
>>> of throwing and non-throwing code.  A secondary benefit is that would still 
>>> be clear what can throw and what can’t, although this is much less useful 
>>> when most things can throw.
>> 
>> Also Matthew, I think this is an interesting idea. And I’d say you’ve hit on 
>> the major problem with try blocks, potential excessive mixing of throwing 
>> and non throwing code. You could perhaps enforce that try blocks must begin 
>> and end with a po

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Tyler Fleming Cloutier via swift-evolution]

Please see inline comments.


> On Jan 3, 2016, at 6:48 PM, Tyler Fleming Cloutier via swift-evolution 
>  wrote:
> 
> Indeed both are reasonable but perhaps suboptimal. Consider the following 
> potential changes.
> 
> 
> // Assume this code is included for the below examples.
> func myThrowingFunc() throws -> String {
> if drand48() < 0.5 {
> throw NSError(domain: "", code: 0, userInfo: nil)
> }
> return ""
> }
> let str: String
> 
> 
> 
> The current syntax is very clear and straightforward. 
> 
> // Current syntax
> do {
> str = try myThrowingFunc().stringByAppendingString("appended")
> } catch {
> str = "Default"
> print("caught!")
> }
> 
> There are two potential issues with it however. The first is that it is quite 
> verbose, and the second is that the try is actually marking two function 
> calls, one which throws and one which does not. In this fake example it’s 
> clear that myThrowingFunc throws, but in general try is not marking a single 
> point of failure.
> 
> 
> 
> One change might be to simply rename do blocks that can throw to try blocks. 
> 
> // Create try blocks which encapsulate potentially throwing code.
> try {
> str = try myThrowingFunc().stringByAppendingString("appended")
> } catch {
> str = "Default"
> print("caught!")
> }
> 
> The motivation for doing this would be to clarify the difference between 
> blocks that can throw and blocks that can’t. For example, it’s helpful to not 
> have to scroll to the bottom of a long block to find catch, or scan through 
> all the lines to find the try keyword for a long block. You would be able to 
> see just from try that block was throwing. It would also be similar to many 
> other languages that use try to demarcate throwing blocks. The problems with 
> this are that it could be considered redundant, and is even more verbose (by 
> 1 character) than the current syntax. Furthermore, as with the current 
> syntax, try is not marking a single point of failure (and yet now we have to 
> try keywords).
> 
> 
> 
> Another change could be to rename do blocks that can throw to try blocks and 
> then not require explicit marking of try on throwing statements.
> 
> // Don't require explicit try marking within try blocks.
> try {
> str = myThrowingFunc().stringByAppendingString("appended")
> } catch {
> str = "Default"
> print("caught!")
> }
> 
> This approach retains all of the benefits of the above change, including 
> familiarity for those coming from other languages. Also, it no longer 
> requires the redundant double try syntax. In this case try is not assumed to 
> be marking a single potentially failing call, but a group of them. 
> Unfortunately, this means that it might not be clear which function is the 
> function that can throw, in a block of code. However, this is already 
> somewhat the case for chained calls in the current syntax. Certainly, only 
> allowing this ambiguity for chained calls reduces the potential size of the 
> code that is unmarked, with functional paradigms long chains are not so 
> uncommon.
> 
> 
> 
> The final change that I have included above is really just a shortening of 
> syntax and could be applied to any of the above implementations to reduce 
> verbosity.
> 

I have included below*


> // Allow catch directly on try expression.
> let str = try myThrowingFunc().stringByAppendingString("appended”) catch {
> str = "Default"
> print("caught!")
> }
> 
> This also has the added benefit of not having to open up a new scope just to 
> catch an error. Additionally it’s very easy to refactor into a try? statement.
> 
> I’d really like to see how these changes might affect real world examples and 
> if I get some time, I will look for some and share them with the list. That 
> way we can really see what the effects of these changes would be within the 
> context of an actual use case.
> 
>> What would you think about a solution that just inverted the default.  
>> Rather than marking throwing expressions with `try` we could have a try 
>> block (with optional catch clauses) where non-throwing calls are marked with 
>> `do`.  The primary motivation for requiring `do` would be to prevent abuse 
>> of `try` blocks by making them awkward when there is a reasonable mix of 
>> throwing and non-throwing code.  A secondary benefit is that would still be 
>> clear what can throw and what can’t, although this is much less useful when 
>> most things can throw.
> 
> Also Matthew, I think this is an interesting idea. And I’d say you’ve hit on 
> the major problem with try blocks, potential excessive mixing of throwing and 
> non throwing code. You could perhaps enforce that try blocks must begin and 
> end with a potentially throwing statement to cut down on mixing, but people 
> might find that strange/confusing.
> 

You might even compromise to allow try blocks, but only in the case where every 
single statement can throw. This would at least solve the problem of

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Chris Lattner via swift-evolution]

We need a token to be unambiguously an operator or identifier - we can have 
different rules for the leading and subsequent characters though.

-Chris

> On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch  wrote:
> 
> Is it considered infeasible for any characters to be allowed in both 
> identifiers and operators?
> 
>> On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
>> >  wrote:
>> >
>> >> Swift currently does not allow operators to use $ - I assume because the 
>> >> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
>> >> why an entire class of identifiers has been eliminated, so I propose $ 
>> >> instead be reclassified as an `operator-character` so it can be used 
>> >> mixed in with other such characters, but prevents the introduction of 
>> >> `$Identifier`-style declarations that might conflict with implicit 
>> >> parameters.
>> >
>> > I believe the reason you don't see any other $ variables is that they're 
>> > reserved for the debugger and REPL.
>> >
>> >   brent@Brents-MacBook-Pro ~/D/Code> swift
>> >   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
>> > clang-700.1.81). Type :help for assistance.
>> > 1> "foo"
>> >   $R0: String = "foo"
>> > 2> print($R0)
>> >   foo
>> 
>> Right.  That said, our current operator space (particularly the unicode 
>> segments covered) is not super well considered.  It would be great for 
>> someone to take a more systematic pass over them to rationalize things.
>> 
>> -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] [Proposal] Separate protocols and interfaces

[Drew Crawford via swift-evolution]

Sure, here's the start of the thread: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
 



> On Jan 3, 2016, at 9:10 PM, Matthew Johnson  wrote:
> 
> 
>> On Jan 3, 2016, at 9:08 PM, Drew Crawford  wrote:
>> 
>>> Existentials for protocols with Self and / or associated type requirements 
>>> would require bindings for Self and / or the associated type(s).  At least 
>>> when you use a member that contains Self and / or an associated type in its 
>>> signature.  So the previous example will always fail to compile. 
>> 
>> Not true.  Joe Groff:
> 
> Can you point me to the source?  I would like more context around these 
> comments.
> 
>> 
>>> This seems like it would be addressed just by allowing Factory to be used 
>>> as a dynamic type, with its Product type generalized to Any. We'll be set 
>>> up to support that with some runtime work to store associated types in 
>>> protocol witness tables (which is also necessary to fix cyclic 
>>> conformances, one of our Swift 3 goals).
>> 
>> 
>>> Yeah, when generalizing a protocol type, we ought to be able to either 
>>> generalize the associated types to their upper bounds, for use cases like 
>>> yours, or constrain them to specific types, for the AnyGenerator kind of 
>>> case.
> 

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 9:08 PM, Drew Crawford  wrote:
> 
>> Existentials for protocols with Self and / or associated type requirements 
>> would require bindings for Self and / or the associated type(s).  At least 
>> when you use a member that contains Self and / or an associated type in its 
>> signature.  So the previous example will always fail to compile. 
> 
> Not true.  Joe Groff:

Can you point me to the source?  I would like more context around these 
comments.

> 
>> This seems like it would be addressed just by allowing Factory to be used as 
>> a dynamic type, with its Product type generalized to Any. We'll be set up to 
>> support that with some runtime work to store associated types in protocol 
>> witness tables (which is also necessary to fix cyclic conformances, one of 
>> our Swift 3 goals).
> 
> 
>> Yeah, when generalizing a protocol type, we ought to be able to either 
>> generalize the associated types to their upper bounds, for use cases like 
>> yours, or constrain them to specific types, for the AnyGenerator kind of 
>> case.

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Drew Crawford via swift-evolution]

> Existentials for protocols with Self and / or associated type requirements 
> would require bindings for Self and / or the associated type(s).  At least 
> when you use a member that contains Self and / or an associated type in its 
> signature.  So the previous example will always fail to compile. 

Not true.  Joe Groff:

> This seems like it would be addressed just by allowing Factory to be used as 
> a dynamic type, with its Product type generalized to Any. We'll be set up to 
> support that with some runtime work to store associated types in protocol 
> witness tables (which is also necessary to fix cyclic conformances, one of 
> our Swift 3 goals).


> Yeah, when generalizing a protocol type, we ought to be able to either 
> generalize the associated types to their upper bounds, for use cases like 
> yours, or constrain them to specific types, for the AnyGenerator kind of 
> case.




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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> I offer a +1, but I have two criticisms of the proposal.
> 
> The first is that the example given in the proposal is stated a lot more 
> strongly than is true:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
>> The code above yields an error, and rightfully so, because if the real types 
>> of first and second are not equal, they cannot actually be compared.
>> 
> It is true for Swift 2 code.  However, whether this is true forever is less 
> clear.  There is a thread here discussing "existential protocols", which 
> AFAIK would make this code listing into a non-error, and in that thread 
> Douglas Gregor said:
> 
>> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
>> I think it’s very, very cool, but it’s complicated and we need a while to 
>> understand its overall effects.

Existentials for protocols with Self and / or associated type requirements 
would require bindings for Self and / or the associated type(s).  At least when 
you use a member that contains Self and / or an associated type in its 
signature.  So the previous example will always fail to compile. 

> 
> As long as the door is open to allowing the syntax, I think saying something 
> strong and normative about it in an official proposal would be a mistake.  
> The example is fine, but the comment should be that this "currently errors" 
> or "surprises new programmers" or something weaker than "it's obvious to all 
> of us this shouldn't work" because it's obvious to some people that it should 
> work after all.
> 
> The second thing is that I think using the words "dynamically dispatched" or 
> "dynamically dispatched interfaces" in the body of the proposal is a mistake. 
>  It is not that interfaces "are" dynamically dispatched.  It is that they may 
> be, e.g. that the compiler may select a dynamic implementation (or it may be 
> able to find a static implementation), whereas for a protocol the compiler is 
> guaranteed to use a static implementation.  This is I think more consistent 
> with CL's position on static/dynamic in Swift 
> 
>  generally.  So I think we should find a turn of phrase like "behaves 
> dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* 
> dynamically dispatched" as if we will force the optimizer to spit out a 
> vtable when it can find a static implementation.
> 
> With those two details resolved I think it is a strong proposal, and very 
> much in line with the proposal we're reviewing about separating typealias vs 
> associatedtype, which strikes at a similar confusion where we're separating 
> two different concepts into their own keywords.
> 
> 
>> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> +1 to "opening" values of existential type, I remember trying (and failing) 
>> to do this when Swift 1 came out. Being able to capture the dynamic type of 
>> an object at runtime and do stuff with it would be incredible.
>> 
>> Austin
>> 
>> On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> This would be wonderful - is it something that could happen in the Swift 3 
>> timeframe? Is it something that myself or someone else could work on a 
>> formal proposal for?
>> 
>> -DW
>> 
>>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Introduction of interfaces will clean up the current blend of static and 
 dynamic protocols, and solve at least three popular issues.
 Please see:
 https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
  
 
>>> I am *completely* against this proposal.
>>> 
>>> Fundamentally, you're trying to address the limitation that protocols with 
>>> Self or associated type requirements can't be existential. But it's just a 
>>> limitation that isn't (conceptually) that hard to fix: the primary 
>>> operation you need to work with an existing of such a protocol is to "open" 
>>> a value of existential type, giving a name to the dynamic type it stores. 
>>> Let's invent one:
>>> 
>>>   func eq(x: Equatable, y: Equatable) -> Bool {
>>> // give the name T to the dynamic type stored in xT
>>> let xT = open x as T
>>> // is y also storing a T?
>>> guard let yT = y as? T else { return false }
>>> // check whether the Ts are equal
>>> return xT == yT
>>>   }
>>> 
>>> Ignore the syntax: semantically, w

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Drew Crawford via swift-evolution]

I offer a +1, but I have two criticisms of the proposal.

The first is that the example given in the proposal is stated a lot more 
strongly than is true:

> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>   if first < second {
> return -1
>   }
>   //...
> }
> The code above yields an error, and rightfully so, because if the real types 
> of first and second are not equal, they cannot actually be compared.
> 
It is true for Swift 2 code.  However, whether this is true forever is less 
clear.  There is a thread here discussing "existential protocols", which AFAIK 
would make this code listing into a non-error, and in that thread Douglas 
Gregor said:

> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
> I think it’s very, very cool, but it’s complicated and we need a while to 
> understand its overall effects.

As long as the door is open to allowing the syntax, I think saying something 
strong and normative about it in an official proposal would be a mistake.  The 
example is fine, but the comment should be that this "currently errors" or 
"surprises new programmers" or something weaker than "it's obvious to all of us 
this shouldn't work" because it's obvious to some people that it should work 
after all.

The second thing is that I think using the words "dynamically dispatched" or 
"dynamically dispatched interfaces" in the body of the proposal is a mistake.  
It is not that interfaces "are" dynamically dispatched.  It is that they may 
be, e.g. that the compiler may select a dynamic implementation (or it may be 
able to find a static implementation), whereas for a protocol the compiler is 
guaranteed to use a static implementation.  This is I think more consistent 
with CL's position on static/dynamic in Swift 

 generally.  So I think we should find a turn of phrase like "behaves 
dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* 
dynamically dispatched" as if we will force the optimizer to spit out a vtable 
when it can find a static implementation.

With those two details resolved I think it is a strong proposal, and very much 
in line with the proposal we're reviewing about separating typealias vs 
associatedtype, which strikes at a similar confusion where we're separating two 
different concepts into their own keywords.


> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> +1 to "opening" values of existential type, I remember trying (and failing) 
> to do this when Swift 1 came out. Being able to capture the dynamic type of 
> an object at runtime and do stuff with it would be incredible.
> 
> Austin
> 
> On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> This would be wonderful - is it something that could happen in the Swift 3 
> timeframe? Is it something that myself or someone else could work on a formal 
> proposal for?
> 
> -DW
> 
>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Introduction of interfaces will clean up the current blend of static and 
>>> dynamic protocols, and solve at least three popular issues.
>>> Please see:
>>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>>  
>>> 
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations that do this internally. They have no spelling in Swift code, but 
>> they are useful to describe operations on ex

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Tyler Fleming Cloutier via swift-evolution]

Indeed both are reasonable but perhaps suboptimal. Consider the following 
potential changes.


// Assume this code is included for the below examples.
func myThrowingFunc() throws -> String {
if drand48() < 0.5 {
throw NSError(domain: "", code: 0, userInfo: nil)
}
return ""
}
let str: String



The current syntax is very clear and straightforward. 

// Current syntax
do {
str = try myThrowingFunc().stringByAppendingString("appended")
} catch {
str = "Default"
print("caught!")
}

There are two potential issues with it however. The first is that it is quite 
verbose, and the second is that the try is actually marking two function calls, 
one which throws and one which does not. In this fake example it’s clear that 
myThrowingFunc throws, but in general try is not marking a single point of 
failure.



One change might be to simply rename do blocks that can throw to try blocks. 

// Create try blocks which encapsulate potentially throwing code.
try {
str = try myThrowingFunc().stringByAppendingString("appended")
} catch {
str = "Default"
print("caught!")
}

The motivation for doing this would be to clarify the difference between blocks 
that can throw and blocks that can’t. For example, it’s helpful to not have to 
scroll to the bottom of a long block to find catch, or scan through all the 
lines to find the try keyword for a long block. You would be able to see just 
from try that block was throwing. It would also be similar to many other 
languages that use try to demarcate throwing blocks. The problems with this are 
that it could be considered redundant, and is even more verbose (by 1 
character) than the current syntax. Furthermore, as with the current syntax, 
try is not marking a single point of failure (and yet now we have to try 
keywords).



Another change could be to rename do blocks that can throw to try blocks and 
then not require explicit marking of try on throwing statements.

// Don't require explicit try marking within try blocks.
try {
str = myThrowingFunc().stringByAppendingString("appended")
} catch {
str = "Default"
print("caught!")
}

This approach retains all of the benefits of the above change, including 
familiarity for those coming from other languages. Also, it no longer requires 
the redundant double try syntax. In this case try is not assumed to be marking 
a single potentially failing call, but a group of them. Unfortunately, this 
means that it might not be clear which function is the function that can throw, 
in a block of code. However, this is already somewhat the case for chained 
calls in the current syntax. Certainly, only allowing this ambiguity for 
chained calls reduces the potential size of the code that is unmarked, with 
functional paradigms long chains are not so uncommon.



The final change that I have included above is really just a shortening of 
syntax and could be applied to any of the above implementations to reduce 
verbosity.

// Allow catch directly on try expression.
let str = try myThrowingFunc().stringByAppendingString("appended”) catch {
str = "Default"
print("caught!")
}

This also has the added benefit of not having to open up a new scope just to 
catch an error. Additionally it’s very easy to refactor into a try? statement.

I’d really like to see how these changes might affect real world examples and 
if I get some time, I will look for some and share them with the list. That way 
we can really see what the effects of these changes would be within the context 
of an actual use case.

> What would you think about a solution that just inverted the default.  Rather 
> than marking throwing expressions with `try` we could have a try block (with 
> optional catch clauses) where non-throwing calls are marked with `do`.  The 
> primary motivation for requiring `do` would be to prevent abuse of `try` 
> blocks by making them awkward when there is a reasonable mix of throwing and 
> non-throwing code.  A secondary benefit is that would still be clear what can 
> throw and what can’t, although this is much less useful when most things can 
> throw.

Also Matthew, I think this is an interesting idea. And I’d say you’ve hit on 
the major problem with try blocks, potential excessive mixing of throwing and 
non throwing code. You could perhaps enforce that try blocks must begin and end 
with a potentially throwing statement to cut down on mixing, but people might 
find that strange/confusing.

Tyler

> On Jan 3, 2016, at 11:37 AM, Dave Abrahams  wrote:
> 
>> 
>> On Jan 3, 2016, at 10:21 AM, Matthew Johnson  wrote:
>> 
>>> 
>>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
 
 Please see comments inline.
 
> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>>>  wro

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 1:37 PM, Dave Abrahams  wrote:
> 
>> 
>> On Jan 3, 2016, at 10:21 AM, Matthew Johnson  wrote:
>> 
>>> 
>>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
 
 Please see comments inline.
 
> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> So “try” instead of “do”. If there is no catch, then just use braces 
>>> without a keyword for a block. 
>>> 
>>> And use do-while instead of repeat-while.
> 
> +1
> 
>> 
>> Do you also propose no longer marking calls to throwing functions with 
>> `try`?
> 
> If try had both a single-statement/expression form as it does today, and 
> a block form that makes it unnecessary to mark all the individual 
> statements in the block, that would be an improvement.
> 
>> Have you read the "Error-Handling Rationale" document in the Swift 
>> repository? If not, please do: 
>> 
>>  If so, please explain why you disagree with it.
> 
> There are large classes of programs where you can know you don’t care 
> exactly where a failure happens, e.g. (most init functions, all pure 
> functions, any function that doesn’t break invariants).  In these cases 
> marking every statement or expression that can throw is just noise.  Try 
> writing some serialization/deserialization code where the underlying 
> stream can fail to see what I mean; you’ll have “try” everwhere, and it 
> adds nothing to comprehensibility or maintainability.  Personally I would 
> like to be able to label the function itself and not have to introuce a 
> scope, but IMO being able to create “try blocks” would be a welcome 
> addition and would even match the common case in blocks with catch 
> clauses, where being aware of the exact line where the error was 
> generated is typically not useful.
 
 I had proposed something very similar to this around six months ago on the 
 swift-users list, but I think John McCall, had some (quite valid) concerns 
 with this.
 
 Unfortunately I can't access those emails, but I think his concern was 
 that the purpose of try was to mark explicitly which statements throw and 
 this would defeat the purpose of that. People might just wrap large blocks 
 in try.
>>> 
>>> As much as I am loath to disagree with John on this, there’s an incorrect 
>>> implicit assumption in that rationale, that forcing people to mark all 
>>> throw points trains them to get error-handling correct.  What it does 
>>> instead is to train them to think of all code uniformly instead of 
>>> recognizing the places where a throw needs special attention (places where 
>>> there are broken invariants). Eventually, as with warnings that have a high 
>>> false-positive rate, when you see “try” in many places where it doesn’t 
>>> help, you learn to ignore it altogether.
>> 
>> I agree that requiring this is not likely to result in improved error 
>> handling and thus is not a strong argument in favor of it.
>> 
>> IMO the purpose of requiring “try” to be stated explicitly is that it 
>> arguably makes code more readable.  It is immediately clear which functions 
>> can throw and which cannot.  You don’t need to look up the signature of 
>> every function called to determine this. My experience thus far has been 
>> that I have really appreciated the requirement that throwing expressions be 
>> explicitly marked. 
> 
> As a default it’s great.  Not having a way to opt out of individual marking 
> for a whole block or function—because you know you’re not breaking any 
> invariants, so which functions can throw is irrelevant, and not having a way 
> for the compiler deduce these regions (e.g. known pure functions)—is the 
> problem.  The recognizer code posted in an earlier message is a perfect 
> example.  If there *was* some code where it was really important to notice 
> failure points, you’d miss it. 

I feel like I must be missing something here.  If we are able to mark the whole 
block with try I don’t see how we would notice any really important failure 
points.  They would not be marked anywhere in the source:

  func recognizeHandler() throws {
try {
accept(.on)// .on is an enum tag for the token for the ‘on’ 
keyword.
recognizeName()
recognizeFormalParamSeq()
accept(.newline)
recognizeCommandSeq()
accept(.end)
recognizeName()// Later Visitor pass checks that names match. 
accept(.newline)
}
  }

> 
> The key to getting error handling right is not being able to trace every 
> possible control path—which is effectively 

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Jacob Bandes-Storch via swift-evolution]

That's an interesting issue, I think you're right. Technically I think it
would only be a problem if you omitted spaces: "a<$>b", since infix
identifiers aren't allowed to have a space on one side but not the other
(thus "a <$> b" couldn't be ">(<(a, $), b)", but "a<$>b" could).

Jacob

On Sun, Jan 3, 2016 at 6:27 PM, Félix Cloutier  wrote:

> I'm routinely proven wrong, but if $ was allowed to be either an operator
> or an identifier, it seems to me that `a <$> b` could produce two different
> and (potentially) valid ASTs depending only on whether <$> exists as an
> operator. Some people don't like operator overloading, imagine if you told
> them that they can't even be sure that what they're looking at is an
> operator at all.
>
> Félix
>
> Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Is it considered infeasible for any characters to be allowed in both
> identifiers and operators?
>
> On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >> Swift currently does not allow operators to use $ - I assume because
>> the grammar reserves it in one place: `implicit-parameter-name`.  I don't
>> see why an entire class of identifiers has been eliminated, so I propose $
>> instead be reclassified as an `operator-character` so it can be used mixed
>> in with other such characters, but prevents the introduction of
>> `$Identifier`-style declarations that might conflict with implicit
>> parameters.
>> >
>> > I believe the reason you don't see any other $ variables is that
>> they're reserved for the debugger and REPL.
>> >
>> >   brent@Brents-MacBook-Pro ~/D/Code> swift
>> >   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15
>> clang-700.1.81). Type :help for assistance.
>> > 1> "foo"
>> >   $R0: String = "foo"
>> > 2> print($R0)
>> >   foo
>>
>> Right.  That said, our current operator space (particularly the unicode
>> segments covered) is not super well considered.  It would be great for
>> someone to take a more systematic pass over them to rationalize things.
>>
>> -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] [Proposal]: Free the '$' Symbol!

[Félix Cloutier via swift-evolution]

I'm routinely proven wrong, but if $ was allowed to be either an operator or an 
identifier, it seems to me that `a <$> b` could produce two different and 
(potentially) valid ASTs depending only on whether <$> exists as an operator. 
Some people don't like operator overloading, imagine if you told them that they 
can't even be sure that what they're looking at is an operator at all.

Félix

> Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution 
>  a écrit :
> 
> Is it considered infeasible for any characters to be allowed in both 
> identifiers and operators?
> 
> On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> >> Swift currently does not allow operators to use $ - I assume because the 
> >> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
> >> why an entire class of identifiers has been eliminated, so I propose $ 
> >> instead be reclassified as an `operator-character` so it can be used mixed 
> >> in with other such characters, but prevents the introduction of 
> >> `$Identifier`-style declarations that might conflict with implicit 
> >> parameters.
> >
> > I believe the reason you don't see any other $ variables is that they're 
> > reserved for the debugger and REPL.
> >
> >   brent@Brents-MacBook-Pro ~/D/Code> swift
> >   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
> > clang-700.1.81). Type :help for assistance.
> > 1> "foo"
> >   $R0: String = "foo"
> > 2> print($R0)
> >   foo
> 
> Right.  That said, our current operator space (particularly the unicode 
> segments covered) is not super well considered.  It would be great for 
> someone to take a more systematic pass over them to rationalize things.
> 
> -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] [Proposal]: Free the '$' Symbol!

[Kevin Ballard via swift-evolution]

On Sun, Jan 3, 2016, at 12:55 PM, Michel Fortin via swift-evolution wrote:
> Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution 
>  a écrit :
> > As I recall it, there is no overlap between operator characters and 
> > identifier characters. If it's not in the operator set, it's effectively 
> > reserved for identifiers.
> 
> It's funny that ¢, £, and ¥ are operator characters but not any other 
> currency symbol.

Blame Unicode. $, ¢, £, and ¥ are the only Currency Symbols that have the 
Pattern_Syntax property, and since Swift explicitly reserves $ for identifiers 
that leaves just ¢, £, and ¥ for operators. Although you can in fact use ¤ if 
you want, which is the symbol that denotes an unspecified currency sign.

I suppose Swift could explicitly include the Currency_Symbol general category 
in the list of operators, but it seems odd to say that things like ฿, ₦, or ₭ 
should be operators when they look like letters. It would actually make more 
sense for Swift to explicitly reserve Currency_Symbol for identifiers, which 
would remove ¢, £, and ¥ from the operator list (but that would be a bit odd 
because Pattern_Syntax characters make sense as operators, with $ being the 
single special case that I'm aware of).

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

Re: [swift-evolution] Customized Inline Init Closure

[Adriano Ferreira via swift-evolution]

Hey there!

As a suggestion, check out this simple yet very interesting project called Then 
 by @devxoul.

Best,

— A

> On Jan 3, 2016, at 1:37 AM, Weston Catron via swift-evolution 
>  wrote:
> 
> Ability to write an initializer while initializing an object.
> 
> Example
> 
> let name = “John Apple”;
> let person = Person {
> self.name = nameInput.first() + " " + nameInput.last()
> self.dob = dateInput.datetime()
> If (self.age() > 18) {
> self.taxableStatus = INDEPENDANT
> } else {
> self.taxableStatus = DEPENDANT
> }
> };
> 
> Helpful examples: Objects with many required parameters that are defaulted in 
> the initializers. 
> 
> SKLabelNode
> 
> let label = SKLabelNode(text: "Example") 
> label.position = CGPoint(x: 0, y: 250); 
> label.fontSize = 34; 
> label.fontColor = UIColor.blackColor() 
> self.addChild(label);
> 
> Can become:
> 
> let label = SKLabelNode(text: self.package!.title) {
> self.position = CGPoint(x: 0, y: 250)
> self.fontSize = 34
> self.fontColor = UIColor.blackColor() 
> }
> self.addChild(label)
> 
> Readability Instead of a large amount of code setting up temporary variables 
> to pass into an initializer, all initializing code could be wrapped in a 
> closure.
> 
> Flexibility Instead of exhaustive initializers covering many use cases. 
> Simpler initializers can be extended as needed. This can also encourage 
> required properties over optional ones that are immediately defined. 
> 
> Compiler Warnings Closures react the same as initializers within classes, 
> warning users of incomplete implementation of required properties.
> 
> Possible disadvantages:
> 
> Sloppy Coding Instead of writing complete initializers programmers can just 
> rely on in-line initializers.  
> 
> Tried Before I found this feature is also available in C# 
> (https://msdn.microsoft.com/en-us/library/bb397680.aspx 
> ). Not sure if it was 
> helpful then but many languages since don't appear to use it. 
> 
> -Weston
> 
> ___
> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Kevin Ballard via swift-evolution]

On Sun, Jan 3, 2016, at 03:41 AM, Loïc Lecrenier via swift-evolution wrote:
> Hi Drew,
> 
> Thanks for the review, just a quick remark:
> 
> “Real” type aliases are already forbidden inside protocols, so this proposal 
> wouldn’t change that.
> (According to the grammar, a protocol body can only contain: property, 
> method, initializer, subscript, or associated type member declarations)
> 
> In your example, secondstype and usecstype were associated types with initial 
> values. To convince yourself, try to create this function
> func bar(_: Foo) { }
> and you should see the "can only be used as a generic constraint because it 
> has Self or associated type requirements” error.
> 
> I initially wanted to allow type aliases inside protocols, and I was told 
> type aliases weren’t requirements, so they shouldn’t be defined inside 
> protocols, which makes sense to me.
> 
> We might want to reconsider this, but I think it is outside the scope of this 
> proposal.

I agree that protocols shouldn't have typealiases, but I would be in favor of 
protocol extensions having them:

extension SequenceType {
typealias Element = Generator.Element
}

But it is definitely outside the scope of this proposal.

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Kevin Ballard via swift-evolution]

I'd argue that there's been such a big discussion because it's basically a 
bikeshed. This is an easy topic for everyone to understand so there's low 
barrier to entry, and it basically boils down to "what should we name this 
thing?" which is something everybody can easily form an opinion on. Naming 
bikesheds have produced some of the longest and most hotly-debated discussions 
about programming language design.

-Kevin Ballard

On Sun, Jan 3, 2016, at 04:03 PM, Erica Sadun via swift-evolution wrote:
> Why has there been such a big discussion? I suspect because this is an 
> obvious win. There's less discussion of "should there be this change" and 
> more of "how should this be changed". The relative lightweight nature of the 
> latter inspires lots of input. When a topic gets more technical in nature, 
> those who are heavily invested, with expertise in building compilers and with 
> specialized knowledge of other languages, focus the discussion.
> 
> Turns out in the end that there was an underlying "term of art" (or however 
> that is put) along with the descriptions in the book, so there never was 
> going to probably be anything deeper than "associatedType", "associatedtype" 
> or "associated", in my opinion.
> 
> Why secrecy? There is none. I was asked to run a poll. I ran a poll using the 
> best information I had at the moment. I don't have money to spend on 
> SurveyMonkey so it cut off at 100 replies. You can't see the extra replies. I 
> can't see the extra replies. Even playing field.
> 
> -- Erica, who had no ulterior motives
> 
> 
> > On Jan 3, 2016, at 2:31 PM, Chris Lattner via swift-evolution 
> >  wrote:
> > 
> > 
> >> On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution 
> >>  wrote:
> >> 
> >> I'm not opposing the proposal, but I wonder why there has been such a big 
> >> discussion (and a poll whose results have neither been revealed completely 
> >> nor affected the choice of the keyword)…
> >> 
> >> Swift has proven it can thrive in secrecy, so I don't think the whole open 
> >> community is a necessity — but as it is now, we should hold transparency 
> >> in high esteem and not start faking democracy.
> > 
> > I’m confused, what are you saying?  No decision has been made here, I’m not 
> > aware of any “secrecy” issue.
> > 
> > -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] [Proposal]: Free the '$' Symbol!

[Jacob Bandes-Storch via swift-evolution]

Is it considered infeasible for any characters to be allowed in both
identifiers and operators?

On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> Swift currently does not allow operators to use $ - I assume because
> the grammar reserves it in one place: `implicit-parameter-name`.  I don't
> see why an entire class of identifiers has been eliminated, so I propose $
> instead be reclassified as an `operator-character` so it can be used mixed
> in with other such characters, but prevents the introduction of
> `$Identifier`-style declarations that might conflict with implicit
> parameters.
> >
> > I believe the reason you don't see any other $ variables is that they're
> reserved for the debugger and REPL.
> >
> >   brent@Brents-MacBook-Pro ~/D/Code> swift
> >   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15
> clang-700.1.81). Type :help for assistance.
> > 1> "foo"
> >   $R0: String = "foo"
> > 2> print($R0)
> >   foo
>
> Right.  That said, our current operator space (particularly the unicode
> segments covered) is not super well considered.  It would be great for
> someone to take a more systematic pass over them to rationalize things.
>
> -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] Empower String type with regular expression

[Austin Zheng via swift-evolution]

+1 on first-class regex support/pattern matching on regex patterns.

There was a thread a while ago discussing compile-time code generation, and
if I recall correctly one of the stated use cases was
'compiling'/'building' (don't know the real terminology) regex literals at
compile-time. Is there a bigger overall vision for this sort of feature, or
would it be better to just focus on better regex support?

Best,
Austin

On Sun, Jan 3, 2016 at 1:35 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It is also probably worth burning first-class language support for regexes.  
> This would allow specifying variable captures inline in the pattern, would 
> allow flexible syntax for defining regexes, support powerful extensions to 
> the base regex model (e.g. Perl 6 style), and would provide better 
> compile-time checking and error recovery for mistakes.
>
> -Chris
>
> I know this is an old thread already, but this sure would be one of the
> major breakout pieces of functionality.
> If Swift had native regular expressions, without all the noise you see in
> the Objective-C API that exposes ICU regular expressions, the adoption rate
> would be huge.
> If they were *truly* native, as in somebody sat down and built an NFA (or
> one of the fancier approaches that mixes with DFA) state machine, Swift's
> best-in-class Unicode support would and could result in amazing things.
> It'd boost the scripting use of Swift tremendously and seal the deal as a
> server side language.
>
>
> Totally agreed.  switch on a string with a bunch of regexes being matched
> should turn into a parallel state machine, just like a lexer :-)
>
> -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] [Proposal] Separate protocols and interfaces

[Austin Zheng via swift-evolution]

+1 to "opening" values of existential type, I remember trying (and failing)
to do this when Swift 1 came out. Being able to capture the dynamic type of
an object at runtime and do stuff with it would be incredible.

Austin

On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> This would be wonderful - is it something that could happen in the Swift 3
> timeframe? Is it something that myself or someone else could work on a
> formal proposal for?
>
> -DW
>
> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Introduction of interfaces will clean up the current blend of static and
> dynamic protocols, and solve at least three popular issues.
> Please see:
>
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>
>
> I am *completely* against this proposal.
>
> Fundamentally, you're trying to address the limitation that protocols with
> Self or associated type requirements can't be existential. But it's just a
> limitation that isn't (conceptually) that hard to fix: the primary
> operation you need to work with an existing of such a protocol is to "open"
> a value of existential type, giving a name to the dynamic type it stores.
> Let's invent one:
>
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
>
> Ignore the syntax: semantically, we've gone from a "dynamic" existential
> thing back to something more "static", just by giving a name to the type.
> Swift generics aren't really even static in any sense: what the do is give
> names to the types of values so one can establish relationships among
> different values. "open..as" would do that for existentials.
>
> Note that ether Swift compilers AST and SIL both have "open existential"
> operations that do this internally. They have no spelling in Swift code,
> but they are useful to describe operations on existentials. At present,
> they cannot be formed when the existential involves a protocol with Self or
> associated type requirements, but that's a limitation that isn't hard to
> address.
>
> As for your concerns about knowing when one can dynamically override and
> when one cannot...  There are issues here that need to be addressed. They
> aren't significant enough to warrant such a drastic change, and may not
> even require language changes at all.
>
> - 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] Idea: delegates as protocols and property types with specialised behaviours.

[Alex Popov via swift-evolution]

I don't think this is necessary, but if it does go through, I would prefer the 
`?` be optional, as occasionally I make my delegates `unowned` so that I don't 
have to do a bunch of nil handling/coalescing in the case where the delegate 
strictly owns the other object and both will be deallocated together.The stack 
and multiple declarations are interesting, but if Swift 3 brings us the 
generics we need, those should be possible to implement without adding new 
keywords/complexity to the language.Alex Popov Jr.
Principal iOS developer | Shelfie


_
From: Ross O'Brien via swift-evolution 
Sent: Sunday, January 3, 2016 17:07
Subject: [swift-evolution] Idea: delegates as protocols and property types with 
specialised behaviours.
To: swift-evolution 


   At the moment, the delegate pattern is just one use of protocols. We 
create a protocol with a set of declared functions, implemented either in a 
protocol extension or in the conforming type - the delegate - and another type 
calls functions of its delegate, notifying them when certain events occur.
  
  I'm wondering if uses of the delegate pattern can or should be made 
more explicitly readable. The form I have in mind creates a keyword 'delegate', 
which is used in two contexts; one to replace 'protocol' in the declaration of 
a protocol intended as a delegate, and one to declare a property of the 
delegate type.  
  So, for example:  delegate UITableViewDataSource { }  
  and  class UITableView  {      delegate 
dataSource : UITableViewDataSource      delegate delegate : 
UITableViewDelegate  }  
  (I realise this example uses 'delegate' both as a keyword and a 
property name, and would cause a lot of rewriting for types which generically 
refer to their delegates with the property name 'delegate', so perhaps this 
isn't the best choice of keyword, but bear with me, the idea may still have 
merit.)  
  As a term for declaring a property, 'delegate' could be synonymous 
with 'weak var', and the type would be implicitly a non-force-unwrapped 
optional. I can't presently think of a type in Objective C or Swift which 
requires a strong reference to its delegate. (It might be preferred that the 
"?" remain explicit for readability).  
  Here are two suggestions from where delegates could benefit from 
being distinct types.  
  First: if the delegate pattern is observational (i.e. the type with a 
delegate property calls its delegate's functions as notifications), then there 
can be a need for multiple observers (e.g. multiple services in an app being 
notified that location services have been started).  (I've tried 
implementing something like this; an array of references to observer-type 
delegates at the moment maintains strong references to all delegates, so I've 
created a custom struct with a weak reference to the specific protocol's type 
and called 'forEach' on a sequence of such structs; if the reference is nil, 
the struct can be removed from the sequence. Much as I'd like this struct to be 
generic, I don't think I can create a generic struct with a protocol as the 
associated type.)  This might be declared with a keyword in the same 
way properties are modified with lazy / weak:  multiple delegate : 
CLLocationManagerDelegate?  
  Second: the delegate pattern, if applied to a group of delegates, 
might not be strictly observational, but might also respond in some way - a 
sequence of delegates could be called in turn, with candidates being asked if 
they can respond, returning false if they can't, true if they can.  
  Third: delegates could also form a stack. For example, in an 
NSXMLParser, the parser's delegate can change during parsing, as types handle 
their 'layer' of parsing and then pass control to child or parent 
parser-delegate types. This could be simplified to calling something akin to: 
'parser.delegate.push(childType)' or 'parser.delegate.pop()'  This 
might be declared like this:  stack delegate : NSXMLParserDelegate? 
 
  I may be combining too many ideas into one proposal, or there may be 
more ideas others can add. Is this worthy of discussion?  
  -- Ross O'Brien  


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

[swift-evolution] Idea: delegates as protocols and property types with specialised behaviours.

[Ross O'Brien via swift-evolution]

At the moment, the delegate pattern is just one use of protocols. We create
a protocol with a set of declared functions, implemented either in a
protocol extension or in the conforming type - the delegate - and another
type calls functions of its delegate, notifying them when certain events
occur.

I'm wondering if uses of the delegate pattern can or should be made more
explicitly readable. The form I have in mind creates a keyword 'delegate',
which is used in two contexts; one to replace 'protocol' in the declaration
of a protocol intended as a delegate, and one to declare a property of the
delegate type.

So, for example:
delegate UITableViewDataSource { }

and
class UITableView
{
delegate dataSource : UITableViewDataSource
delegate delegate : UITableViewDelegate
}

(I realise this example uses 'delegate' both as a keyword and a property
name, and would cause a lot of rewriting for types which generically refer
to their delegates with the property name 'delegate', so perhaps this isn't
the best choice of keyword, but bear with me, the idea may still have
merit.)

As a term for declaring a property, 'delegate' could be synonymous with
'weak var', and the type would be implicitly a non-force-unwrapped
optional. I can't presently think of a type in Objective C or Swift which
requires a strong reference to its delegate. (It might be preferred that
the "?" remain explicit for readability).

Here are two suggestions from where delegates could benefit from being
distinct types.

First: if the delegate pattern is observational (i.e. the type with a
delegate property calls its delegate's functions as notifications), then
there can be a need for multiple observers (e.g. multiple services in an
app being notified that location services have been started).
(I've tried implementing something like this; an array of references to
observer-type delegates at the moment maintains strong references to all
delegates, so I've created a custom struct with a weak reference to the
specific protocol's type and called 'forEach' on a sequence of such
structs; if the reference is nil, the struct can be removed from the
sequence. Much as I'd like this struct to be generic, I don't think I can
create a generic struct with a protocol as the associated type.)
This might be declared with a keyword in the same way properties are
modified with lazy / weak:
multiple delegate : CLLocationManagerDelegate?

Second: the delegate pattern, if applied to a group of delegates, might not
be strictly observational, but might also respond in some way - a sequence
of delegates could be called in turn, with candidates being asked if they
can respond, returning false if they can't, true if they can.

Third: delegates could also form a stack. For example, in an NSXMLParser,
the parser's delegate can change during parsing, as types handle their
'layer' of parsing and then pass control to child or parent parser-delegate
types. This could be simplified to calling something akin to:
'parser.delegate.push(childType)' or 'parser.delegate.pop()'
This might be declared like this:
stack delegate : NSXMLParserDelegate?

I may be combining too many ideas into one proposal, or there may be more
ideas others can add. Is this worthy of discussion?

-- Ross O'Brien
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[David Waite via swift-evolution]

This would be wonderful - is it something that could happen in the Swift 3 
timeframe? Is it something that myself or someone else could work on a formal 
proposal for?

-DW

> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Introduction of interfaces will clean up the current blend of static and 
>> dynamic protocols, and solve at least three popular issues.
>> Please see:
>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>  
>> 
> I am *completely* against this proposal.
> 
> Fundamentally, you're trying to address the limitation that protocols with 
> Self or associated type requirements can't be existential. But it's just a 
> limitation that isn't (conceptually) that hard to fix: the primary operation 
> you need to work with an existing of such a protocol is to "open" a value of 
> existential type, giving a name to the dynamic type it stores. Let's invent 
> one:
> 
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
> 
> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
> thing back to something more "static", just by giving a name to the type. 
> Swift generics aren't really even static in any sense: what the do is give 
> names to the types of values so one can establish relationships among 
> different values. "open..as" would do that for existentials. 
> 
> Note that ether Swift compilers AST and SIL both have "open existential" 
> operations that do this internally. They have no spelling in Swift code, but 
> they are useful to describe operations on existentials. At present, they 
> cannot be formed when the existential involves a protocol with Self or 
> associated type requirements, but that's a limitation that isn't hard to 
> address. 
> 
> As for your concerns about knowing when one can dynamically override and when 
> one cannot...  There are issues here that need to be addressed. They aren't 
> significant enough to warrant such a drastic change, and may not even require 
> language changes at all. 
> 
>   - 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] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Erica Sadun via swift-evolution]

Why has there been such a big discussion? I suspect because this is an obvious 
win. There's less discussion of "should there be this change" and more of "how 
should this be changed". The relative lightweight nature of the latter inspires 
lots of input. When a topic gets more technical in nature, those who are 
heavily invested, with expertise in building compilers and with specialized 
knowledge of other languages, focus the discussion.

Turns out in the end that there was an underlying "term of art" (or however 
that is put) along with the descriptions in the book, so there never was going 
to probably be anything deeper than "associatedType", "associatedtype" or 
"associated", in my opinion.

Why secrecy? There is none. I was asked to run a poll. I ran a poll using the 
best information I had at the moment. I don't have money to spend on 
SurveyMonkey so it cut off at 100 replies. You can't see the extra replies. I 
can't see the extra replies. Even playing field.

-- Erica, who had no ulterior motives


> On Jan 3, 2016, at 2:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution 
>>  wrote:
>> 
>> I'm not opposing the proposal, but I wonder why there has been such a big 
>> discussion (and a poll whose results have neither been revealed completely 
>> nor affected the choice of the keyword)…
>> 
>> Swift has proven it can thrive in secrecy, so I don't think the whole open 
>> community is a necessity — but as it is now, we should hold transparency in 
>> high esteem and not start faking democracy.
> 
> I’m confused, what are you saying?  No decision has been made here, I’m not 
> aware of any “secrecy” issue.
> 
> -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] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Erica Sadun via swift-evolution]

+1 from me too.

(My vote takes into account the various alternatives were put on the table and 
weeded down thoughtfully to the one we're voting on.)

-- E


> On Jan 3, 2016, at 5:57 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> +1 from me. It is a solid change that addresses an oddity in the language.
> 
> On Sun, Jan 3, 2016 at 7:27 AM, plx via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I like this.
> 
>> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "Replace `typealias` keyword with `associatedtype` for 
>> associated type declarations” begins now and runs through Wednesday, January 
>> 6th. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.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?
> 
> It’s a good idea and improves the language.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, the existing situation is comprehensible (if you think like a 
> language-implementer) but highly non-intuitive and generally sub-optimal for 
> language users.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes; conservation-of-reserved-terms is valuable, but giving different things 
> different names fits the feel much better here.
> 
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
> 
> To the extent I’m aware of analogous situations in other languages, none of 
> them actually seem to use distinct keywords, but they also don’t have the 
> confusing situation Swift has vis-a-vis typealiases with concrete definitions 
> (in protocols).
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Quick read, plus having been bit by issues the proposal addresses numerous 
> times.
> 
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>>  Cheers,
>>  Doug Gregor
>>  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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Tino Heth via swift-evolution]

>> Swift has proven it can thrive in secrecy, so I don't think the whole open 
>> community is a necessity — but as it is now, we should hold transparency in 
>> high esteem and not start faking democracy.
> 
> I’m confused, what are you saying?  No decision has been made here, I’m not 
> aware of any “secrecy” issue.
Sorry, it could be that my words don't express exactly what I wanted to say.
The first part is just about the closed-source past, which brought us Swift as 
we know it now (a big thank you for that; I'm really very happy about it).

For me (I guess for others as well :) the decision process is a black box, but 
I expect the proposals have impact on it — so proposers have some 
responsibility.
Loïc and I already had a short conversation, and I have no accusations against 
him, but rather wanted to criticize a tool that can be instrumentalized easily:
There has been a poll about which keyword to choose as replacement, and that 
made his proposal the target for my word of warning…

I guess most of us agree that surveys have to be taken with a grain of salt, 
and I think their use should be discouraged for most situations.
Polls itself can be manipulated in many ways (bias of the author, fake votes…), 
and there are no rules how to handle the result (an author could cite a survey 
that supports his standpoint, but he might as well ignore a result he doesn't 
like).

Of course, the core team is not bound to the result of any vote, but bad 
decisions aren't my main concern:
I don't know how this community will evolve, but I guess there will be natural 
controversy in the future, there will be temptation to support opinions with 
unfair methods — and there will be people suspecting or accusing others of 
using such methods…

All those bad things are most likely unavoidable, but clear rules could help 
keeping them at bay.

So, I hope my language has been better this time, and that Swift grows up to be 
a healthy open source project with a great community! (and to make sure I don't 
get things wrong again: It is already quite healthy and great ;-) 

Best regards,
Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

[Andrew Bennett via swift-evolution]

As an alternative to minElement and maxElement, this could reduce the
number of overloads and provide autocomplete:

extension SequenceType {

@warn_unused_result

func reduce(

@noescape combine: (C, C) throws -> Bool,

@noescape by key: Generator.Element -> C

) rethrows -> Generator.Element?

{

var generator = self.generate()

guard let first = generator.next() else {

return nil

}

var best = first, bestKey = key(first)

while let element = generator.next() {

let elementKey = key(element)

if try !combine(bestKey, elementKey) {

bestKey = elementKey

best = element

}

}

return best

}

}


print(["a","ab","abc"].reduce(<, by: { $0.characters.count })) //
Optional("a")

print(["a","ab","abc"].reduce(>, by: { $0.characters.count })) //
Optional("abc")


The regular minElement, maxElement methods could have this alternative when
you don't want "by":

extension SequenceType {

@warn_unused_result

func reduce(

@noescape combine: (Generator.Element, Generator.Element) throws ->
Bool

) rethrows -> Generator.Element?

{

var generator = self.generate()

guard let first = generator.next() else {

return nil

}

var best = first

while let element = generator.next() {

best = try combine(best, element) ? best : element

}

return best

}

}


print([0,1,2,3].reduce(<)) // Optional(0)

print([0,1,2,3].reduce(>)) // Optional(3)


It may be more efficient to define this on CollectionType where
SubSequence.Generator.Element == Generator.Element, using .first and .
dropFirst() rather than .generate(), but it's less flexible and this was
enough to illustrate the alternative.


On Fri, Jan 1, 2016 at 7:20 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > I don’t get the resistance to Dave’s solution? I think it works well and
> much more applicable.
>
> I have two issues:
>
> 1. It's less discoverable. Someone merely *typing* `sort` into their
> editor will see `sortBy` right below it in their autocompletion list, and
> might discover it that way.
>
> 2. It forces a naïve implementation, which may not be the best idea. In
> the Perl world, for instance, we would usually use a Schwartzian transform
> to implement this, particularly if the key might be expensive to compute:
>
> array.map { ($0, sortKey($0)) }.sort { $0.1 < $1.1 }.map { $0.0 }
>
> Having said that, I think both of these concerns are relatively  minor.
>
> --
> 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] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Introduction of interfaces will clean up the current blend of static and 
> dynamic protocols, and solve at least three popular issues.
> Please see:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md

I am *completely* against this proposal.

Fundamentally, you're trying to address the limitation that protocols with Self 
or associated type requirements can't be existential. But it's just a 
limitation that isn't (conceptually) that hard to fix: the primary operation 
you need to work with an existing of such a protocol is to "open" a value of 
existential type, giving a name to the dynamic type it stores. Let's invent one:

  func eq(x: Equatable, y: Equatable) -> Bool {
// give the name T to the dynamic type stored in xT
let xT = open x as T
// is y also storing a T?
guard let yT = y as? T else { return false }
// check whether the Ts are equal
return xT == yT
  }

Ignore the syntax: semantically, we've gone from a "dynamic" existential thing 
back to something more "static", just by giving a name to the type. Swift 
generics aren't really even static in any sense: what the do is give names to 
the types of values so one can establish relationships among different values. 
"open..as" would do that for existentials. 

Note that ether Swift compilers AST and SIL both have "open existential" 
operations that do this internally. They have no spelling in Swift code, but 
they are useful to describe operations on existentials. At present, they cannot 
be formed when the existential involves a protocol with Self or associated type 
requirements, but that's a limitation that isn't hard to address. 

As for your concerns about knowing when one can dynamically override and when 
one cannot...  There are issues here that need to be addressed. They aren't 
significant enough to warrant such a drastic change, and may not even require 
language changes at all. 

- Doug


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

Re: [swift-evolution] Empower String type with regular expression

[Chris Lattner via swift-evolution]

> On Jan 1, 2016, at 4:44 PM, John Joyce via swift-evolution 
>  wrote:
>> It is also probably worth burning first-class language support for regexes.  
>> This would allow specifying variable captures inline in the pattern, would 
>> allow flexible syntax for defining regexes, support powerful extensions to 
>> the base regex model (e.g. Perl 6 style), and would provide better 
>> compile-time checking and error recovery for mistakes.
>> 
>> -Chris
> I know this is an old thread already, but this sure would be one of the major 
> breakout pieces of functionality.
> If Swift had native regular expressions, without all the noise you see in the 
> Objective-C API that exposes ICU regular expressions, the adoption rate would 
> be huge.
> If they were *truly* native, as in somebody sat down and built an NFA (or one 
> of the fancier approaches that mixes with DFA) state machine, Swift's 
> best-in-class Unicode support would and could result in amazing things.
> It'd boost the scripting use of Swift tremendously and seal the deal as a 
> server side language.

Totally agreed.  switch on a string with a bunch of regexes being matched 
should turn into a parallel state machine, just like a lexer :-)

-Chris

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Chris Lattner via swift-evolution]

> On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> I'm not opposing the proposal, but I wonder why there has been such a big 
> discussion (and a poll whose results have neither been revealed completely 
> nor affected the choice of the keyword)…
> 
> Swift has proven it can thrive in secrecy, so I don't think the whole open 
> community is a necessity — but as it is now, we should hold transparency in 
> high esteem and not start faking democracy.

I’m confused, what are you saying?  No decision has been made here, I’m not 
aware of any “secrecy” issue.

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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Chris Lattner via swift-evolution]

> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Swift currently does not allow operators to use $ - I assume because the 
>> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
>> why an entire class of identifiers has been eliminated, so I propose $ 
>> instead be reclassified as an `operator-character` so it can be used mixed 
>> in with other such characters, but prevents the introduction of 
>> `$Identifier`-style declarations that might conflict with implicit 
>> parameters.
> 
> I believe the reason you don't see any other $ variables is that they're 
> reserved for the debugger and REPL.
> 
>   brent@Brents-MacBook-Pro ~/D/Code> swift
>   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
> clang-700.1.81). Type :help for assistance.
> 1> "foo"
>   $R0: String = "foo"
> 2> print($R0)
>   foo

Right.  That said, our current operator space (particularly the unicode 
segments covered) is not super well considered.  It would be great for someone 
to take a more systematic pass over them to rationalize things.

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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Michel Fortin via swift-evolution]

Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution 
 a écrit :
> As I recall it, there is no overlap between operator characters and 
> identifier characters. If it's not in the operator set, it's effectively 
> reserved for identifiers.

It's funny that ¢, £, and ¥ are operator characters but not any other currency 
symbol.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Dave Abrahams via swift-evolution]

> On Jan 3, 2016, at 10:25 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> The problem with syntax of "existential protocol" and "protocol" is that the 
> first should actually be default, and easier to write.
> 
> We should prefer static to dynamic.

These two statements seem to be in conflict: existentials create dynamic 
polymorphism, while generics create static polymorphism.

> It is as if "structs" had to be declared as "static class", or "let" 
> variables as "const var". Shorter keywords should be used for enforcing good 
> practices.
> Additionally, 95% of standard library protocols are actually "existential 
> protocols", or "protocols" in my notation.
> 
> Next, I don't know any language which has "existential" keyword. Moreover, 
> "existential types" in Haskell mean means (roughly) "type that can hold value 
> of any instance of class with type erasure", and that is exactly what an 
> interface is in Swift. So, I think that if we will add "existential" keyword, 
> we would add it the other way: for dynamically dispatched types.
> 
> Some other suggestions (imagine a table):
> 
> statically dispatched - dynamically dispatched
> protocol - interface
> protocol - dynamic protocol
> protocol - existential protocol
> static protocol - dynamic protocol
> trait - protocol
> trait - interface
> 
> I also personally like the "trait - protocol" naming. Traits are used to be 
> statically dispatched things in other languages, and protocols are 
> dynamically dispatched things from Objective-C. Actually, I'm satisfied with 
> any pair unless dynamic protocols get shorter names.
> 
> P.S. I'll correct that Self issue, thanks!
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Dave Abrahams via swift-evolution]

> On Jan 3, 2016, at 10:51 AM, David Waite  wrote:
> 
> In a block of code where errors are only thrown in some places, do+try is 
> illustrative because it allows you to know which functions are possible 
> failure points.
> 
> However, in a block of code where errors are thrown in most places, a try 
> block would be useful because individual try statements become noise.

Whether the individal failure points are important to notice is not related to 
how many of them there are; it’s a function of what your code is doing in 
between and around them. 

> 
> Comments:
> 1. I was under the impression that the second case was not expected to be the 
> norm in swift code when the error functionality was added.

That seems unlikely there is a large class of common applications that fall 
into that bucket.  In particular, anything likely to be coupled to I/O tends to 
be like that.

> 2. It seems like in either case, a try block would be less typing than a 
> do+try block. I don’t know if this would lead to do blocks not being used in 
> cases where doing so would improve code comprehension.
> 
> 3. Using try in this manner also has the potential (positive and negative) of 
> having c++ style try/catch, but with different mechanics (as we are dealing 
> with errors and not exceptions).
> 
> One possible approach if it was desirable to not have this used arbitrarily 
> in place of do+try, and to avoid looking too much like exception syntax: 
> instead define rethrows blocks:
> 
>   func recognizeHandler() throws {
>   rethrows {
>accept(.on)// .on is an enum tag for the token for the 
> ‘on’ keyword.
>recognizeName()
>recognizeFormalParamSeq()
>accept(.newline)
>recognizeCommandSeq()
>accept(.end)
>recognizeName()// Later Visitor pass checks that names match. 
>accept(.newline)
>   }
>   }
> 
> A rethrows block does not allow catch blocks to be attached.

Sure; I wanted that to be the meaning of the “rethrows” keyword that adorns a 
func decl, so it didn’t cause an extra level of indentation.  A very common 
case is, “I am not directly throwing any errors of my own; I promise to only 
propagate errors thrown by my parameters (including generic parameters), and it 
doesn’t matter which of them throws.” 

> To catch any of the errors, you would still need to use do+try, which means 
> do+try would still be used in cases where it was illustrative. There is an 
> extra level of indentation, but at four character indentation this would not 
> make the lines of code any longer (since you eliminated “try “). There is no 
> syntax mismatch with existing languages with exception semantics to cause 
> confusion.
> 
> Comments?
> 
> -DW
> 
>> On Jan 3, 2016, at 10:58 AM, Dave Abrahams via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 
> There are large classes of programs where you can know you don’t care 
> exactly where a failure happens, e.g. (most init functions, all pure 
> functions, any function that doesn’t break invariants).  In these cases 
> marking every statement or expression that can throw is just noise.  Try 
> writing some serialization/deserialization code where the underlying 
> stream can fail to see what I mean; you’ll have “try” everwhere, and it 
> adds nothing to comprehensibility or maintainability.  Personally I would 
> like to be able to label the function itself and not have to introuce a 
> scope, but IMO being able to create “try blocks” would be a welcome 
> addition and would even match the common case in blocks with catch 
> clauses, where being aware of the exact line where the error was 
> generated is typically not useful.
 
 That's a really interesting idea, but I don't think it's what the poster 
 was suggesting. It sounded to me like he was merely saying “let's make the 
 Swift error system look like my favorite language's exception system".
>>> 
>>> I agree with Brent’s assessment of the OP. However that doesn’t mean that 
>>> Dave does not have a good point. Here is some code from a recursive descent 
>>> parser. (More correctly: the recognizer. Omitting the AST-building stuff.)
>>> 
>>>   func recognizeHandler() throws {
>>>   try accept(.on)// .on is an enum tag for the token for the 
>>> ‘on’ keyword.
>>>   try recognizeName()
>>>   try recognizeFormalParamSeq()
>>>   try accept(.newline)
>>>   try recognizeCommandSeq()
>>>   try accept(.end)
>>>   try recognizeName()// Later Visitor pass checks that names match. 
>>>   try accept(.newline)
>>>   }
>>> 
>>> There is a lot more where that came from.
>> 
>> Exactly.  The natural response from framework designers is to find more ways 
>> to support writing entir

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Dave Abrahams via swift-evolution]

> On Jan 3, 2016, at 10:21 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
>>> 
>>> Please see comments inline.
>>> 
 On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
  wrote:
 
 
>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> So “try” instead of “do”. If there is no catch, then just use braces 
>> without a keyword for a block. 
>> 
>> And use do-while instead of repeat-while.
 
 +1
 
> 
> Do you also propose no longer marking calls to throwing functions with 
> `try`?
 
 If try had both a single-statement/expression form as it does today, and a 
 block form that makes it unnecessary to mark all the individual statements 
 in the block, that would be an improvement.
 
> Have you read the "Error-Handling Rationale" document in the Swift 
> repository? If not, please do: 
> 
>  If so, please explain why you disagree with it.
 
 There are large classes of programs where you can know you don’t care 
 exactly where a failure happens, e.g. (most init functions, all pure 
 functions, any function that doesn’t break invariants).  In these cases 
 marking every statement or expression that can throw is just noise.  Try 
 writing some serialization/deserialization code where the underlying 
 stream can fail to see what I mean; you’ll have “try” everwhere, and it 
 adds nothing to comprehensibility or maintainability.  Personally I would 
 like to be able to label the function itself and not have to introuce a 
 scope, but IMO being able to create “try blocks” would be a welcome 
 addition and would even match the common case in blocks with catch 
 clauses, where being aware of the exact line where the error was generated 
 is typically not useful.
>>> 
>>> I had proposed something very similar to this around six months ago on the 
>>> swift-users list, but I think John McCall, had some (quite valid) concerns 
>>> with this.
>>> 
>>> Unfortunately I can't access those emails, but I think his concern was that 
>>> the purpose of try was to mark explicitly which statements throw and this 
>>> would defeat the purpose of that. People might just wrap large blocks in 
>>> try.
>> 
>> As much as I am loath to disagree with John on this, there’s an incorrect 
>> implicit assumption in that rationale, that forcing people to mark all throw 
>> points trains them to get error-handling correct.  What it does instead is 
>> to train them to think of all code uniformly instead of recognizing the 
>> places where a throw needs special attention (places where there are broken 
>> invariants). Eventually, as with warnings that have a high false-positive 
>> rate, when you see “try” in many places where it doesn’t help, you learn to 
>> ignore it altogether.
> 
> I agree that requiring this is not likely to result in improved error 
> handling and thus is not a strong argument in favor of it.
> 
> IMO the purpose of requiring “try” to be stated explicitly is that it 
> arguably makes code more readable.  It is immediately clear which functions 
> can throw and which cannot.  You don’t need to look up the signature of every 
> function called to determine this. My experience thus far has been that I 
> have really appreciated the requirement that throwing expressions be 
> explicitly marked. 

As a default it’s great.  Not having a way to opt out of individual marking for 
a whole block or function—because you know you’re not breaking any invariants, 
so which functions can throw is irrelevant, and not having a way for the 
compiler deduce these regions (e.g. known pure functions)—is the problem.  The 
recognizer code posted in an earlier message is a perfect example.  If there 
*was* some code where it was really important to notice failure points, you’d 
miss it. 

The key to getting error handling right is not being able to trace every 
possible control path—which is effectively impossible anyway— it’s 
understanding the relationship between scopes in your code and your program’s 
invariants.  

> I think positions on both sides of this are reasonable.

Absolutely.  Even reasonable positions can be sub-optimal though :-)

>> 
>>> 
>>> Another idea is to treat the block as an unnamed, no argument, no return 
>>> value, function that could throw. This solves the problem in a very general 
>>> way, and would retain the marking of all throwing functions with try,
>> 
>> That marking, in itself, is the root problem.  Our syntax is the way it is 
>> primarily because "marking everywhere" was adopted as an explicit goal.
>> 
>>> but has the perhaps unfortunate syntax of allowing things like:
>>> 
>>> try {
>>>  try myFunctio

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Matt Whiteside via swift-evolution]

I have one concern with `associated` vs `associatedtype`, which is that it 
people might, in the interest of clarity, start naming things using a 
conventions like

`associated PayloadType`, 

when I think it would be better to have  

`associatedtype Payload`

because it leaves less room for interpretation about how to name things 
idiomatically.

But I still haven’t completely decided between `type` and `associatedtype`, and 
I plan to respond to this thread separately with my thoughts on that.

Matt


> On Jan 3, 2016, at 10:10, Alex Migicovsky via swift-evolution 
>  wrote:
> 
>> * What is your evaluation of the proposal?
> 
> I think the proposal is great. The only thing I’d prefer is to use 
> `associated` over `associatedtype`.
> 
> `associated` has always felt better to me over `associatedtype`. It was 
> mentioned in one of the original proposals as the keyword that was initially 
> most well received as well—I think this is because it just feels right, which 
> is a good indicator even though it doesn’t seem scientific :-)
> 
> One downside mentioned is that `associated` is more vague than 
> `associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
> `classtype`, etc as keywords over `protocol` and `class`. I think the 
> convention of having associated type names start with an uppercase letter 
> makes it clear that what follows `associated` is a type (or will be a 
> concrete type).
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> Yes, I’ve seen many developers be confused by the difference between defining 
> a typealias inside a protocol declaration vs outside.
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> I’ve been paying attention to the thread and have thought about why I like 
> `associated` over `associatedtype` since the start of the thread.
> 
> - Alex
> ___
> 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] use standard syntax instead of "do" and "repeat"

[Goffredo Marocchi via swift-evolution]

> On 3 Jan 2016, at 18:21, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
>>> 
>>> Please see comments inline.
>>> 
 On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
  wrote:
 
 
>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> So “try” instead of “do”. If there is no catch, then just use braces 
>> without a keyword for a block. 
>> 
>> And use do-while instead of repeat-while.
 
 +1
 
> 
> Do you also propose no longer marking calls to throwing functions with 
> `try`?
 
 If try had both a single-statement/expression form as it does today, and a 
 block form that makes it unnecessary to mark all the individual statements 
 in the block, that would be an improvement.
 
> Have you read the "Error-Handling Rationale" document in the Swift 
> repository? If not, please do: 
> 
>  If so, please explain why you disagree with it.
 
 There are large classes of programs where you can know you don’t care 
 exactly where a failure happens, e.g. (most init functions, all pure 
 functions, any function that doesn’t break invariants).  In these cases 
 marking every statement or expression that can throw is just noise.  Try 
 writing some serialization/deserialization code where the underlying 
 stream can fail to see what I mean; you’ll have “try” everwhere, and it 
 adds nothing to comprehensibility or maintainability.  Personally I would 
 like to be able to label the function itself and not have to introuce a 
 scope, but IMO being able to create “try blocks” would be a welcome 
 addition and would even match the common case in blocks with catch 
 clauses, where being aware of the exact line where the error was generated 
 is typically not useful.
>>> 
>>> I had proposed something very similar to this around six months ago on the 
>>> swift-users list, but I think John McCall, had some (quite valid) concerns 
>>> with this.
>>> 
>>> Unfortunately I can't access those emails, but I think his concern was that 
>>> the purpose of try was to mark explicitly which statements throw and this 
>>> would defeat the purpose of that. People might just wrap large blocks in 
>>> try.
>> 
>> As much as I am loath to disagree with John on this, there’s an incorrect 
>> implicit assumption in that rationale, that forcing people to mark all throw 
>> points trains them to get error-handling correct.  What it does instead is 
>> to train them to think of all code uniformly instead of recognizing the 
>> places where a throw needs special attention (places where there are broken 
>> invariants).  Eventually, as with warnings that have a high false-positive 
>> rate, when you see “try” in many places where it doesn’t help, you learn to 
>> ignore it altogether.
> 
> I agree that requiring this is not likely to result in improved error 
> handling and thus is not a strong argument in favor of it.
> 
> IMO the purpose of requiring “try” to be stated explicitly is that it 
> arguably makes code more readable.  It is immediately clear which functions 
> can throw and which cannot.  You don’t need to look up the signature of every 
> function called to determine this.  My experience thus far has been that I 
> have really appreciated the requirement that throwing expressions be 
> explicitly marked. 
> 

In a way the current 'do' (which I would rename to attempt ;)... regardless of 
requiring try for every throwing statement is used or not I am not a fan of 
taking a commonly used keyword and changing its meaning unless there is a clear 
strong benefit to it) already identifies blocks of throwing code and having try 
marking each expression does not do much about trying to catch errors thrown by 
too many statements together. My litmus test for this is that we could remove 
the try keyword from those error handling blocks and it would not by itself 
worsen our code much, but I may very well be utterly wrong here.



> I think positions on both sides of this are reasonable.
> 
>> 
>>> 
>>> Another idea is to treat the block as an unnamed, no argument, no return 
>>> value, function that could throw. This solves the problem in a very general 
>>> way, and would retain the marking of all throwing functions with try,
>> 
>> That marking, in itself, is the root problem.  Our syntax is the way it is 
>> primarily because "marking everywhere" was adopted as an explicit goal.
>> 
>>> but has the perhaps unfortunate syntax of allowing things like:
>>> 
>>> try {
>>>  try myFunction()
>>> } catch {
>>> 
>>> }
>>> 
>>> Something like this could be shortened to a consistent theoretical inline 
>>> try catch syntax like:

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Tino Heth via swift-evolution]

I'm not opposing the proposal, but I wonder why there has been such a big 
discussion (and a poll whose results have neither been revealed completely nor 
affected the choice of the keyword)…

Swift has proven it can thrive in secrecy, so I don't think the whole open 
community is a necessity — but as it is now, we should hold transparency in 
high esteem and not start faking democracy.

Just my 2c
Tino

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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[David Waite via swift-evolution]

In a block of code where errors are only thrown in some places, do+try is 
illustrative because it allows you to know which functions are possible failure 
points.

However, in a block of code where errors are thrown in most places, a try block 
would be useful because individual try statements become noise.

Comments:
1. I was under the impression that the second case was not expected to be the 
norm in swift code when the error functionality was added.

2. It seems like in either case, a try block would be less typing than a do+try 
block. I don’t know if this would lead to do blocks not being used in cases 
where doing so would improve code comprehension.

3. Using try in this manner also has the potential (positive and negative) of 
having c++ style try/catch, but with different mechanics (as we are dealing 
with errors and not exceptions).

One possible approach if it was desirable to not have this used arbitrarily in 
place of do+try, and to avoid looking too much like exception syntax: instead 
define rethrows blocks:

  func recognizeHandler() throws {
  rethrows {
   accept(.on)// .on is an enum tag for the token for the ‘on’ 
keyword.
   recognizeName()
   recognizeFormalParamSeq()
   accept(.newline)
   recognizeCommandSeq()
   accept(.end)
   recognizeName()// Later Visitor pass checks that names match. 
   accept(.newline)
  }
  }

A rethrows block does not allow catch blocks to be attached. To catch any of 
the errors, you would still need to use do+try, which means do+try would still 
be used in cases where it was illustrative. There is an extra level of 
indentation, but at four character indentation this would not make the lines of 
code any longer (since you eliminated “try “). There is no syntax mismatch with 
existing languages with exception semantics to cause confusion.

Comments?

-DW

> On Jan 3, 2016, at 10:58 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution 
>>  wrote:
>> 
>> 
>>> 
 There are large classes of programs where you can know you don’t care 
 exactly where a failure happens, e.g. (most init functions, all pure 
 functions, any function that doesn’t break invariants).  In these cases 
 marking every statement or expression that can throw is just noise.  Try 
 writing some serialization/deserialization code where the underlying 
 stream can fail to see what I mean; you’ll have “try” everwhere, and it 
 adds nothing to comprehensibility or maintainability.  Personally I would 
 like to be able to label the function itself and not have to introuce a 
 scope, but IMO being able to create “try blocks” would be a welcome 
 addition and would even match the common case in blocks with catch 
 clauses, where being aware of the exact line where the error was generated 
 is typically not useful.
>>> 
>>> That's a really interesting idea, but I don't think it's what the poster 
>>> was suggesting. It sounded to me like he was merely saying “let's make the 
>>> Swift error system look like my favorite language's exception system".
>> 
>> I agree with Brent’s assessment of the OP. However that doesn’t mean that 
>> Dave does not have a good point. Here is some code from a recursive descent 
>> parser. (More correctly: the recognizer. Omitting the AST-building stuff.)
>> 
>>   func recognizeHandler() throws {
>>   try accept(.on)// .on is an enum tag for the token for the 
>> ‘on’ keyword.
>>   try recognizeName()
>>   try recognizeFormalParamSeq()
>>   try accept(.newline)
>>   try recognizeCommandSeq()
>>   try accept(.end)
>>   try recognizeName()// Later Visitor pass checks that names match. 
>>   try accept(.newline)
>>   }
>> 
>> There is a lot more where that came from.
> 
> Exactly.  The natural response from framework designers is to find more ways 
> to support writing entire functions as a single expression.  At the limit, 
> you end up with 
> http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html
>  
> .
> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> -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-evolu

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Félix Cloutier via swift-evolution]

As I recall it, there is no overlap between operator characters and identifier 
characters. If it's not in the operator set, it's effectively reserved for 
identifiers.

I also remember someone from Apple confirming what Brent said but I can't find 
it at the moment.

Félix

> Le 3 janv. 2016 à 03:47:39, Developer via swift-evolution 
>  a écrit :
> 
> Well, that's just it.  $ is a perfectly valid character in identifiers 
> everywhere but in the grammar for operators for some reason.  It isn't 
> reserved, it just isn't there.
> 
> ~Robert Widmann
> 
> 2016/01/03 0:53、Brent Royal-Gordon  のメッセージ:
> 
>>> Swift currently does not allow operators to use $ - I assume because the 
>>> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
>>> why an entire class of identifiers has been eliminated, so I propose $ 
>>> instead be reclassified as an `operator-character` so it can be used mixed 
>>> in with other such characters, but prevents the introduction of 
>>> `$Identifier`-style declarations that might conflict with implicit 
>>> parameters.
>> 
>> I believe the reason you don't see any other $ variables is that they're 
>> reserved for the debugger and REPL.
>> 
>>   brent@Brents-MacBook-Pro ~/D/Code> swift
>>   Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
>> clang-700.1.81). Type :help for assistance.
>> 1> "foo"
>>   $R0: String = "foo"
>> 2> print($R0)
>>   foo
>> 
>> -- 
>> 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] [Proposal] Separate protocols and interfaces

[Антон Жилин via swift-evolution]

The problem with syntax of "existential protocol" and "protocol" is that
the first should actually be default, and easier to write.

We should prefer static to dynamic. It is as if "structs" had to be
declared as "static class", or "let" variables as "const var". Shorter
keywords should be used for enforcing good practices.
Additionally, 95% of standard library protocols are actually "existential
protocols", or "protocols" in my notation.

Next, I don't know any language which has "existential" keyword. Moreover,
"existential types" in Haskell mean means (roughly) "type that can hold
value of any instance of class with type erasure", and that is exactly what
an interface is in Swift. So, I think that if we will add "existential"
keyword, we would add it the other way: for dynamically dispatched types.

Some other suggestions (imagine a table):

statically dispatched - dynamically dispatched
protocol - interface
protocol - dynamic protocol
protocol - existential protocol
static protocol - dynamic protocol
trait - protocol
trait - interface

I also personally like the "trait - protocol" naming. Traits are used to be
statically dispatched things in other languages, and protocols are
dynamically dispatched things from Objective-C. Actually, I'm satisfied
with any pair unless dynamic protocols get shorter names.

P.S. I'll correct that Self issue, thanks!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Matthew Johnson via swift-evolution]

> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
>> 
>> Please see comments inline.
>> 
>>> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> So “try” instead of “do”. If there is no catch, then just use braces 
> without a keyword for a block. 
> 
> And use do-while instead of repeat-while.
>>> 
>>> +1
>>> 
 
 Do you also propose no longer marking calls to throwing functions with 
 `try`?
>>> 
>>> If try had both a single-statement/expression form as it does today, and a 
>>> block form that makes it unnecessary to mark all the individual statements 
>>> in the block, that would be an improvement.
>>> 
 Have you read the "Error-Handling Rationale" document in the Swift 
 repository? If not, please do: 
 
  If so, please explain why you disagree with it.
>>> 
>>> There are large classes of programs where you can know you don’t care 
>>> exactly where a failure happens, e.g. (most init functions, all pure 
>>> functions, any function that doesn’t break invariants).  In these cases 
>>> marking every statement or expression that can throw is just noise.  Try 
>>> writing some serialization/deserialization code where the underlying stream 
>>> can fail to see what I mean; you’ll have “try” everwhere, and it adds 
>>> nothing to comprehensibility or maintainability.  Personally I would like 
>>> to be able to label the function itself and not have to introuce a scope, 
>>> but IMO being able to create “try blocks” would be a welcome addition and 
>>> would even match the common case in blocks with catch clauses, where being 
>>> aware of the exact line where the error was generated is typically not 
>>> useful.
>> 
>> I had proposed something very similar to this around six months ago on the 
>> swift-users list, but I think John McCall, had some (quite valid) concerns 
>> with this.
>> 
>> Unfortunately I can't access those emails, but I think his concern was that 
>> the purpose of try was to mark explicitly which statements throw and this 
>> would defeat the purpose of that. People might just wrap large blocks in try.
> 
> As much as I am loath to disagree with John on this, there’s an incorrect 
> implicit assumption in that rationale, that forcing people to mark all throw 
> points trains them to get error-handling correct.  What it does instead is to 
> train them to think of all code uniformly instead of recognizing the places 
> where a throw needs special attention (places where there are broken 
> invariants).  Eventually, as with warnings that have a high false-positive 
> rate, when you see “try” in many places where it doesn’t help, you learn to 
> ignore it altogether.

I agree that requiring this is not likely to result in improved error handling 
and thus is not a strong argument in favor of it.

IMO the purpose of requiring “try” to be stated explicitly is that it arguably 
makes code more readable.  It is immediately clear which functions can throw 
and which cannot.  You don’t need to look up the signature of every function 
called to determine this.  My experience thus far has been that I have really 
appreciated the requirement that throwing expressions be explicitly marked. 

I think positions on both sides of this are reasonable.

> 
>> 
>> Another idea is to treat the block as an unnamed, no argument, no return 
>> value, function that could throw. This solves the problem in a very general 
>> way, and would retain the marking of all throwing functions with try,
> 
> That marking, in itself, is the root problem.  Our syntax is the way it is 
> primarily because "marking everywhere" was adopted as an explicit goal.
> 
>> but has the perhaps unfortunate syntax of allowing things like:
>> 
>> try {
>>   try myFunction()
>> } catch {
>> 
>> }
>> 
>> Something like this could be shortened to a consistent theoretical inline 
>> try catch syntax like:
>> 
>> try myFunction() catch {
>> 
>> }
>> 
>> Though, as John, pointed out at the time, this could still be added on with 
>> the current syntax. Obviously treating a try like an unnamed function would 
>> have different return semantics, so perhaps that's not the right 
>> abstraction. (Although I recall a thread going on that is considering 
>> allowing functions to retain return semantics of the outer scope)
>> 
>> Tyler
>> 
>> 
>>> 
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

__

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Dave Abrahams via swift-evolution]

> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier  wrote:
> 
> Please see comments inline.
> 
>> On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
 On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 So “try” instead of “do”. If there is no catch, then just use braces 
 without a keyword for a block. 
 
 And use do-while instead of repeat-while.
>> 
>> +1
>> 
>>> 
>>> Do you also propose no longer marking calls to throwing functions with 
>>> `try`?
>> 
>> If try had both a single-statement/expression form as it does today, and a 
>> block form that makes it unnecessary to mark all the individual statements 
>> in the block, that would be an improvement.
>> 
>>> Have you read the "Error-Handling Rationale" document in the Swift 
>>> repository? If not, please do: 
>>> 
>>>  If so, please explain why you disagree with it.
>> 
>> There are large classes of programs where you can know you don’t care 
>> exactly where a failure happens, e.g. (most init functions, all pure 
>> functions, any function that doesn’t break invariants).  In these cases 
>> marking every statement or expression that can throw is just noise.  Try 
>> writing some serialization/deserialization code where the underlying stream 
>> can fail to see what I mean; you’ll have “try” everwhere, and it adds 
>> nothing to comprehensibility or maintainability.  Personally I would like to 
>> be able to label the function itself and not have to introuce a scope, but 
>> IMO being able to create “try blocks” would be a welcome addition and would 
>> even match the common case in blocks with catch clauses, where being aware 
>> of the exact line where the error was generated is typically not useful.
> 
> I had proposed something very similar to this around six months ago on the 
> swift-users list, but I think John McCall, had some (quite valid) concerns 
> with this.
> 
> Unfortunately I can't access those emails, but I think his concern was that 
> the purpose of try was to mark explicitly which statements throw and this 
> would defeat the purpose of that. People might just wrap large blocks in try.

As much as I am loath to disagree with John on this, there’s an incorrect 
implicit assumption in that rationale, that forcing people to mark all throw 
points trains them to get error-handling correct.  What it does instead is to 
train them to think of all code uniformly instead of recognizing the places 
where a throw needs special attention (places where there are broken 
invariants).  Eventually, as with warnings that have a high false-positive 
rate, when you see “try” in many places where it doesn’t help, you learn to 
ignore it altogether.

> 
> Another idea is to treat the block as an unnamed, no argument, no return 
> value, function that could throw. This solves the problem in a very general 
> way, and would retain the marking of all throwing functions with try,

That marking, in itself, is the root problem.  Our syntax is the way it is 
primarily because "marking everywhere" was adopted as an explicit goal.

> but has the perhaps unfortunate syntax of allowing things like:
> 
> try {
>try myFunction()
> } catch {
> 
> }
> 
> Something like this could be shortened to a consistent theoretical inline try 
> catch syntax like:
> 
> try myFunction() catch {
> 
> }
> 
> Though, as John, pointed out at the time, this could still be added on with 
> the current syntax. Obviously treating a try like an unnamed function would 
> have different return semantics, so perhaps that's not the right abstraction. 
> (Although I recall a thread going on that is considering allowing functions 
> to retain return semantics of the outer scope)
> 
> Tyler
> 
> 
>> 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

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

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Alex Migicovsky via swift-evolution]

> * What is your evaluation of the proposal?

I think the proposal is great. The only thing I’d prefer is to use `associated` 
over `associatedtype`.

`associated` has always felt better to me over `associatedtype`. It was 
mentioned in one of the original proposals as the keyword that was initially 
most well received as well—I think this is because it just feels right, which 
is a good indicator even though it doesn’t seem scientific :-)

One downside mentioned is that `associated` is more vague than 
`associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
`classtype`, etc as keywords over `protocol` and `class`. I think the 
convention of having associated type names start with an uppercase letter makes 
it clear that what follows `associated` is a type (or will be a concrete type).

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

Yes, I’ve seen many developers be confused by the difference between defining a 
typealias inside a protocol declaration vs outside.

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

Yes.

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

I’ve been paying attention to the thread and have thought about why I like 
`associated` over `associatedtype` since the start of the thread.

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

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Dave Abrahams via swift-evolution]

> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution 
>  wrote:
> 
> 
>> 
>>> There are large classes of programs where you can know you don’t care 
>>> exactly where a failure happens, e.g. (most init functions, all pure 
>>> functions, any function that doesn’t break invariants).  In these cases 
>>> marking every statement or expression that can throw is just noise.  Try 
>>> writing some serialization/deserialization code where the underlying stream 
>>> can fail to see what I mean; you’ll have “try” everwhere, and it adds 
>>> nothing to comprehensibility or maintainability.  Personally I would like 
>>> to be able to label the function itself and not have to introuce a scope, 
>>> but IMO being able to create “try blocks” would be a welcome addition and 
>>> would even match the common case in blocks with catch clauses, where being 
>>> aware of the exact line where the error was generated is typically not 
>>> useful.
>> 
>> That's a really interesting idea, but I don't think it's what the poster was 
>> suggesting. It sounded to me like he was merely saying “let's make the Swift 
>> error system look like my favorite language's exception system".
> 
> I agree with Brent’s assessment of the OP. However that doesn’t mean that 
> Dave does not have a good point. Here is some code from a recursive descent 
> parser. (More correctly: the recognizer. Omitting the AST-building stuff.)
> 
>func recognizeHandler() throws {
>try accept(.on)// .on is an enum tag for the token for the 
> ‘on’ keyword.
>try recognizeName()
>try recognizeFormalParamSeq()
>try accept(.newline)
>try recognizeCommandSeq()
>try accept(.end)
>try recognizeName()// Later Visitor pass checks that names match. 
>try accept(.newline)
>}
> 
> There is a lot more where that came from.

Exactly.  The natural response from framework designers is to find more ways to 
support writing entire functions as a single expression.  At the limit, you end 
up with 
http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html.

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

-Dave

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

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Rudolf Adamkovič via swift-evolution]

Sorry for the previous message. I pressed “Send” by mistake...

Here is my +1:

>   * What is your evaluation of the proposal?

It’s a great improvement.

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

Definitely.

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

Yes.

>   * If you have you 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 discussion closely.

—

Rudolf Adamkovic

R+

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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 3, 2016, at 10:53 AM, David Waite via swift-evolution 
>  wrote:
> 
> I like this, and had considered proposing something similar.
> 
> Points:
> I would have chose to leave protocol to mean the dynamically dispatch-able 
> type declaration, as that is what it indicates in Objective-C. Your proposal 
> would cause every Objective-C protocol to now be considered an interface in 
> Swift terms.
> 
> Some discussion on this list makes me think that you might instead have a 
> modifier for declaring statically dispatched, existential protocols - e.g. 
> “existential protocol SequenceType { … }”

The problem with *requiring* distinct syntax for protocols that are intended to 
be used as existential a is that it is a stated goal to expand the kinds of 
protocols which can be used as existentials.  In other words, the set of 
protocols that can be used as existentials is a moving target that is likely to 
grow substantially in the future.

I would be comfortable with some kind of optional assertion that a protocol can 
be used as an existential but probably not comfortable with anything more than 
that.

> 
> Also, note not all usage of Self need be disallowed in dynamically 
> dispatch-able types today:
> 
> protocol Test { 
>  func foo() -> Self 
> }
> 
> var t:Test? // legal, I assume on purpose due to the covariance of the return 
> type
> 
> -DW
> 
>> On Jan 3, 2016, at 7:48 AM, Антон Жилин via swift-evolution 
>>  wrote:
>> 
>> Introduction of interfaces will clean up the current blend of static and 
>> dynamic protocols, and solve at least three popular issues.
>> Please see:
>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>  ___
>> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Rudolf Adamkovic via swift-evolution]

>   * 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
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[David Waite via swift-evolution]

I like this, and had considered proposing something similar.

Points:
I would have chose to leave protocol to mean the dynamically dispatch-able type 
declaration, as that is what it indicates in Objective-C. Your proposal would 
cause every Objective-C protocol to now be considered an interface in Swift 
terms.

Some discussion on this list makes me think that you might instead have a 
modifier for declaring statically dispatched, existential protocols - e.g. 
“existential protocol SequenceType { … }”

Also, note not all usage of Self need be disallowed in dynamically 
dispatch-able types today:

protocol Test { 
 func foo() -> Self 
}

var t:Test? // legal, I assume on purpose due to the covariance of the return 
type

-DW

> On Jan 3, 2016, at 7:48 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Introduction of interfaces will clean up the current blend of static and 
> dynamic protocols, and solve at least three popular issues.
> Please see:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>  
> 
>  ___
> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[David Waite via swift-evolution]

>   * What is your evaluation of the proposal?


+1, with caveats

From a wording perspective, the “Proposed Approach” and “Impact on Existing 
Code” sections talk about removing typealias, while the intention is almost 
certainly to remove typealias usage within protocols only. My review assumes 
the latter.  

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

I think it is based on Swift today, in particular for the reasons given in the 
proposal (that it looks like, but is not possible, to use typealias to declare 
a type alias inside a protocol)

I personally find it cumbersome that Swift does not allow protocols with 
associated types to be used other than under generic constraints - I would 
prefer generic protocols. If generic protocols were on the horizon, then I do 
not know whether declaring associated types inline is even a necessary feature.

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

Yes, although I still feel the keyword is long.

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

Since Swift is the only language I have used with associated types, I can only 
compare to Swift 1 and 2. I feel this will make the protocols themselves easier 
to understand

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
I followed the mailing list for the most part, read the proposal, and imagined 
adding it to my own protocols.

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

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

[Matthew Johnson via swift-evolution]

Sorry if this should be clear already, but are you suggesting that @patch would 
allow patching of final or sealed types thus making them more palatable as 
defaults?  This would surprise me, but if that is not what you are suggesting I 
don't follow how it relates to the final / sealed discussion.

Matthew

Sent from my iPad

> On Dec 31, 2015, at 1:13 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> A lot of the discussion around the final/sealed-by-default issue focused on 
> the ability in ObjC to extend frameworks or fix bugs in unforeseen ways. 
> Framework developers aren't perfect, and being able to patch a broken 
> framework method can be the difference between shipping and not. On the other 
> hand, these patches become compatibility liabilities for libraries, which 
> have to contend not only with preserving their own designed interface but all 
> the undesigned interactions with shipping apps based on those libraries. The 
> Objective-C model of monkey-patchable-everything has problems, but so does 
> the buttoned-down everything-is-static C++ world many of us rightly fear. 
> However, with the work we're putting into Swift for resilience and strong 
> versioning support, I think we're in a good position to try to find a 
> reasonable compromise. I'd like to sketch out a rough idea of how that might 
> look. Public interfaces fundamentally correspond to one or more dynamic 
> library symbols; the same resilience that lets a new framework version 
> interact with older apps gives us an opportunity to patch resilient 
> interfaces at process load time. We could embrace this by allowing 
> applications to provide `@patch` implementations overriding imported 
> non-fragile public APIs at specific versions:
> 
> import Foundation
> 
> extension NSFoo {
>   @patch(OSX 10.22, iOS 17)
>   func foo() { ... }
> }
> 
> By tying the patch to a specific framework version, we lessen the 
> compatibility liability for the framework; it's clear that, in most cases, 
> the app developer is responsible for testing their app with new framework 
> versions to see if their patch is still needed with each new version. Of 
> course, that's not always possible—If the framework developer determines 
> during compatibility testing that their new version breaks a must-not-break 
> app, and they aren't able to adopt a fix on their end for whatever reason (it 
> breaks other apps, or the app's patch is flawed), the framework could declare 
> that their new version accepts patches for other framework versions too:
> 
> // in Foundation, OSX 10.23
> public class NSFoo {
>   // Compatibility: AwesomeApp patched the 10.22 version of NSFoo.foo.
>   // However, RadicalApp and BodaciousApp rely on the unpatched 10.22 
> behavior, so
>   // we can't change it.
>   @accepts_patch_from(AwesomeApp, OSX 10.22)
>   public func foo() { ... }
> }
> 
> A sufficiently smart dynamic linker could perhaps resolve these patches at 
> process load time (and probably summarily reject patches for dylibs loaded 
> dynamically with dlopen), avoiding some of the security issues with arbitrary 
> runtime patching. For public entry points to be effectively patchable, we'd 
> have to also avoid any interprocedural optimization of the implementations 
> within the originating module, so there is a performance cost to allowing 
> this patching by default. Sufficiently mature (or arrogant) interfaces could 
> perhaps declare themselves "unpatchable" to admit IPO within their own 
> module. (Note that 'fragile' interfaces which admit cross-module inlining 
> would inherently be unpatchable, and those are likely to be the most 
> performance-sensitive interfaces to begin with.)
> 
> -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] [Proposal Draft] Flexible memberwise initialization

[Tino Heth via swift-evolution]

> What are those advantages precisely?  
subjective: Easier to understand
objective: Saves keywords/syntax ("…", "memberwise", "@nomemberwise", 
"required", "convenience", "@default"…)

>> What I can see in your example is that the proposed syntax allows me to 
>> trigger compiler errors that will never happen with Kotlin (and errors that 
>> cannot happen are the ones I like the most).
> 
> Can you point out what potential compiler errors you are concerned about?  
> Are you referring to the access control example where the compiler does not 
> synthesize initialization of a private member in an internal memberwise 
> initializer and thus requires manual initialization of the private member?
Exactly.

>> public class Customer(title: String, private var birthday: NSDate?, public 
>> address: String = "n/a"): Person {
>> 
>>  protected let statusPoints = - birthday?.timeIntervalSinceNow() ?? 0.0
>> 
>>  let constantWithHardToExpressValue: Int
>> 
>>  lazy var age: Int = dateCalculationIsHard(birthday)
>> 
>>  init {
>>  constantWithHardToExpressValue = Int(statusPoints) + 1
>>  super.init(title: title)
>>  }
>>  
>>  public init(titlePrefix: String, titleSuffixObject: Any) {
>>  init(title: titlePrefix + titleSuffixObject.description, 
>> birthday: NSDate())
>>  }
>> }
>> 
>> So: Dear reader, please do my job and explain the "pseudo"-source above ;-) 
>> — or ask questions if you are just puzzled by it.
> 
> This must be what you are suggesting for Swift because the example uses 
> NSDate?
Yes indeed — I'm quite sure Kotlin couldn't compile that ;-).

> Is it correct that this class would have the following members in addition to 
> the ones declared in the body?
Yes (but see below)

> You used access control modifiers in that parameter list.  Would you allow 
> any annotations that are valid for properties that can be initialized (i.e. 
> not lazy, but maybe an observable behavior if Property Behaviors are 
> accepted)?


> let title: String // internal
> private var birthday: NSDate?
> public let address: String = “n/a”
> 
> It actually looks like you pass `title` to super so maybe that isn’t expected 
> to synthesize a member?
Yes

> If that is the case how does the compiler determine which parameters should 
> receive member synthesis?
It could be inferred, but actually I'd prefer explicit rules (those could be 
"let x: Int" -> constant, "var…" variable, "x: Int" nothing is synthesized, the 
parameter is used for the parent initializer or to compute the value of a 
member that isn't visible)

> If not, I assume super would not have a `title` member and is doing something 
> else with that argument.  Is that what you intend?
Yes

> Is it also correct that all of the following forms would be valid at call 
> sites?
> 
> Customer(title: “a title”, birthday: nil)
> Customer(title: “a title”, birthday: nil, address: “an address”)
> Customer(titlePrefix: “a prefix”, titleSuffixObject: Foo())
Yes

> If so, does the initializer used in the first two call examples (the 
> designated / memberwise initializer?) receive the same access control as the 
> type itself since it cannot be specified directly?
Yes and no:
Kotlin allows you to limit the visibility of the initializer:
class Customer private init(...

> Is it also correct that the init block that calls super would be invoked 
> regardless of which initializer form is used?  When would this block run? 
> Immediately after the memberwise initializer is called?  Is it the “body” of 
> the memberwise initializer?
Yes, that is the idea

> It would need to run prior to any use of self in the body of `public 
> init(titlePrefix: String, titleSuffixObject: Any)` in order to follow Swift's 
> rules of definitive initialization.  
True, the same as it is now

> Is the `public init(titlePrefix: String, titleSuffixObject: Any)` initializer 
> actually a convenience initializer?
Yes

> Is it required to call the designated / memberwise initializer before it does 
> anything else?  What rules need to be followed to ensure definitive 
> initialization happens?  Is this rule applicable to all additional 
> initializers the author writes?  If it is a convenience initializer maybe it 
> just follows the current rules for those in Swift?
Yes, everything in this hypothetic model behaves like it does now

> Maybe the memberwise parameters plus the body is the single and only 
> designated initializer for the type?  Is that what you’re suggesting?
It would be possible to allow additional designated initializers, but imho this 
should at least be discouraged.

> What if the init body needs additional non-memberwise parameters?  Is it 
> allowed to specify those?
Yes

> If so how is that accomplished?
See above ("which parameters receive member synthesis")

> How is the parameter ordering in the final parameter list determined?
Like in a regular function call.

> Would you use the `…` placeholder for the membe

[swift-evolution] [Proposal] Separate protocols and interfaces

[Антон Жилин via swift-evolution]

Introduction of interfaces will clean up the current blend of static and
dynamic protocols, and solve at least three popular issues.
Please see:
https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Matthew Johnson via swift-evolution]

>   * What is your evaluation of the proposal?

I like this proposal.  I think it adds clarity to the language.  Especially 
after the change from 'associated' to 'associatedtype'.

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

Yes.  It isn't a huge issue for me but has causes confusion for some.  A 
distinct keyword improving clarity is worth the change.

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

Yes.

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

I am familiar with several.  This proposal is different than anything I've see, 
but in a good way.

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

I read the proposal, followed the discussion, and thought about the tradeoffs.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Asserts should not cause undefined behaviour

[Joseph Lord via swift-evolution]

I gave a quick reply to an email later in the chain last night but I think 
these points are worth addressing. Apologies for the slow response, I wanted to 
ponder and consider the points rather than rush the response.

>> On Dec 31, 2015, at 8:27 PM, Chris Lattner  wrote:
>> 
>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution 
>>  wrote:
>> The documented behaviour of assert and assertionFailure in "disable safety 
>> checks" builds (still documented as -Ounchecked) is that the compiler "may 
>> assume that it would evaluate to true" or in the assertionFailure case never 
>> be called.
> 
> Right.
> 
>> This documented behaviour would allow the compiler to completely eliminate 
>> tests and branches before or after the assertion and take the operation deep 
>> into undefined behaviour.
> 
> Only in cases where the assertion would have failed, right?  The point of 
> -Ounchecked is that - if your code was correct with the checks - that it will 
> still be correct.  Disabling overflow and array bounds checks is far more 
> dangerous than the assertion behavior you cite here.

Yes only when it would have failed but that may still make correct code 
incorrect where whole branches of runtime belt and braces code could be a 
eliminated. 

>> It appears from the code as if the assumption is not currently applied on 
>> the assert method although it is on the assertionFailure case by means of 
>> the _conditionallyUnreachable() call. assert seems to be a no-op in both 
>> normal release and disable safety checks build modes.
> 
> Right.
> 
>> [Proposed Change]
>> 
>> Change the documentation for assert and assertionFailure so that behaviour 
>> in unchecked mode is the same as in normal release - no evaluation and no 
>> effect.
> 
> Why? :
> 
>> 1) Expected behaviour based on other languages is for assert to have no 
>> effect in release. (If current behaviour is highly desired another function 
>> name should be used). Having potential dangerous behaviour from a function 
>> that is familiar across languages and is regarded as a safety feature is 
>> undesirable.
> 
> This is the C model, but as you know, there is a whole field of custom 
> assertions libraries that people have developed.  I don’t think there is 
> anything like consensus on this topic.

C, Python, Erlang, Ocaml, Java (although it can enabled at runtime) and 
probably more. I recognise that in house assertion policies and systems may 
have different behaviours and agreed modes but I think affecting surrounding 
code (before and after the assertion) is surprising based on people experience 
with these other languages. I have not seen elsewhere any instances of 
compilers removing code outside of the branch itself which could be possible if 
the compiler is allowed to assume the truth of the assertion condition. 

if let names = jsonObject as? [String] where names.count > 0 {
  print(names.first)
} else {
  assertionFailure("Invalid JSON")
  return nil
}

Could be compiled to pretty much an unconditional print of an address in 
unchecked. The nil return could be unreachable, the if let reduced to an unsafe 
bitcast (maybe not given array bridging but possibly in other cases) and the 
.first converted to [0] given the assumed passing of the where clause.

>> 2) Adding asserts to code should not make the code more dangerous whatever 
>> the build. Assuming the truth of the assert may lead to runtime safety 
>> checks being skipped and undefined behaviour when a no-op would be a safe 
>> behaviour.
> 
> This only affects code built with -Ounchecked, which is definitely not a safe 
> mode to build your code.  The intention of this mode is that you can use it 
> to get a performance boost, if you believe your code to be sufficiently 
> tested.  This mode, which isn’t the default in any way, intentionally takes 
> the guard rails off to get better performance.
> 
> If you don’t like that model, don’t use this mode

One fear is that libraries will be compiled in this way by people who aren't 
the original authors and that people won't realise the consequences.

>> 3) "For highly robust code assert and then handle the error anyway" [Code 
>> Complete 2nd Edition section 8.2]
> 
> Highly robust code shouldn’t build with -Ounchecked, so I don’t see how this 
> point is pertinent.

The quote was external validation of the concept of having asserts where the 
case is also handled. I would not limit the use to "highly robust code". 

However as I said in my other email if no one else is concerned I will just go 
away and use my custom assertions and miss out on the compiler hinting.

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:

The idea of including C libraries/code in Swift projects *without* having to 
use Xcode strikes me as *very* valuable. Two questions:

a) for item (2) in "solution" I see the advantages of placing the bridging in a 
separate directory, but I want to point out that this may make the interactions 
between various devenvs and things like GitHub more annoying. Xcode's 
Bridging-Header solution has it's own problems, but may be easier to work with 
in complex projects. Generally I think more flexibility here might be valuable, 
even going so far as a ".bh" for the bridging files, allowing them to be placed 
anywhere.

b) for (3), I'm facing this problem right now porting some very old C that has 
a main.c that includes main() as well as other more general code that the rest 
of the system uses. I solved this by changing main(), but that's not ideal, I 
would greatly prefer to use the original code verbatim. So for the 10% of cases 
where this is a problem, perhaps a compiler directive would be useful?


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

Re: [swift-evolution] Inquiry: Status of SR-122 ?

[plx via swift-evolution]

Thanks for pointing me at it; at a quick read I like the functionality, but 
will have to take a closer look to get a sense of its feel in use.

It certainly addresses the current gripes I have around `CollectionType` 
requiring a `ForwardIndexType`: for all but the truly-linear collections (e.g., 
Array-like) implementing `successor()` either forces you to hold a 
back-reference, or leaves you choosing between holding a back-reference or 
having rather “fat” indices.

If the collection becomes responsible for moving the index this is all mooted; 
I can finish the sketched refactoring proposal and simply refer to this 
(prototype? proposal?) as something else that’d be needed to get the full 
benefit.

> On Jan 2, 2016, at 11:24 AM, Dmitri Gribenko  wrote:
> 
> On Sat, Jan 2, 2016 at 4:53 AM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>>> On Jan 1, 2016, at 4:34 PM, plx via swift-evolution 
>>>  wrote:
>>> 
>>> I was preparing a proposal-sketch relating to this earlier discussion: 
>>> http://article.gmane.org/gmane.comp.lang.swift.evolution/1629
>>> 
>>> …which is largely about inserting "intermediate steps” between 
>>> `SequenceType` and `CollectionType`, but to get the full benefit would 
>>> likely wind up requiring modifications to the API on the `*Index` types 
>>> (e.g. `ForwardIndexType`, which at present is required of a 
>>> `CollectionType`’s `Index`).
>>> 
>>> Searching for prior discussion/work I found this bug: 
>>> https://bugs.swift.org/browse/SR-122 , and was curious if anything further 
>>> has happened on that topic?
>> 
>> Yes, Dmitri has been making progress on an implementation.  He may be able 
>> to point you at it…
> 
> The prototype is checked in at
> test/Prototypes/CollectionsMoveIndices.swift, feel free to ask me more
> questions about it.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */

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

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Janosch Hildebrand via swift-evolution]

> On 03 Jan 2016, at 07:38, Douglas Gregor  wrote:
> 
>   * What is your evaluation of the proposal?

I am in favor of this for the same reasons mentioned by the previous reviewers.

>   * 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?

I think so. 

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

I am only aware of Rust and I haven't used that enough to make any meaningful 
comparisons.

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

I read the proposal and followed the previous threads discussing the proposal 
and the keyword.

Speaking of which, `associatedtype` remains my favorite. I don't think its 
ideal but I prefer it to the alternatives that were considered.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

- Janosch

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[T.J. Usiyan via swift-evolution]

+1 from me. It is a solid change that addresses an oddity in the language.

On Sun, Jan 3, 2016 at 7:27 AM, plx via swift-evolution <
swift-evolution@swift.org> wrote:

> I like this.
>
> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "Replace `typealias` keyword with `associatedtype` for
> associated type declarations” begins now and runs through Wednesday,
> January 6th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.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?
>
>
> It’s a good idea and improves the language.
>
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
>
>
> Yes, the existing situation is comprehensible (if you think like a
> language-implementer) but highly non-intuitive and generally sub-optimal
> for language users.
>
> * Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes; conservation-of-reserved-terms is valuable, but giving different
> things different names fits the feel much better here.
>
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
>
> To the extent I’m aware of analogous situations in other languages, none
> of them actually seem to use distinct keywords, but they also don’t have
> the confusing situation Swift has vis-a-vis typealiases with concrete
> definitions (in protocols).
>
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Quick read, plus having been bit by issues the proposal addresses numerous
> times.
>
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Cheers,
> Doug Gregor
> 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] Customized Inline Init Closure

[Tino Heth via swift-evolution]

Something similar has been discussed ("method cascading"), and I hope the 
feature will be considered for Swift 4(?).
It is a little bit different, though:
"self" would not change its meaning (which imho is a plus), and the syntax is 
different.

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

I like this.

> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "Replace `typealias` keyword with `associatedtype` for 
> associated type declarations” begins now and runs through Wednesday, January 
> 6th. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.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?

It’s a good idea and improves the language.

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

Yes, the existing situation is comprehensible (if you think like a 
language-implementer) but highly non-intuitive and generally sub-optimal for 
language users.

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

Yes; conservation-of-reserved-terms is valuable, but giving different things 
different names fits the feel much better here.

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

To the extent I’m aware of analogous situations in other languages, none of 
them actually seem to use distinct keywords, but they also don’t have the 
confusing situation Swift has vis-a-vis typealiases with concrete definitions 
(in protocols).

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

Quick read, plus having been bit by issues the proposal addresses numerous 
times.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Drew Crawford via swift-evolution]

LOL

I don't think my you can get a stronger +1 for removing this than "reviewer 
doesn't understand the feature"!

> On Jan 3, 2016, at 5:41 AM, Loïc Lecrenier  wrote:
> 
> Hi Drew,
> 
> Thanks for the review, just a quick remark:
> 
> “Real” type aliases are already forbidden inside protocols, so this proposal 
> wouldn’t change that.
> (According to the grammar, a protocol body can only contain: property, 
> method, initializer, subscript, or associated type member declarations)
> 
> In your example, secondstype and usecstype were associated types with initial 
> values. To convince yourself, try to create this function
> func bar(_: Foo) { }
> and you should see the "can only be used as a generic constraint because it 
> has Self or associated type requirements” error.
> 
> I initially wanted to allow type aliases inside protocols, and I was told 
> type aliases weren’t requirements, so they shouldn’t be defined inside 
> protocols, which makes sense to me.
> 
> We might want to reconsider this, but I think it is outside the scope of this 
> proposal.
> 
> Loïc
> 
>> On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution 
>>  wrote:
>> 
>> 
>>> 
>>>* What is your evaluation of the proposal?
>> 
>> +1
>> 
>>>* Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes.  A typealias in a protocol and a typealias anywhere else are 2 very 
>> different things.
>> 
>> * One is almost a preprocessor macro
>> * The other basically defines the protocol as a generic type, which has a 
>> lot of strange follow-on consequences
>> 
>> There are plenty of questions online related to this confusion.
>> 
>> In addition the change is trivial and code could be transitioned 
>> automatically.
>> 
>>>* Does this proposal fit well with the feel and direction of Swift?
>> 
>> The choice of keyword "associatedtype" is already used in a common compiler 
>> error message:
>> 
>>> protocol 'Printable' can only be used as a generic constraint because it 
>>> has Self or associated type requirements
>> 
>> Using "associatedtype" here is consistent with that error message and makes 
>> it more understandable for new users.
>> 
>>>* If you have you used other languages or libraries with a similar 
>>> feature, how do you feel that this proposal compares to those?
>> 
>> I am an occasional user of Rust; Rust uses the same keyword ("type") in both 
>> of these cases.  IMO that choice is suffers from the same problems in Rust 
>> that it does here.
>> 
>>>* How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> One "potential" problem with this proposal is that it technically forbids 
>> the use of a "real" typealias in a protocol e.g.
>> 
>> protocol Foo {
>>typealias F = Int
>> }
>> 
>> is now illegal.
>> 
>> To evaluate the severity of this problem I checked a private codebase with 
>> 47 usages of typealias.  One usage of the 47 would be illegal:
>> 
>> protocol Foo {
>>  #if arch(x86_64) || arch(arm64)
>>typealias secondstype = Int64
>>typealias usecstype = Int64
>>  #else
>>typealias secondstype = __darwin_time_t
>>typealias usecstype = __darwin_suseconds_t
>>   #endif
>>func setTimeout(s: secondstype, u: usecstype) throws
>> }
>> 
>> I refactored this to move the typealiases to top level.  That is not ideal, 
>> but I think it is outweighed by the advantages of this proposal.
>> 
>> While auditing this codebase for illegal typealiases I did find a comment 
>> that was quite confused about the difference between typealias and 
>> associatedtype.  So that convinces me even more about the importance of this 
>> proposal.
>> 
>> ___
>> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Loïc Lecrenier via swift-evolution]

Hi Drew,

Thanks for the review, just a quick remark:

“Real” type aliases are already forbidden inside protocols, so this proposal 
wouldn’t change that.
(According to the grammar, a protocol body can only contain: property, method, 
initializer, subscript, or associated type member declarations)

In your example, secondstype and usecstype were associated types with initial 
values. To convince yourself, try to create this function
func bar(_: Foo) { }
and you should see the "can only be used as a generic constraint because it has 
Self or associated type requirements” error.

I initially wanted to allow type aliases inside protocols, and I was told type 
aliases weren’t requirements, so they shouldn’t be defined inside protocols, 
which makes sense to me.

We might want to reconsider this, but I think it is outside the scope of this 
proposal.

Loïc

> On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
>> 
>>  * What is your evaluation of the proposal?
> 
> +1
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes.  A typealias in a protocol and a typealias anywhere else are 2 very 
> different things.
> 
> * One is almost a preprocessor macro
> * The other basically defines the protocol as a generic type, which has a lot 
> of strange follow-on consequences
> 
> There are plenty of questions online related to this confusion.
> 
> In addition the change is trivial and code could be transitioned 
> automatically.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> The choice of keyword "associatedtype" is already used in a common compiler 
> error message:
> 
>> protocol 'Printable' can only be used as a generic constraint because it has 
>> Self or associated type requirements
> 
> Using "associatedtype" here is consistent with that error message and makes 
> it more understandable for new users.
> 
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
> 
> I am an occasional user of Rust; Rust uses the same keyword ("type") in both 
> of these cases.  IMO that choice is suffers from the same problems in Rust 
> that it does here.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> One "potential" problem with this proposal is that it technically forbids the 
> use of a "real" typealias in a protocol e.g.
> 
> protocol Foo {
> typealias F = Int
> }
> 
> is now illegal.
> 
> To evaluate the severity of this problem I checked a private codebase with 47 
> usages of typealias.  One usage of the 47 would be illegal:
> 
> protocol Foo {
> #if arch(x86_64) || arch(arm64)
> typealias secondstype = Int64
> typealias usecstype = Int64
>   #else
> typealias secondstype = __darwin_time_t
> typealias usecstype = __darwin_suseconds_t
>#endif
>   func setTimeout(s: secondstype, u: usecstype) throws
> }
> 
> I refactored this to move the typealiases to top level.  That is not ideal, 
> but I think it is outweighed by the advantages of this proposal.
> 
> While auditing this codebase for illegal typealiases I did find a comment 
> that was quite confused about the difference between typealias and 
> associatedtype.  So that convinces me even more about the importance of this 
> proposal.
> 
> ___
> 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] Swift 2.2: #if swift language version

[Goffredo Marocchi via swift-evolution]

+1 from me as well, supporting conditional compilation when the two versions of 
foundation differ and may differ for the foreseeable future seems a must on 
this end.

Sent from my iPhone

> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>  wrote:
> 
>> If we are going to support something like this, I’d rather see it be 
>> something everyone could leverage as there are many use cases for this 
>> feature:
>> 
>> #if available("package-name", "1.2.*")
>> #endif
> 
> Big +1.
> 
> I've asked specifically to get some kind of conditional compilation on 
> corelibs-foundation being used.  corelibs-founcation is currently 
> incompatible with Darwin Foundation, and so it is impractical to make a 
> single codebase build for both.
> 
> But building the same application against both Foundations and spotting 
> differences is one of the important ways we're going to spot bugs.
> 
> So I think the code quality of Foundation ultimately hinges on getting some 
> feature like this in the language.
> 
> ___
> 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] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Drew Crawford 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.  A typealias in a protocol and a typealias anywhere else are 2 very 
different things.

* One is almost a preprocessor macro
* The other basically defines the protocol as a generic type, which has a lot 
of strange follow-on consequences

There are plenty 

 of questions 
 online 
related to this confusion.

In addition the change is trivial and code could be transitioned automatically.

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

The choice of keyword "associatedtype" is already used in a common compiler 
error message:

> protocol 'Printable' can only be used as a generic constraint because it has 
> Self or associated type requirements


Using "associatedtype" here is consistent with that error message and makes it 
more understandable for new users.

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

I am an occasional user of Rust; Rust uses the same keyword ("type") in both of 
these cases.  IMO that choice is suffers from the same problems in Rust that it 
does here.

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


One "potential" problem with this proposal is that it technically forbids the 
use of a "real" typealias in a protocol e.g.

protocol Foo {
typealias F = Int
}

is now illegal.

To evaluate the severity of this problem I checked a private codebase with 47 
usages of typealias.  One usage of the 47 would be illegal:

protocol Foo {
  #if arch(x86_64) || arch(arm64)
typealias secondstype = Int64
typealias usecstype = Int64
  #else
typealias secondstype = __darwin_time_t
typealias usecstype = __darwin_suseconds_t
   #endif
func setTimeout(s: secondstype, u: usecstype) throws
}

I refactored this to move the typealiases to top level.  That is not ideal, but 
I think it is outweighed by the advantages of this proposal.

While auditing this codebase for illegal typealiases I did find a comment that 
was quite confused about the difference between typealias and associatedtype.  
So that convinces me even more about the importance of this proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

[Drew Crawford via swift-evolution]

> If we are going to support something like this, I’d rather see it be 
> something everyone could leverage as there are many use cases for this 
> feature:
> 
> #if available("package-name", "1.2.*")
> #endif

Big +1.

I've asked specifically to get some kind of conditional compilation on 
corelibs-foundation 

 being used.  corelibs-founcation is currently incompatible with Darwin 
Foundation, and so it is impractical to make a single codebase build for both.

But building the same application against both Foundations and spotting 
differences is one of the important ways we're going to spot bugs.

So I think the code quality of Foundation ultimately hinges on getting some 
feature like this in the language.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

[Andrew Duncan via swift-evolution]

> 
>> There are large classes of programs where you can know you don’t care 
>> exactly where a failure happens, e.g. (most init functions, all pure 
>> functions, any function that doesn’t break invariants).  In these cases 
>> marking every statement or expression that can throw is just noise.  Try 
>> writing some serialization/deserialization code where the underlying stream 
>> can fail to see what I mean; you’ll have “try” everwhere, and it adds 
>> nothing to comprehensibility or maintainability.  Personally I would like to 
>> be able to label the function itself and not have to introuce a scope, but 
>> IMO being able to create “try blocks” would be a welcome addition and would 
>> even match the common case in blocks with catch clauses, where being aware 
>> of the exact line where the error was generated is typically not useful.
> 
> That's a really interesting idea, but I don't think it's what the poster was 
> suggesting. It sounded to me like he was merely saying “let's make the Swift 
> error system look like my favorite language's exception system".

I agree with Brent’s assessment of the OP. However that doesn’t mean that Dave 
does not have a good point. Here is some code from a recursive descent parser. 
(More correctly: the recognizer. Omitting the AST-building stuff.)

func recognizeHandler() throws {
try accept(.on)// .on is an enum tag for the token for the ‘on’ 
keyword.
try recognizeName()
try recognizeFormalParamSeq()
try accept(.newline)
try recognizeCommandSeq()
try accept(.end)
try recognizeName()// Later Visitor pass checks that names match. 
try accept(.newline)
}

There is a lot more where that came from.


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

Re: [swift-evolution] [SR-119] AnySequence --> Any*Collection promotion

[Austin Zheng via swift-evolution]

Agreed, any proposal would come with an accompanying PR. Since the API itself 
is pretty straightforward, I don't think this will put any undue burden on the 
reviewers. 

Austin

> On Jan 3, 2016, at 12:09 AM, Dave Abrahams  wrote:
> 
> 
>> On Jan 2, 2016, at 9:44 PM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> Hello all,
>> 
>> Currently there exist at least four 'type-erased' sequence/collection types: 
>> AnySequence, AnyForwardCollection, AnyBidirectionalCollection, and 
>> AnyRandomAccessCollection.
>> 
>> The three Any*Collection types can be conceptually arranged into a 'ladder', 
>> in which collections can be constructed unconditionally from collection 
>> types above themselves, and conditionally from collection types below 
>> themselves. I've put together a little ASCII image of this here: 
>> (https://gist.github.com/austinzheng/829425242bef1573b668).
>> 
>> Note that AnySequence doesn't currently fit into this ladder: Any*Collection 
>> instances can't easily be constructed from AnySequences. SR-119 
>> (https://bugs.swift.org/browse/SR-119) aims to change that. As per that 
>> ticket, I propose that we add three promotion APIs, sketched out as 
>> following:
>> 
>> extension AnyForwardCollection {
>> init?(_: AnySequence< Element>)
>> }
>> 
>> extension AnyBidirectionalCollection {
>> init?(_: AnySequence< Element>)
>> }
>> 
>> extension AnyRandomAccessCollection {
>> init?(_: AnySequence< Element>)
>> }
>> 
>> Like their Any*Collection --> Any*Collection antecedents, these initializers 
>> construct a new Any*Collection out of an existing AnySequence, but only if 
>> the underlying sequence is compatible, and without copying the underlying 
>> sequence.
>> 
>> I'll also have to examine SE-0014 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md)
>>  more closely to see if it has any effects on this proposal.
>> 
>> I plan on submitting a formal proposal at some point (probably by the end of 
>> the coming week), but first wish to solicit feedback, opinions, concerns, 
>> etc. Thanks for your time.
> 
> My main concern is whether you can implement it, and do so efficiently.  I 
> don’t have a particular reason to think you can’t, but it seems simple enough 
> to check, so IMO such a proposal should come with an implementation.
> 
> -Dave
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

[Developer via swift-evolution]

Well, that's just it.  $ is a perfectly valid character in identifiers 
everywhere but in the grammar for operators for some reason.  It isn't 
reserved, it just isn't there.

~Robert Widmann

2016/01/03 0:53、Brent Royal-Gordon  のメッセージ:

>> Swift currently does not allow operators to use $ - I assume because the 
>> grammar reserves it in one place: `implicit-parameter-name`.  I don't see 
>> why an entire class of identifiers has been eliminated, so I propose $ 
>> instead be reclassified as an `operator-character` so it can be used mixed 
>> in with other such characters, but prevents the introduction of 
>> `$Identifier`-style declarations that might conflict with implicit 
>> parameters.
> 
> I believe the reason you don't see any other $ variables is that they're 
> reserved for the debugger and REPL.
> 
>brent@Brents-MacBook-Pro ~/D/Code> swift
>Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 
> clang-700.1.81). Type :help for assistance.
>  1> "foo"
>$R0: String = "foo"
>  2> print($R0)
>foo
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

[Louis Gerbarg via swift-evolution]

As one of the engineers working on dyld I have a few thoughts on this:

1)  I am not comfortable with one image altering the lazy 
pointers/PLT/stubs used to call between other images, at least during normal 
operation. While most OSes don’t actively prevent people from doing this today 
(if you want to walk through the image lists and the symbol data you can 
totally find where another image’s function pointers are and rewrite them), 
allowing it is a way to subvert control flow (think ROP/JOP). There is a good 
write up about it at 
.
 Suffice it to say, I think most platforms are going to end up having to 
(further) restrict the ability to interpose in order to protect against these 
sorts of attacks, so building a language feature around it seems like a bad 
idea in terms of future proofing/portability.

2)  I am conceptually fine with the semantics that would be exposed by a 
library rewriting its own lazy pointers/PLT/stubs, though at a practical level 
I am not comfortable guaranteeing enough stability in the internal interfaces 
to allow a binary image to embed that machinery inside of itself necessary to 
do that. Of course, those semantics could be achieved purely in the 
compiler/static linker by having the @patch generate glue wrapping the patched 
function that decides whether to call through or use the patched implementation.
This has the virtue of being insulated from the semantic differences 
between dyld and ld.so, though it is also admittedly a much weaker form of 
patching then what can be achieved by directing the dynamic linkers to rewrite 
the pointers of other images.

More comments inline:

> On Jan 1, 2016, at 12:28 PM, Félix Cloutier  wrote:
> 
> How would this extend to third-party libraries that evolve independently of 
> Apple's release schedule and to the Linux compiler?
> 
> Is a patch scoped to the executable object that declares it? For instance, if 
> I have a patch in a library, do applications that link against it see the 
> patch? If I have a Mach-O plugin, does it see the patches that my program 
> made (and vice-versa)? (I'm assuming that the patches go at the PLT/stub 
> level, but let's be sure that this is what we need and that it doesn't cause 
> any security interference)

It has to be scoped to the executable image declaring it if you implement it as 
glue. If it were done through a dynamic linker feature it could conceivably 
allow other images to be patched, but as stated above, in my view that makes 
the feature a lot more fragile and insecure. 

> Should patching be allowed in contexts where DYLD_INSERT_LIBRARIES/LD_PRELOAD 
> are currently disallowed?

If it is done as glue then this falls out naturally, it should be perfectly 
safe to allow patches in restricted contexts as it only patches the code 
explicitly requesting it get it, though it would require more thought. It also 
should provide rational behavior for dlopen()’ing dylibs that contain patches.

> Félix
> 
>> Le 31 déc. 2015 à 14:13:47, Joe Groff via swift-evolution > at swift.org> a écrit :
>> 
>> A lot of the discussion around the final/sealed-by-default issue focused on 
>> the ability in ObjC to extend frameworks or fix bugs in unforeseen ways. 
>> Framework developers aren't perfect, and being able to patch a broken 
>> framework method can be the difference between shipping and not. On the 
>> other hand, these patches become compatibility liabilities for libraries, 
>> which have to contend not only with preserving their own designed interface 
>> but all the undesigned interactions with shipping apps based on those 
>> libraries. The Objective-C model of monkey-patchable-everything has 
>> problems, but so does the buttoned-down everything-is-static C++ world many 
>> of us rightly fear. However, with the work we're putting into Swift for 
>> resilience and strong versioning support, I think we're in a good position 
>> to try to find a reasonable compromise. I'd like to sketch out a rough idea 
>> of how that might look. Public interfaces fundamentally correspond to one or 
>> more dynamic library symbols; the same resilience that lets a new framework 
>> version interact with older apps gives us an opportunity to patch resilient 
>> interfaces at process load time. We could embrace this by allowing 
>> applications to provide `@patch` implementations overriding imported 
>> non-fragile public APIs at specific versions:
>> 
>> import Foundation
>> 
>> extension NSFoo {
>>  @patch(OSX 10.22, iOS 17)
>>  func foo() { ... }
>> }
>> 
>> By tying the patch to a specific framework version, we lessen the 
>> compatibility liability for the framework; it's clear that, in most cases, 
>> the app developer is responsible for testing their app with new framework 
>> versions to see if their patch is still needed with each new version. Of 
>> course, that's not always possible—If the fra

Re: [swift-evolution] [SR-119] AnySequence --> Any*Collection promotion

[Dave Abrahams via swift-evolution]

> On Jan 2, 2016, at 9:44 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> Currently there exist at least four 'type-erased' sequence/collection types: 
> AnySequence, AnyForwardCollection, AnyBidirectionalCollection, and 
> AnyRandomAccessCollection.
> 
> The three Any*Collection types can be conceptually arranged into a 'ladder', 
> in which collections can be constructed unconditionally from collection types 
> above themselves, and conditionally from collection types below themselves. 
> I've put together a little ASCII image of this here: 
> (https://gist.github.com/austinzheng/829425242bef1573b668 
> ).
> 
> Note that AnySequence doesn't currently fit into this ladder: Any*Collection 
> instances can't easily be constructed from AnySequences. SR-119 
> (https://bugs.swift.org/browse/SR-119 ) 
> aims to change that. As per that ticket, I propose that we add three 
> promotion APIs, sketched out as following:
> 
> extension AnyForwardCollection {
> init?(_: AnySequence< Element>)
> }
> 
> extension AnyBidirectionalCollection {
> init?(_: AnySequence< Element>)
> }
> 
> extension AnyRandomAccessCollection {
> init?(_: AnySequence< Element>)
> }
> 
> Like their Any*Collection --> Any*Collection antecedents, these initializers 
> construct a new Any*Collection out of an existing AnySequence, but only if 
> the underlying sequence is compatible, and without copying the underlying 
> sequence.
> 
> I'll also have to examine SE-0014 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md
>  
> )
>  more closely to see if it has any effects on this proposal.
> 
> I plan on submitting a formal proposal at some point (probably by the end of 
> the coming week), but first wish to solicit feedback, opinions, concerns, 
> etc. Thanks for your time.

My main concern is whether you can implement it, and do so efficiently.  I 
don’t have a particular reason to think you can’t, but it seems simple enough 
to check, so IMO such a proposal should come with an implementation.

-Dave

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

Re: [swift-evolution] Proposal: Add SequenceType.first

[Kevin Ballard via swift-evolution]

On Sat, Jan 2, 2016, at 11:53 PM, Dave Abrahams wrote:
> 
> > On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution 
> >  wrote:
> > 
> > On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote:
> >>> `buffered` is no more problematic than `lazy` is. In fact, calling 
> >>> `buffered` actually doesn't have any side-effects at all (it can avoid 
> >>> fetching the first element until you call `first` on the result of 
> >>> `buffered`).
> >> 
> >> If `seq` is a single-pass sequence, then `seq.buffered.first` will consume 
> >> an element from `seq`, even though you only accessed two properties. 
> >> That's why I call it problematic.
> >> 
> >> (If calling `buffered` somehow rendered the original sequence unusable—for 
> >> instance, if we had some way to express that the `BufferedSequence` takes 
> >> unique ownership of its base—this wouldn't bother me as much.)
> > 
> > If `sequence` is a single-pass sequence, wrapping it in any other sequence 
> > type and then doing anything with that other sequence type makes the 
> > original sequence unusable (or rather, you can still use it but the 
> > elements yielded from any further access to the original sequence can be 
> > completely arbitrary).
> > 
> > And for the record we already have precedent for the specific case of 
> > `seq.prop1.prop2` destructively consuming the original sequence: 
> > `seq.lazy.array`.
> 
> Yes, and there are arguments for dropping “.array” as a property.  The 
> convention is that “conversions” (ill-defined, I know) use constructor 
> syntax, and we are currently heading towards the elimination of "convenience” 
> interfaces that duplicate functionality, so we might end up with Array(seq).  
> 
> All that said, single-pass Sequences are just weird in that they get mutated 
> without calling any mutating methods on them; you mutate them by calling a 
> mutating method on a separate generator instance.  In other words, they 
> fundamentally have reference semantics.  There may be some better way to 
> address this whole area, but we’ll have to go much deeper than merely poking 
> at the question of a  `.first` property.

FWIW move-only structs (and safe immutable references) are a great solution to 
this. Rust is a good example. Rust's equivalent to SequenceType is 
IntoIterator, which has a method into_iter() that consumes the receiver and 
returns an Iterator. If a sequence is multi-pass, then instead of just 
implementing it on the type, the IntoIterator trait is also implemented on 
references to that type (e.g. both `Vec` and `&'a Vec` implement it) and 
sometimes on mutable references too (`&'a mut Vec`). The multi-pass 
iterators actually yield references to the elements involved (e.g. the Iterator 
for `Vec` yields `T`, but the Iterator for `&'a Vec` yields `&'a T`). 
Similarly Iterator itself can be move-only if it's a single-pass iterator, but 
for multi-pass iterators the Iterator is either copyable or Clone-able. This 
scheme means that the type system documents whether a sequence/iterator is 
multi-pass and statically prevents you from violating that guarantee.

Of course, Swift doesn't have move-only structs and it doesn't have immutable 
references, but thinking long-term this does seem like a great model to be 
aware of.

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