Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

[Taras Zakharko via swift-evolution]

Is the lack of comments due to general disinterest in such a thing or did my 
mail go amiss somehow? ;)

Best, 

 Taras

> On 31 Mar 2016, at 14:39, Taras Zakharko  wrote:
> 
> Recently, I have been working on implementing some non-trivial data 
> structures in Swift (its about storing polygons in a space-partitioning 
> tree). I am using enums to represent different types of parent nodes and 
> leafs and I had some ideas to make them more fit for this kind of work. I 
> expect that I will write multiple enum-related emails, each one concentrating 
> on one particular feature. A usual disclaimer: these are random, quite rough 
> ideas that might or not make sense, but I’d like to get some feedback  from 
> the community. 
> 
> Case-based dispatch for enum methods
> 
> Often, behaviour of enum method depends on the enum value. For instance, 
> imagine a tree structure with an insert(value:) method: the way how the 
> inserting is handled depends on the type of the node. Usually, you’d 
> implement it as a switch operation:
> 
> func insert(value:T) {
>   switch self {
> case let Leaf1(a, b, c): …
> case let Leaf2(a, b): …
> case let Parent1(x, y): …
>   }
> }
> 
> If the insert operation is non-trivial, this becomes quite convoluted. You 
> can of course define private helper methods or functions that perform the 
> specific functionality, but I don’t find it to be a very satisfying solution: 
> there is still the switch boilerplate + you need to be careful to call the 
> correct helper, so there are some safety issues. 
> 
> Now, suppose there was a way to add a method implementation that is 
> case-specific:
> 
> enum MyTree {
>   case Leaf1(Float, Float) {
> mutating  func insert(value: T) {
>let (a, b) = self.Leaf1 // or something like that
>// handle insert for the case that node is of type Parent1
> 
>...
>  }
>   }
> 
>  case Parent1(Int, Float) {
>  mutating func insert(value: T) {
>let (x, y) = self.Parent1 // or something like that
>// handle insert for the case that node is of type Parent1
>...
>  }
>   }
> 
> default {
>mutating func insert(value: T) {
>   // handle insert for all other cases 
>...
>  }
> }
> }
> 
> etc. The case method specification needs to be exhaustive and adhere to the 
> same signature. It is a compile-time error to specify a method or property 
> only in some cases but not in the other ones (that is why we have the default 
> implementation). Outer scope definitions apply to all cases and cannot be 
> overridden by a case-specific implementation. 
> 
> Basically, the compiler would synthesise an outer-scope method that does a 
> switch operator to dispatch to the particular implementation. This is thus 
> mostly syntactic sugar which also promotes safety (as it becomes impossible 
> to call the wrong implementation). These would make the case-specific methods 
> fully compatible with protocols etc. (e.g. a protocol Insertable { mutating 
> func insert(value:) }
> 
> Looking forward to your thoughts on this!
> 
> Best, 
> 
>  Taras
> 
> 

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Thorsten Seitz via swift-evolution]

> Am 05.04.2016 um 01:52 schrieb Dany St-Amant via swift-evolution 
> :.
> 
> I am with you here, Swift is Swift, C is C, Swift should not be hampered by 
> keeping the syntax identical to C. But, it seems that most prefer to type 
> less, so we should be really careful with proposing new keywords like this 
> 'then' and 'do' as they carry little meaning,  have to be mandatory (as per 
> Chris), and are really needed only for trailing closure which will not be 
> used by everyone.
> 
> So, I'm against adding these 'then' and 'do' keywords for the sake of 
> providing the trailing support to 'if' and 'for'.

FWIW adding 'then' would allow using 'if' as an expression by replacing the 
{...} blocks with expressions. One argument against 'if' expressions was that { 
} are ugly within an expression. So there might be a benefit besides providing 
trailing support.

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

Re: [swift-evolution] [META] Re: Mailman?

[Keith Smiley via swift-evolution]

This can be done by setting up a single server pointing to news.gmane.org. Then
you can search for the swift lists and right click to subscribe.

--
Keith Smiley

On 04/02, Ilya Belenkiy wrote:
> Hi Keith,
>
> can you give some more details on how to do this? I'd love to use Unison
> for this, but I have no idea how to set this up. Any help is greatly
> appreciated.
>
> --
> Ilya
>
> On Wed, Mar 9, 2016 at 1:47 PM Keith Smiley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> > For those who are just interested in getting these conversations out of
> > their
> > email in the meantime, you can use the nntp bridge at
> >
> > http://news.gmane.org/gmane.comp.lang.swift.evolution/
> >
> > Along with Panic's retired Unison app
> >
> > https://panic.com/blog/the-future-of-unison/
> >
> > As a pretty good GUI for this.
> >
> > --
> > Keith Smiley
> >
> > On 03/09, James Campbell via swift-evolution wrote:
> > > They are listening but they keep saying they don't have the resources.
> > So I
> > > would encourage them to let the community give back and set something up
> > !
> > >
> > > *___*
> > >
> > > *James⎥Head of Trolls*
> > >
> > > *ja...@supmenow.com ⎥supmenow.com <
> > http://supmenow.com>*
> > >
> > > *Sup*
> > >
> > > *Runway East *
> > >
> > > *10 Finsbury Square*
> > >
> > > *London*
> > >
> > > * EC2A 1AF *
> > >
> > > On Wed, Mar 9, 2016 at 6:28 PM, David Hart via swift-evolution <
> > > swift-evolution@swift.org> wrote:
> > >
> > > > +1000
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On 09 Mar 2016, at 11:34, Adrian Kashivskyy via swift-evolution <
> > > > swift-evolution@swift.org> wrote:
> > > >
> > > > I'm a very big supporter of moving the discussions to a Discourse forum
> > > > installation. Here are my arguments:
> > > >
> > > >
> > > >1. *Subscribing to interesting threads*
> > > >In the mailing list, it is not possible to subscribe to a thread
> > > >unless the mail client supports it. In a forum, you can subscribe
> > to a
> > > >thread and you may even turn on email notifications.
> > > >2. *Muting uninteresting threads*
> > > >Unless the mail client is supporting it (many don't) – it's not
> > > >possible to mute a thread – all emails are equally important.
> > > >3. *Searching*
> > > >It is way easier to search an indexed forum like Discourse, than
> > > >searching through 12k emails
> > > >4. *Message formatting*
> > > >We tend to include many code examples and formatted text in our
> > > >messages. Some of us tend to create markdown files on the side and
> > then
> > > >paste the generated HTML into an email body. Discourse supports
> > > >mix-and-match of Markdown, HTML and BBEdit.
> > > >5. *Tags*
> > > >In the mailing list, most of us tend to include [tags] in the mail
> > > >subjects, but some folks forget or ignore them. Discourse allows to
> > > >predefine tags for the threads which improves indexing and
> > searching even
> > > >more.
> > > >6. *Pinned threads*
> > > >Announcements of e.g. ongoing reviews may take a form of pinned
> > > >threads so they are immediately visible to forum members.
> > > >7. *The problem of replying to a thread with a changed subject*
> > > >Sometimes users reply to threads but accidentally add a tag or a
> > > >whitespace to the message subject. Most mail client interpret it as
> > a new
> > > >thread and such a reply may be lost in the wild. Replies to
> > coherent forum
> > > >threads are never lost, they're always in the right place.
> > > >8. *Accessibility*
> > > >Even if your mailing client allows all of the above features,
> > > >sometimes it is needed to access the forums from a phone or on a
> > university
> > > >computer, where many functionalities are blocked. Although it is
> > possible
> > > >to access the webmail page in the browser, it is most often painful
> > to
> > > >navigate through archives (especially on icloud.com ¯\_(ツ)_/¯).
> > When
> > > >using Discourse, all above features are available everywhere.
> > > >9. *Permanent links*
> > > >To share a link to a Discourse discussion, you just copy it from the
> > > >browser URL field. To share a link to a mailing list reply, you
> > need to
> > > >open the web archive, find the topic manually and then copy the URL
> > from
> > > >the browser field anyway.
> > > >10. *Mentioning other users*
> > > >In mailing list, this is achievable by including the target user in
> > a
> > > >recipients list. In forum, you just @mention someone, just like in
> > GitHub
> > > >issues.
> > > >11. *Privacy*
> > > >Some users don't want their private emails to be disclosed in a
> > > >mailing list. In a forum like Discourse, you can choose whether
> > your email
> > > >is displayed publicly or not.
> > > >
> > > >
> > > > I can actually go 

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Russ Bishop via swift-evolution]

> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
> 
> There are a number of things I'm not really clear on.
> 
> * * *
> 
> Consider this Objective-C API:
> 
>   ObjCFizzer* myFizzer;
> 
> Which of these represents how it is imported?
> 
>   var myFizzer: ObjCFizzer
>   var myFizzer: Fizzer

The latter. The idea is that the importer sees the bridged type is available 
and substitutes it on all imported signatures. The actual mechanics of that 
will involve some generated code (thunk) to call the protocol. I could update 
the proposal to include what the body of that thunk might look like but it 
didn’t seem terribly interesting.

> 
> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this 
> Objective-C API:
> 
>   ObjCMutableFizzer* mutableFizzer;
> 
> Which of these represents how it is imported?
> 
>   var myMutableFizzer: ObjCMutableFizzer
>   var myMutableFizzer: Fizzer

The intention there is that it imports as the bridged type so the latter.


> 
> On the basis of NSArray and friends, I assume they come across like this:
> 
>   var myFizzer: Fizzer
>   var myMutableFizzer: ObjCMutableFizzer
> 
> Is that correct?

No


> 
> * * *
> 
> I assume that you can use casts to implicitly cross the bridge in both 
> directions, even when Objective-C is not involved. That is, you could write 
> something like this:
> 
>   ObjCFizzer() as Fizzer
> 
> Is that correct?
> 
> If you can cross the bridge purely in Swift, does the object type actually 
> have to be @objc? Why?
> 
> If it does not have to be @objc, is this perhaps better thought of as an 
> `ObjectBridgeable` protocol which allows cast-based conversion of any type to 
> an equivalent class, and which also does Objective-C bridging if the class 
> happens to be @objc? (This looser definition might help us if we ever 
> interoperate with other object systems on different platforms.)

In theory you could do this, though it would be a useless waste of CPU cycles :)

My thinking was that we may need similar bridging protocols in some 
hypothetical world where we can import C++ objects but the shape of the 
protocol (and certainly the constraints on the associated type) would be quite 
different.


> 
> * * *
> 
> Suppose you have a value of type `ObjCMutableFizzer`:
> 
>   let mutableFizzer: ObjCMutableFizzer = ...
> 
> Can you write `mutableFizzer as! Fizzer`? In other words, if a type is 
> bridged to a particular class, is it also bridged to its subclasses?
> 
> Based on the examples from Foundation, I suspect the answer is "yes”.

Yes, you can invoke as? or as! casts which will call the respective 
initializers, though the default implementation of unconditional bridging (as!) 
will call the conditional initializer.


> 
> * * *
> 
> Foundation classes can sometimes be bridged using an upcast (a plain `as`), 
> which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? 
> If not, will Foundation classes lose that ability?
> 
> If this feature can't be expressed with ObjectiveCBridgeable, is this seen as 
> a shortcoming we should try to overcome, or the proper design? I worry about 
> the unnecessary proliferation of exclamation points, especially since many 
> style guides strongly discourage them, which will turn this into an 
> unnecessary proliferation of unnecessary `if let`s.

This would not be possible. This sort of bridging only works with special magic 
types because they are known to always succeed. There is no condition under 
which Swift will fail to convert String to NSString. The compiler/runtime can’t 
prove that about any arbitrary type.

For bridging an Objective-C library into Swift, ideally all the APIs will be 
annotated with SWIFT_BRIDGED so on import the Swift code won’t even be aware 
the Objective-C type exists. All you’ll see in Swift is the appropriate Swift 
types. This gives a library (say Photos.framework or UIKit) the chance to 
provide truly native Swift types by shipping a module with combined Swift and 
Objective-C code.

Similarly, going the other direction (an app with Objective-C and Swift code) 
this proposal eliminates the need to deal with the Objective-C types in Swift.

The only situation where casting might be required is interop with things like 
performSelector, context objects, or when SWIFT_BRIDGED annotations are missing.


> 
> * * *
> 
> I'm confused by a statement in the "Ambiguity and Casting" section:
> 
>   2. A Swift type may bridge to an Objective-C base class then provide 
> different subclass instances at runtime, but no other Swift type may bridge 
> to that base class or any of its subclasses.
>   i. The compiler should emit a diagnostic when it detects two 
> Swift types attempting to bridge to the same ObjectiveCType.
> 
> Does this 

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Brent Royal-Gordon via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md

There are a number of things I'm not really clear on.

* * *

Consider this Objective-C API:

ObjCFizzer* myFizzer;

Which of these represents how it is imported?

var myFizzer: ObjCFizzer
var myFizzer: Fizzer

Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this 
Objective-C API:

ObjCMutableFizzer* mutableFizzer;

Which of these represents how it is imported?

var myMutableFizzer: ObjCMutableFizzer
var myMutableFizzer: Fizzer

On the basis of NSArray and friends, I assume they come across like this:

var myFizzer: Fizzer
var myMutableFizzer: ObjCMutableFizzer

Is that correct?

* * *

I assume that you can use casts to implicitly cross the bridge in both 
directions, even when Objective-C is not involved. That is, you could write 
something like this:

ObjCFizzer() as Fizzer

Is that correct?

If you can cross the bridge purely in Swift, does the object type actually have 
to be @objc? Why?

If it does not have to be @objc, is this perhaps better thought of as an 
`ObjectBridgeable` protocol which allows cast-based conversion of any type to 
an equivalent class, and which also does Objective-C bridging if the class 
happens to be @objc? (This looser definition might help us if we ever 
interoperate with other object systems on different platforms.)

* * *

Suppose you have a value of type `ObjCMutableFizzer`:

let mutableFizzer: ObjCMutableFizzer = ...

Can you write `mutableFizzer as! Fizzer`? In other words, if a type is bridged 
to a particular class, is it also bridged to its subclasses?

Based on the examples from Foundation, I suspect the answer is "yes".

* * *

Foundation classes can sometimes be bridged using an upcast (a plain `as`), 
which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? If 
not, will Foundation classes lose that ability?

If this feature can't be expressed with ObjectiveCBridgeable, is this seen as a 
shortcoming we should try to overcome, or the proper design? I worry about the 
unnecessary proliferation of exclamation points, especially since many style 
guides strongly discourage them, which will turn this into an unnecessary 
proliferation of unnecessary `if let`s.

* * *

I'm confused by a statement in the "Ambiguity and Casting" section:

2. A Swift type may bridge to an Objective-C base class then provide 
different subclass instances at runtime, but no other Swift type may bridge to 
that base class or any of its subclasses.
i. The compiler should emit a diagnostic when it detects two 
Swift types attempting to bridge to the same ObjectiveCType.

Does this mean that each bridged class must have exactly one corresponding 
Swift type? Or does it mean that if a bridged type has more than one 
corresponding Swift class, an explicit cast is always needed? Or merely that it 
may sometimes be needed?

There are examples in the frameworks of many types bridging to a single class. 
For instance, a whole hoard of numeric types bridge to NSNumber; Swift handles 
this by exposing Swift types like `[Int]` as `NSArray*`, but doesn't 
do any converting when going in the opposite direction. Is that how this new 
protocol works, or does it do something else? 

* * *

I'm confused by the SWIFT_BRIDGED() macro. Why does it exist? Doesn't the 
ObjectiveCBridgeable conformance provide all the information needed? What 
happens if you don't include it? (Perhaps you get the one-way bridging behavior 
seen with `NSNumber`?)

* * *

The "Resilience" section says:

Adding or removing conformance to ObjectiveCBridgeable, or changing the 
ObjectiveCType is a fragile (breaking) change.

Why is this? In particular, why is adding a conformance a breaking change? That 
isn't the normal rule for protocols.

* * *

Probably a stupid question, but I want to be certain since the example does 
something else: There would not be some kind of circularity problem with 
defining `ObjCFizzer` in terms of `Fizzer`, would there? For instance:

class ObjCFizzer: NSObject {
fileprivate var fizzer: Fizzer

fileprivate init(_ fizzer: Fizzer) {
self.fizzer = fizzer
}

var fizzyString: String? {
guard case .case1(let string) = fizzer else { return 
nil }

return string
}

var fizzyX: Int? {
guard case .case2(let x, _) = fizzer else { return nil }
return x
}

var fizzyY: Int? {
guard case .case2(_, let y) = fizzer else { return nil }
return y
}
}
extension 

Re: [swift-evolution] My personal beef with leading-dot syntax

[T.J. Usiyan via swift-evolution]

*like* types. I, at no point, said that they are types.

Pointing out what they can't do is not a great stance, in my opinion,
because some of those things are perfectly reasonable but simply might not
have been considered or attempted yet. I am *not* arguing that they are
types. I am arguing that they are semantically different from static
members. If they aren't, why not simply give us a means to pattern match
over custom values and call it a day?

My point is that enum are special.

``` swift
enum Boolean {
case True, False
}
```

We could argue that `True` and `False` are just instances of Boolean. I
will argue that you provide no significant state (Void) in either case to
'create' or 'choose' either `True` or `False`. You provide such  a raw
value to `Int`  to create each instance but you do no such thing for an
enum without an associate value. You do, however, provide a significant bit
of state to enums with associated values. Both the case choses AND the
state define identity, which places it between an enum without associated
values and a struct/class/product type

``` swift
enum Optional {
case Some(T)
case None
}
```

Again, I agree that they are not types. I disagree that they are just like
`Int` Each case is a signifier between member value and type.
TJ





On Mon, Apr 4, 2016 at 11:04 PM, Brent Royal-Gordon 
wrote:

> > Because semantically they seem more like types unto themselves
>
> But they aren't types.
>
> * You can't declare a variable/property/parameter of a particular case.
> * You can't constrain a generic type parameter to a case.
> * You can't cast to a case with `as` and friends or test for a case with
> `is`.
> * You can't conform different cases to different protocols.
> * You can't give different cases different members. (The associated value
> tuple is not a member; you can only access it with pattern matching.)
>
> There is nothing subtle or ambiguous about this. Swift does not even blur
> the line anywhere, except in the switch statement (which is full of ad-hoc
> magic) and in the now-corrected capitalization convention. Cases simply
> *are not* types. They are different values which may be stored in the same
> type, just as `Int(1)` and `Int(2)` are not different types.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] My personal beef with leading-dot syntax

[Brent Royal-Gordon via swift-evolution]

> Because semantically they seem more like types unto themselves

But they aren't types.

* You can't declare a variable/property/parameter of a particular case.
* You can't constrain a generic type parameter to a case.
* You can't cast to a case with `as` and friends or test for a case with `is`.
* You can't conform different cases to different protocols.
* You can't give different cases different members. (The associated value tuple 
is not a member; you can only access it with pattern matching.)

There is nothing subtle or ambiguous about this. Swift does not even blur the 
line anywhere, except in the switch statement (which is full of ad-hoc magic) 
and in the now-corrected capitalization convention. Cases simply *are not* 
types. They are different values which may be stored in the same type, just as 
`Int(1)` and `Int(2)` are not different types.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[T.J. Usiyan via swift-evolution]

Because semantically they seem more like types unto themselves–which is why
I disagree with the lower camel casing but I digress–and the fact that they
are static members seems like an implementation detail more than anything
else.

TJ

On Mon, Apr 4, 2016 at 10:15 PM, Joe Groff  wrote:

>
> > On Apr 4, 2016, at 6:27 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Is a solution to this actually making the leading dot mean enum lookup,
> full stop and allowing `Self.foo`? The case that that doesn't cover is
> static members on a type other than `Self`. I use it to great effect for
> standard instances of types, so I would appreciate *some* facility to
> provide that, but it doesn't have to be a leading dot if we can think of a
> way which is less problematic.
> >
> > I am simply spitballing here but would
> > 1 period for enum look up
> > 2 periods for static member lookup
> >
> > or something similar be a solution? It doesn't use another character or
> keyword and it makes it clear which feature is being used.
>
> I don't see any reason for a split here. Enum cases *are* static members,
> they just happen to be the ones people encounter most often.
>
> -Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

On Apr 4, 2016, at 8:13 PM, Joe Groff  wrote:
> On Apr 4, 2016, at 11:17 AM, Erica Sadun  wrote:
>> On Apr 4, 2016, at 12:13 PM, Joe Groff  wrote:
>>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution 
>>>  wrote:
 Are there reasons that prevent using `Self` as a synonym for an instance's 
 type name?
 
 Consider:
 
 struct MyStruct {
   static func foo() { print("foo") }
   func bar() {
   MyStruct.foo() // works
   self.dynamicType.foo() // works
   Self.foo() // error
   }
 }
 
 Obviously, you can always name a type directly or use `self.dynamicType` 
 but
 neither solution does any favors for readability. Both approaches obscure 
 intent, 
 especially as type names grow large: 
 `MyExtremelyLargeTypeName.staticMember`,
 for example. Plus, as Kevin B pointed out to me,  
 `self.dynamicType.classMember`  
 and `TypeName.classMember` may not be synonyms in class types with 
 non-final members.
 
 I'd like to see `Self.staticMember` introduced as a synonym for 
 `TypeName.staticMember`.
>>> 
>>> There's the wrinkle of inheritance, as there so often is. `Self` inside a 
>>> class scope already means "the dynamic class of 'self'", not "the type this 
>>> declaration statically appears within". Now, we really ought to allow you 
>>> to utter Self in the bodies of class methods too. It would be consistent to 
>>> extend that courtesy to value types, where dynamic `Self` always matches 
>>> the static type, from that principle.
>>> 
>>> -Joe
>> 
>> Would using another word or symbol fix that problem?
> 
> My preference would be for there to be only one Self, and have it always be 
> the dynamic type of 'self'. Some people disagree, but I don't think it's all 
> that onerous to have to write ClassName.foo if that's really what you 
> specifically mean.
> 
> -Joe

There's a pleasing simplicity to that approach.

-- E


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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 6:27 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> Is a solution to this actually making the leading dot mean enum lookup, full 
> stop and allowing `Self.foo`? The case that that doesn't cover is static 
> members on a type other than `Self`. I use it to great effect for standard 
> instances of types, so I would appreciate *some* facility to provide that, 
> but it doesn't have to be a leading dot if we can think of a way which is 
> less problematic. 
> 
> I am simply spitballing here but would 
> 1 period for enum look up
> 2 periods for static member lookup
> 
> or something similar be a solution? It doesn't use another character or 
> keyword and it makes it clear which feature is being used.  

I don't see any reason for a split here. Enum cases *are* static members, they 
just happen to be the ones people encounter most often.

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 11:17 AM, Erica Sadun  wrote:
> 
> 
>> On Apr 4, 2016, at 12:13 PM, Joe Groff  wrote:
>> 
>>> 
>>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Are there reasons that prevent using `Self` as a synonym for an instance's 
>>> type name?
>>> 
>>> Consider:
>>> 
>>> struct MyStruct {
>>>static func foo() { print("foo") }
>>>func bar() {
>>>MyStruct.foo() // works
>>>self.dynamicType.foo() // works
>>>Self.foo() // error
>>>}
>>> }
>>> 
>>> Obviously, you can always name a type directly or use `self.dynamicType` but
>>> neither solution does any favors for readability. Both approaches obscure 
>>> intent, 
>>> especially as type names grow large: 
>>> `MyExtremelyLargeTypeName.staticMember`,
>>> for example. Plus, as Kevin B pointed out to me,  
>>> `self.dynamicType.classMember`  
>>> and `TypeName.classMember` may not be synonyms in class types with 
>>> non-final members.
>>> 
>>> I'd like to see `Self.staticMember` introduced as a synonym for 
>>> `TypeName.staticMember`.
>> 
>> There's the wrinkle of inheritance, as there so often is. `Self` inside a 
>> class scope already means "the dynamic class of 'self'", not "the type this 
>> declaration statically appears within". Now, we really ought to allow you to 
>> utter Self in the bodies of class methods too. It would be consistent to 
>> extend that courtesy to value types, where dynamic `Self` always matches the 
>> static type, from that principle.
>> 
>> -Joe
> 
> Would using another word or symbol fix that problem?

My preference would be for there to be only one Self, and have it always be the 
dynamic type of 'self'. Some people disagree, but I don't think it's all that 
onerous to have to write ClassName.foo if that's really what you specifically 
mean.

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Brent Royal-Gordon via swift-evolution]

> Are there reasons that prevent using `Self` as a synonym for an instance's 
> type name?
> 
> Consider:
> 
> struct MyStruct {
> static func foo() { print("foo") }
> func bar() {
> MyStruct.foo() // works
> self.dynamicType.foo() // works
> Self.foo() // error
> }
> }
> 
> Obviously, you can always name a type directly or use `self.dynamicType` but
> neither solution does any favors for readability. Both approaches obscure 
> intent, 
> especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
> for example. Plus, as Kevin B pointed out to me,  
> `self.dynamicType.classMember`  
> and `TypeName.classMember` may not be synonyms in class types with non-final 
> members.
> 
> I'd like to see `Self.staticMember` introduced as a synonym for 
> `TypeName.staticMember`.
> 
> Thoughts?

I'm kind of struggling with how best to design this. Here's the most coherent 
design I've been able to come up with so far.

* Adopt the proposal to no longer require `.self` on types to get the type 
instance. Using a type name in expression context gives you the type instance.
* Every variable `foo` has a typealias attached to it, `foo.Self`. This is the 
static (compile-time declared or inferred) type of that instance. You can use 
it anywhere you can use a type name, including in declarations. If it's used in 
an expression, it becomes the type instance of the variable's static type.
* Every variable `foo` has a special typealias attached to it, 
`foo.DynamicSelf`. This is the dynamic (runtime assigned) type of that 
instance. In theory you can use it anywhere you can use a type name, though in 
practice there are probably significant limitations. If it's used an 
expression, it become the type instance of the variable's dynamic type.
* A bare `Self` or `DynamicSelf` is a shorthand for `self.Self` or 
`self.DynamicSelf`.

`DynamicSelf` subsumes the roles of both the old `Self` and `dynamicType`. 
`Self` is both an alias for the declared type and a way to get its type 
instance.

This gives us a number of new abilities:

Self.classMember()  // Instead of 
ReallyLongClassName.classMember()
foo.Self.classMember()  // Likewise, but for a 
different variable

let self2: Self // Match the static 
type of self
let foo2: foo.Self  // Match the static 
type of a different variable

DynamicSelf.classMember()   // Instead of 
self.dynamicType.classMember()
foo.DynamicSelf.classMember()   // Likewise

let self3: DynamicSelf  // Match the dynamic type of 
self
let foo3: foo.DynamicSelf   // Match the dynamic type of a 
different variable
// (Those would probably require certain restrictions, like the base 
variable has to be 
// immutable and the assignment has to come from a function returning a 
DynamicSelf
// derived from `self`/`foo`.)

// Make promises about matching dynamic types of parameters besides 
`self`:
func tenMinutesAfter(date: NSDate) -> date.DynamicSelf {
return date.adding(10 * 60) // Note that `adding(_: 
NSTimeInterval)` returns DynamicSelf
}

// Possible alternative to generic syntax:
func removingCommonPrefix(_ one: Collection, _ two: Collection) -> 
(one.Self.SubSequence, two.Self.SubSequence) where one.Self.Element == 
two.Self.Element, one.Self.Element: Equatable {
for (oneIndex, twoIndex) in zip(one.indices + [one.endIndex], 
two.indices + [two.endIndex]) {
if oneIndex == one.endIndex || twoIndex == two.endIndex 
|| one[oneIndex] != two[twoIndex] {
return (one.suffixFrom(oneIndex), 
two.suffixFrom(twoIndex))
}
}
fatalError("Can't get here")
}

The only disadvantage I see to this approach is that code which currently uses 
`Self` will be longer. But there may be other problems as well. I'm not 
entirely sure I have a good handle on the existing `Self` vs. `dynamicType`; 
it's possible the connection I see between them is spurious or ill-defined.

By the way, an alternative would be to leave the dynamic type as `Self` and 
call the static type `Type`, which I *think* would generalize the existing 
notion of the metatype being accessible as `Type`. In other words:

Type.classMember()  // Instead of 
ReallyLongClassName.classMember()
foo.Type.classMember()  // Likewise, but for a 
different variable

let self2: Type // Match the static 
type of self
let foo2: foo.Type  // Match the static 
type of a different variable

Self.classMember()   

Re: [swift-evolution] My personal beef with leading-dot syntax

[T.J. Usiyan via swift-evolution]

Is a solution to this actually making the leading dot mean enum lookup,
full stop and allowing `Self.foo`? The case that that doesn't cover is
static members on a type other than `Self`. I use it to great effect for
standard instances of types, so I would appreciate *some* facility to
provide that, but it doesn't have to be a leading dot if we can think of a
way which is less problematic.

I am simply spitballing here but would
1 period for enum look up
2 periods for static member lookup

or something similar be a solution? It doesn't use another character or
keyword and it makes it clear which feature is being used.

TJ

On Mon, Apr 4, 2016 at 4:22 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> Moving away from the compiler, I like the leading dot for the programmer
> to distinguish static and instance members. The 'missing' receiver natural
> means static to me.
>
>
> On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> on Mon Apr 04 2016, Joe Groff  wrote:
>>
>> >> On Apr 4, 2016, at 12:51 PM, Dave Abrahams 
>> wrote:
>> >>
>> >>
>> >> on Mon Apr 04 2016, Joe Groff  wrote:
>> >>
>> >
>>  On Apr 4, 2016, at 11:44 AM, Dave Abrahams 
>> wrote:
>> 
>> 
>>  on Mon Apr 04 2016, Joe Groff  wrote:
>> 
>> >>>
>> >> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>
>> >> on Mon Apr 04 2016, Erica Sadun  asked:
>> >>
>> >
>> >>> Can you ping me off-list or in another thread and explain what the
>> >>> issues are?
>> >>
>> >> All of the following make me uncomfortable with our leading-dot
>> thang:
>> >>
>> >> * The rules for lookup don't seem obvious to me.  I admit this is
>> very
>> >> personal/subjective.
>> >>
>> >> * There is some evidence that people think it means something it
>> doesn't
>> >> (“enum case”), as mentioned in SE-0036.  That suggests it is a
>> >> confusing feature.  That confusion may be fairly harmless so far,
>> but
>> >> still.
>> >>
>> >> * The dot doesn't seem to buy enough to be worth the complexity it
>> adds
>> >> to the language; why not just let those names be looked up without
>> the
>> >> dot?  You can always disambiguate with full qualification if you
>> have
>> >> to.
>> >
>> > Making every unqualified reference context-dependent would be
>> > impractical. `foo.bar(bas)` would become an exponential search to
>> find
>> > a contextual type containing a `foo` which has a `bar` member that
>> can
>> > accept an type containing a `bas` member.
>> 
>>  I don't think I'm talking about making every unqualified reference
>>  context-dependent.  When I have a context that demands an instance
>> of a
>>  particular enum type, I think it's reasonable to look up the names in
>>  the enum without qualification, and I strongly question the value of
>>  leading-dot syntax for general static member lookup.
>> >>>
>> >>> Therein lies the rub—*any* context an unqualified name can appear in
>> >>> could potentially demand an instance of a particular enum type, until
>> >>> the type checker rules that out. Limiting the behavior to enums
>> >>> doesn't simplify the implementation.
>> >>
>> >> I'm afraid I don't understand how that's a serious problem yet.
>> >
>> > Right now, we limit the contextual lookup to places where it's
>> > syntactically asked for, using the leading dot. Without the leading
>> > dot, we'd have to extend it to every unqualified name, which makes it
>> > much more likely you'll fall into problematic cases.
>>
>> I don't know how to evaluate whether that likelihood is a problem in
>> practice, or not, though.
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> --
> -- Howard.
>
> ___
> 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] My personal beef with leading-dot syntax

[David Waite via swift-evolution]

I believe the confusion comes from language references only using the leading 
dot to access enumerated values, and not to access an option set implementation 
or something like UIColor.

I can’t speak to the compiler processing impact or language impact of potential 
conflicts of looking these up without the leading dot. I can see how it would 
be confusing for people to have a very terse syntax for looking up static 
members on *other* types, and expecting either that same terse syntax or 
something comparable for referring to static members on their *own* type. Such 
syntax would have to tread softly on distinguishing static vs dynamic type 
resolution for looking up said members.

-DW


> On Apr 4, 2016, at 12:05 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> * There is some evidence that people think it means something it doesn't
>  (“enum case”), as mentioned in SE-0036.  That suggests it is a
>  confusing feature.  That confusion may be fairly harmless so far, but
>  still.
> 
> * The dot doesn't seem to buy enough to be worth the complexity it adds
>  to the language; why not just let those names be looked up without the
>  dot?  You can always disambiguate with full qualification if you have
>  to.
> 
> * Static members generally are too verbose to access from within members
>  of a type (`Self.x` doesn't work; you have to write out
>  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
>  so. If we're going to have a special syntax for accessing static
>  members, it should *at least* solve this problem.

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

Re: [swift-evolution] [Manifesto] Completing Generics

[Russ Bishop via swift-evolution]

> On Mar 2, 2016, at 5:22 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> Removing unnecessary restrictions
> 
> Concrete same-type requirements
> 
> Currently, a constrained extension cannot use a same-type constraint to make 
> a type parameter equivalent to a concrete type. For example:
> 
> extension Array where Element == String {
>   func makeSentence() -> String {
> // uppercase first string, concatenate with spaces, add a period, whatever
>   }
> }
> 
> This is a highly-requested feature that fits into the existing syntax and 
> semantics. Note that one could imagine introducing new syntax, e.g., 
> extending “Array”, which gets into new-feature territory: see the 
> section on “Parameterized extensions”.

Seems useful.


> 
> Parameterizing other declarations
> 
> 
> Parameterized extensions
> 
> Extensions themselves could be parameterized, which would allow some 
> structural pattern matching on types. For example, this would permit one to 
> extend an array of optional values, e.g.,
> 
> extension Array where Element == T? {
>   var someValues: [T] {
> var result = [T]()
> for opt in self {
>   if let value = opt { result.append(value) }
> }
>return result
>   }
> }
> 
> We can generalize this to a protocol extensions:
> 
> extension Sequence where Element == T? {
>   var someValues: [T] {
> var result = [T]()
> for opt in self {
>   if let value = opt { result.append(value) }
> }
>return result
>   }
> }

This would be fantastic. I’ve run into it a number of times.



> 
> Minor extensions
> 
> There are a number of minor extensions we can make to the generics system 
> that don’t fundamentally change what one can express in Swift, but which can 
> improve its expressivity.
> 
> *Arbitrary requirements in protocols
> 
> Currently, a new protocol can inherit from other protocols, introduce new 
> associated types, and add new conformance constraints to associated types (by 
> redeclaring an associated type from an inherited protocol). However, one 
> cannot express more general constraints. Building on the example from 
> “Recursive protocol constraints”, we really want the element type of a 
> Sequence’s SubSequence to be the same as the element type of the Sequence, 
> e.g.,
> 
> protocol Sequence {
>   associatedtype Iterator : IteratorProtocol
>   …
>   associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == 
> Iterator.Element
> }
> 
> Hanging the where clause off the associated type is protocol not ideal, but 
> that’s a discussion for another thread.

Definitely run into this one before.


> 
> 
> Default generic arguments 
> 
> Generic parameters could be given the ability to provide default arguments, 
> which would be used in cases where the type argument is not specified and 
> type inference could not determine the type argument. For example:
> 
> public final class Promise { … }
> 
> func getRandomPromise() -> Promise { … }
> 
> var p1: Promise = …
> var p2: Promise = p1 // okay: p1 and p2 have the same type 
> Promise
> var p3: Promise = getRandomPromise() // p3 has type Promise ErrorProtocol> due to type inference
> 

Also quite useful in eliminating boilerplate.


> 
> Generalized “class” constraints
> 
> The “class” constraint can currently only be used for defining protocols. We 
> could generalize it to associated type and type parameter declarations, e.g.,
> 
> protocol P {
>   associatedtype A : class
> }
> 
> func foo(t: T) { }
> 
> As part of this, the magical AnyObject protocol could be replaced with an 
> existential with a class bound, so that it becomes a typealias:
> 
> typealias AnyObject = protocol
> 
> See the “Existentials” section, particularly “Generalized existentials”, for 
> more information.

Another +1. 


> 
> Major extensions to the generics model
> 
> Unlike the minor extensions, major extensions to the generics model provide 
> more expressivity in the Swift generics system and, generally, have a much 
> more significant design and implementation cost.
> 
> 
> *Conditional conformances
> 
> 

This one seems extremely important and has immediate utility IMHO.


> 
> Syntactic improvements
> 
> 
> 
> Maybe
> 
> 
> Higher-kinded types
> 
> Higher-kinded types allow one to express the relationship between two 
> different specializations of the same nominal type within a protocol. For 
> example, if we think of the Self type in a protocol as really being 
> “Self”, it allows us to talk about the relationship between “Self” and 
> “Self” for some other type U. For example, it could allow the “map” 
> operation on a collection to return a collection of the same kind but with a 
> different operation, e.g.,
> 
> let intArray: Array = …
> intArray.map { String($0) } // produces Array
> let intSet: Set = …
> intSet.map { String($0) }   // produces Set
> 
> 
> Potential syntax borrowed 

Re: [swift-evolution] [Proposal]Add support for extension variables

[David Waite via swift-evolution]

Such a feature would require limitations, yes. For a strawman, what would be 
the resulting system behavior if someone had a use case to add a string unit 
identifier to all numeric values?

At a minimum:
- every number in the system now would take more space
- you would be unable to redefine the comparison operator (all else being the 
same) to account for this new unit identifier
- if redefinition was possible, comparisons for this type are now more complex 
and more computationally expensive.

A more typical example - adding a flag to all Strings to indicate whether or 
not they have been pre-sanitized for use in XML/JSON/SQL/etc (such as in Ruby 
on Rails)

-DW

> On Apr 4, 2016, at 3:49 PM, Haravikk via swift-evolution 
>  wrote:
> 
> There was a proposal for this a little while ago, what you’re looking for are 
> mixins, though I’m not sure they would solve your problem either.
> 
> The reason this can’t be done as part of an extension is that there are only 
> really two ways to implement it:
> 
> Expand the Type: Basically the new data has to be added to the type somehow. 
> For example, a struct of four Ints is about 32 bytes, to add a stored 
> property you’d need to increase that. This could be fine if it’s internal to 
> a module, as it can be computed in advance, but if you’re extending an 
> imported type (as in your case) then this isn’t ideal as your version of 
> UITextFields would be a different from the size expected by other libraries 
> that don’t know about your extension, which would mean that some kind of 
> transformation is required between your version of UITextFields and any other 
> variation of it that you need to work with; not impossible, but not the 
> nicest thing to have to do and potentially not great for performance.
> 
> Lookup Added Properties: I believe this is exactly what you’re doing with 
> your workaround; namely your added properties are being stored separately and 
> associated to an instance so that they can be looked up/changed without 
> touching the size of the original. However, this kind of lookup isn’t great 
> for performance either.
> 
> So both options would have to trade performance for stored property style 
> syntax, which IMO would not be a great thing to do as it would hide what’s 
> going on behind the scenes to make it work. Maybe if we had some kind of 
> Swiftier methods for doing either option explicitly that might be okay, since 
> it could give simpler means that explicitly expose the performance impact, 
> but APIs designed to handle type-erased wrappers shouldn’t need anything like 
> this. Of course that’s no comfort when dealing with APIs that do, especially 
> legacy ones, but you’ve found a workaround that seems to do what you need, 
> and there may be other options (can’t think of any just now).
> 
> Anyway, that’s the gist of the problem as I understand it, hope some of that 
> helps to fill in why it’s not a straightforward thing to address.
> 
>> On 4 Apr 2016, at 11:00, Yogev Sitton via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> I try to avoid using inheritance for just adding functionality - for that I 
>> use (and love) extensions.
>> This works great for functions - but I find the lack for stored properties 
>> support limiting.
>> 
>> Here’s my use case:
>> I want to map every textfield in my view controller to a JSON field - so it 
>> would be very helpful to add a string Key property to all of the 
>> UITextFields in my app.
>> For now this is how I solve this issue (inside the extension):
>> 
>> struct customProperties {
>>  static var key : String?
>> }
>> 
>> var key : String? {
>>  get {
>>  return objc_getAssociatedObject(self, ) 
>> as? String
>>  }
>>  set (value){
>>  
>> objc_setAssociatedObject(self,,value,.OBJC_ASSOCIATION_RETAIN_NONATOMIC)
>>  }
>> }
>> 
>> I would love to just add an actual variable to the extension without the 
>> need to use Obj-C associated objects.
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

> On Apr 4, 2016, at 7:01 PM, Jonathan Tang  wrote:
> 
> I assume that the @available annotation generated would also work for 
> watchOS, tvOS, etc. frameworks.

Yes

> How would it work for non-iOS Swift platforms?  I'm not terribly familiar 
> with how #available works on Linux, but the versioning problem exists there 
> too.

In my experience, "linux" cannot be listed inside @available.  I think we need 
to add it.

I'm not sure the "version" of Linux is meaningful (e.g. - interpreted as kernel 
version? glibc?) but I think clearly "linux" the vaguely-versioned platform 
should be allowed in an @availability attribute.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Jonathan Tang via swift-evolution]

+1 to this.  It's really important for getting a sane third-party library
ecosystem working.

I assume that the @available annotation generated would also work for
watchOS, tvOS, etc. frameworks.  How would it work for non-iOS Swift
platforms?  I'm not terribly familiar with how #available works on Linux,
but the versioning problem exists there too.

On Mon, Apr 4, 2016 at 4:48 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> Suppose **Apple** ships a framework that is only supported in iOS 9.3.
> As a direct consequence, the framework is only #available in iOS 9.3 or
> later.
>
> Suppose Jane links this framework into her iOS application.  The
> deployment target for her application *can be any value*.  She sets the
> framework to be weakly linked, and as long as the code that uses the Apple
> framework is guarded by a 9.3 availability check, she can deploy back to
> 8.0, 7.0, etc.
>
> Suppose *I* ship a custom framework that I only want to bother supporting
> for iOS 9.3 users.  I'm not testing on old OS, I don't have CI on old OS,
> and quite frankly I have no idea if it works.  And I'm not in the habit of
> shipping code that wasn't even tested on my machine.  As a direct
> consequence, I set my framework deployment target to 9.3.
>
> Now Jane links this framework into her "deployment target 8.0"
> application.  She weakly links it and uses availability checks just like
> she did with the Apple framework.  But this time the compiler says no:
>
> error: module file's minimum deployment target is ios9.3 v9.3
>
>
> Jane now has a set of bad choices:
>
> 1.  She can not use my framework at all
> 2.  She can drop support for <9.3 entirely from her application in order
> to use my framework
> 3.  She can convince me to support iOS 8, when I don't want to invest in
> the QA and test time.
> 4.  She can convince me to set my deployment target to 8, try to find all
> my public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I
> didn't miss any.  Spoiler alert: that's what I did all afternoon.
>
> This is too hard.  IMO Jane should be able to use my "9.3+" frameworks as
> easily as she can use Apple's.
>
> IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0"
> application, it should A) import successfully, B) link weakly, and C) have
> `@availability(9.3, *)` overlayed on the interface.
>
> There may be some subtle additional details because I don't know exactly
> the implementation of these features, but that's the general idea.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Dany St-Amant via swift-evolution]

> Le 4 avr. 2016 à 10:19, Patrick Gili  a écrit :
> 
> If I understand you correctly, you think adding keywords represents an 
> inconsistency.

I didn't write that, maybe I should have put my reply between your two 
paragraphs. Adding keywords such as 'then' and 'do' could add some consistency, 
but another word than 'do' will likely have to be found as 'do' could break 
code as highlighted by Xiaodi, as well as cause by the 'catch' case caught by 
Jeremy.

I was merely highlighting the current inconsistency of the variable scope of 
'guard let' versus 'if let' which no one had mentioned so far... An 
inconsistency which is (logically) fully design intent and will remain forever. 
So some inconsistencies are acceptable, 

Is accepting trailing closure in 'guard' really a new inconsistency?
Being unable to use them with 'guard', 'if', 'switch' is the original 
inconsistency as the trailing closure seemed to be use in many places 
(including argument list of another function). Adding 'guard' as a location 
where trailing closure are allowed doesn't really introduce a new 
inconsistency, it just incompletely reduce an existing inconsistency.

> However, I think it would add considerable consistency and utility to the 
> Swift language. Yes, it would make it inconsistent with the generations of 
> C-like languages that have come before it. However, I think we've already 
> taken considerable steps from away from C-like languages; for example, 
> removing C-like for-loop syntax and unary increment/decrement operators.

I am with you here, Swift is Swift, C is C, Swift should not be hampered by 
keeping the syntax identical to C. But, it seems that most prefer to type less, 
so we should be really careful with proposing new keywords like this 'then' and 
'do' as they carry little meaning,  have to be mandatory (as per Chris), and 
are really needed only for trailing closure which will not be used by everyone.

So, I'm against adding these 'then' and 'do' keywords for the sake of providing 
the trailing support to 'if' and 'for'. And I do not see why we should prevent 
'guard' from gaining this support just because the 'if' and 'for' doesn't also 
have it.

Dany
 
> 
>> On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution 
>>  wrote:
>> 
>> 
>> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution 
>>  a écrit :
>> 
 What is your evaluation of the proposal?
>>> I think there is a lot of value to allowing trailing closures in the guard 
>>> condition clause. However, not at the cost of inconsistency. We have 
>>> reviewed many proposals over the last month that addressed consistency 
>>> issues in the Swift language, and if I'm not mistaken, all of them have 
>>> been accepted by the community, larger to eliminate the inconsistency.
>>> 
>>> Because of this, I think two of the alternatives stated by the proposal 
>>> have credibility:
>>> 1) Eliminate the "else" keyword from the guard syntax.
>>> 2) Add keywords to "if", "while", "for", and "switch" to delineate the 
>>> condition clause from the body of the statement.
>>> 
>>> The second alternative has more appeal, because it supports trailing 
>>> closures without "heroics".
>> 
>> It have been mentioned multiple times that allowing trailing closure only 
>> for guard is creating an inconsistency, but these keywords already are 
>> inconsistent with the each other (beside the presence of the 'trailing' else 
>> keyword) on the variable scoping:
>> 
>> - guard let: outer scope immutable variable
>> - if let: inner scope immutable variable
>> - for: inner scope immutable variable without let keyword
>> 
>> Consistency is good, but since each keywords are not for the exact same 
>> thing, it is normal to see some variances.  Like the global scope of the 
>> immutable variable created by guard; as per the intent of the keyword, or 
>> its trailing else keyword; needed to clarify that what follow is for, for 
>> lack of better word, the 'else' case.
>> 
>> So as long as such inconsistency have a "raison d'être", that they have been 
>> designed and are not an oversight; there should be no reason to not allow 
>> them.
>> 
>> Dany
>> 
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> No.
>>> 
 Does this proposal fit well with the feel and direction of Swift?
>>> No. Please don't add inconsistencies to the language, as we're just going 
>>> to have to deal with it down the road.
>>> 
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
>>> Not in my experience.
>>> 
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
>>> 
>>> In-depth study.
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

[swift-evolution] deployment targets and frameworks

[Drew Crawford via swift-evolution]

Suppose *Apple* ships a framework that is only supported in iOS 9.3.  As a 
direct consequence, the framework is only #available in iOS 9.3 or later.

Suppose Jane links this framework into her iOS application.  The deployment 
target for her application *can be any value*.  She sets the framework to be 
weakly linked, and as long as the code that uses the Apple framework is guarded 
by a 9.3 availability check, she can deploy back to 8.0, 7.0, etc.

Suppose *I* ship a custom framework that I only want to bother supporting for 
iOS 9.3 users.  I'm not testing on old OS, I don't have CI on old OS, and quite 
frankly I have no idea if it works.  And I'm not in the habit of shipping code 
that wasn't even tested on my machine.  As a direct consequence, I set my 
framework deployment target to 9.3.

Now Jane links this framework into her "deployment target 8.0" application.  
She weakly links it and uses availability checks just like she did with the 
Apple framework.  But this time the compiler says no:

error: module file's minimum deployment target is ios9.3 v9.3

Jane now has a set of bad choices:

1.  She can not use my framework at all
2.  She can drop support for <9.3 entirely from her application in order to use 
my framework
3.  She can convince me to support iOS 8, when I don't want to invest in the QA 
and test time.
4.  She can convince me to set my deployment target to 8, try to find all my 
public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I didn't 
miss any.  Spoiler alert: that's what I did all afternoon.

This is too hard.  IMO Jane should be able to use my "9.3+" frameworks as 
easily as she can use Apple's.

IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0" application, it 
should A) import successfully, B) link weakly, and C) have `@availability(9.3, 
*)` overlayed on the interface.

There may be some subtle additional details because I don't know exactly the 
implementation of these features, but that's the general idea.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-proposal/Idea] Auto-generate Type-Erased Wrappers

[Russ Bishop via swift-evolution]

> On Apr 4, 2016, at 3:07 PM, Haravikk via swift-evolution 
>  wrote:
> 
> One of the things that threw me when starting with Swift was the inability to 
> use many protocols as types, e.g- being unable to declare: [SequenceType], 
> instead having to do: [AnySequence]
> 
> And I guess it got me wondering; why can’t we just have these be 
> auto-generated and used where we would expect a protocol to fit? Writing 
> type-erased wrappers currently involves a lot of boilerplate, especially for 
> a type with a lot of methods and/or properties, so automating this would be 
> very useful.
> 
> For me there are two good options:
> 
> Autogenerate for All Types: As it says; every protocol would have an 
> identically named type-erasure (with the same visibility etc.) that Swift 
> would just swap in where appropriate. For example:
> 
>   protocol Foo { … }
>   let myArray:[Foo]   // Array of type-erased wrappers of Foo

The only reason you can’t use [Foo] is due to associated type or Self 
requirements so what type is Foo’s associated type(s) here? 


> 
> 
> I’m particularly curious about other features in discussion or that are 
> upcoming that may affect this, as I’m sure I’ll have missed some. Anything 
> that might render this obsolete (or less necessary)? Also whether anyone 
> thinks it could be a bad idea to essentially hide the type-erasure.
> 

The Completing Generics manifesto discusses this in the context of Existential 
types. If that were supported, then the compiler would just treat the 
associated types as Any. It also discusses allowing you to create types ala 
protocol


Russ

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Brent Royal-Gordon via swift-evolution]

> When I have a context that demands an instance of a
> particular enum type, I think it's reasonable to look up the names in
> the enum without qualification, and I strongly question the value of
> leading-dot syntax for general static member lookup.  I would normally
> never think of using it that way—because, guess what? I think of
> leading-dot as a notation for enums like everybody else does—and I don't
> think there are any important idioms it supports, that couldn't be
> equally well handled by something like `Self.x` if we were allowed to
> use it.

Well, sure, they don't know that leading dot is more widely usable—"The Swift 
Programming Language" only mentions it in connection with enums. But once 
people know, they're very glad to use it.

I've introduced several different people to the joys of universal leading-dot 
syntax, and I would characterize their reaction as *pleasant* surprise. They 
immediately start using the syntax for things like `.blackColor()` and 
`.passRetained(_:)` and `.min`, and often expand their usage beyond that. Now 
that unbound methods are uncurried, a small tweak to the leading dot syntax in 
function context will also open us up to things like 
`views.forEach(.removeFromSuperview)`. Lens functions may also eventually be 
used in this way. 

If the feature is underused, that's because it's poorly explained, not because 
it's not widely desired.

(Besides, you probably at least use the syntax for option sets, which are 
enum-like but not enums.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[James Hillhouse via swift-evolution]

Hi Doug,

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. Swift needs strong Set API’s that play nicey-nicey with the API Guidelines 
and this proposal is a firm effort in that direction.

> Does this proposal fit well with the feel and direction of Swift?
Yes. This proposal takes nouns that have no commonly used verb form and forms 
them into verbs, e.g. ‘union’ into ‘formUnion’. It may not look especially 
pretty to some, but is effective.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
While not languages, the proposal provides SetAlgebra API that is at least as 
understandable as Mathematica and much more so than Matlab. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve been following this discussion since it’s inception back in…what, early 
February? I have read the API’s and diff’s. Many times.

> On Apr 1, 2016, at 12:14 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs 
> Accordingly" begins now and runs through April 5, 2016. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.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. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> 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] [Proposal] Custom operators

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

Apr 5, 2016, Maximilian Hünenberger wrote:

>
> Am 04.04.2016 um 08:06 schrieb Антон Жилин  >:
>
> Is it OK to have "less, equal, greater" in precedence name?
>
> What do you mean by OK? Other operators like == are weird:
>
> precedence(== == <)
> // in comparison to
> precedence(== equalTo <)
>

I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
Maybe:

associativity(left)
precedence(lessThan: +)
precedence(equalTo: +)

It also solves my concern about dictionary inside braces.

After thinking more about it I came to the conclusion that we should have
> something like "precedence groups" where all operators have the same
> precedence:
>
> precedenceGroup Additive {
> +, -
> }
>
> precedenceGroup Multiplicative {
> *, /
> }
>
> precedence(Additive lessThan Multiplicative)
>
> infix operator +- {
> associativity: left
> }
>
> extension Additive {
> +-, -+, ++, --
> }
>

Precedence groups have a great benefit of additional symmetry. Transitive
precedence propagation, on the other hand, also has benefits:

1. It does not introduce new entities, just some rules for compiler
2. It does not add new keywords. In your current wording, we have to take
precedence and precedenceGroup as keywords, that's why I
originally preferred directives
3. We actually think in terms of operators, not groups.
If I want to say that my operator should have the same priority as `+`, I'd
rather say that I want it to have priority of plus and minus, not "belong
to multiplicative group".
If I declare <$> and want it to have same priority as <*>, it would be more
difficult to invent some name for their group like FunctorManipulator.

On the other hand, in your solution you have a list of global rules
and don't really need braces. How about this?

#precedenceGroup(Additive)
#precedenceGroup(Multiplicative)
#precedence(Additive, less, Multiplicative)
#operator(+, infix, associativity: left, group: Additive)
#operator(*, infix, associativity: left, group: Multiplicative)
#operator(<>, infix)

So precedence group is just a tag that can be used in precedence rules and
assigned to operators at declaration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Hi Taras

I’ve watched the WWDC15 video about Swift compiler optimization, read some more
in depth material about it. It is probably advanced in many aspects of 
optimization.
So, you might be correct to assume that the compiler can optimize
>  for(int i = x0; i In case I didn’t explain my reasoning clear enough, here is another attempt. 
> Swift already has a very powerful, compact tool that offers a strict superset 
> of the iteration semantics.
That is not (yet) the case, let alone a superset!

> I simply see no purpose into making the language more verbose and complicated 
> for no particular gain.

It doesn’t make the language more complicated, rather, the reverse is true.
If you want a less verbose language, learn APL, or J.
APL proves unintentionally the inverse relation between “verbose”and 
“complicated” :o) 

> What you do is argue for having two different syntactic styles for 
> accomplishing exactly the same thing,
> simply on the grounds of your personal dislike of one of them. 
It is not at all personal dislike, it is many years of die-hard experience 
with a multitude of programming languages and systems.
I don’t think in emotional terms about programming constructs but
solely about practical implications, usefulness, reliably and so on.

I assume this difference of opinion will remain...

 -
Coincidentally, today John Heerema, described here on swift-evolution 
exactly my point of view on these matters based on facts. 
read his text please. Thank you.
 -
I hope I am not too unfriendly here, Nothing personal. 
If I am in Zürich again it would be nice to discuss this with a beer. 
Although not so far from here, currently my finances prevent this.

Kind regards
Ted
www.ravelnotes.com

  == The problem is not what you add to a programming language
  == but what you remove!
  








> On 31.03.2016, at 14:59, Taras Zakharko  wrote:
> 
> 
>> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen  wrote:
>> 
>> Alas, I don’t understand you irritation, 
>> but it is your irritation, not mine.
> 
> Well, its quite simple: we are having a discussion here. You are claiming 
> that the collection-based iteration is inherently slower than a classical 
> numerical loop. This is incorrect. I have even sent around some C code that 
> uses different abstractions and shown that it compiles to the same machine 
> code. Yet you are consistently ignoring this. 
> 
>> Please note again, that “for ... in …”  always has 
>> some sort of collection type as its argument..
>> At run time, the content of a collection 
>> is in most cases unpredictable.
> 
> Again, incorrect. The simple collections that are relevant to this discussion 
> are based on trivial iterators that 

[swift-evolution] [Pre-proposal/Idea] Auto-generate Type-Erased Wrappers

[Haravikk via swift-evolution]

One of the things that threw me when starting with Swift was the inability to 
use many protocols as types, e.g- being unable to declare: [SequenceType], 
instead having to do: [AnySequence]

And I guess it got me wondering; why can’t we just have these be auto-generated 
and used where we would expect a protocol to fit? Writing type-erased wrappers 
currently involves a lot of boilerplate, especially for a type with a lot of 
methods and/or properties, so automating this would be very useful.

For me there are two good options:

Autogenerate for All Types: As it says; every protocol would have an 
identically named type-erasure (with the same visibility etc.) that Swift would 
just swap in where appropriate. For example:

protocol Foo { … }
let myArray:[Foo]   // Array of type-erased wrappers of Foo

Autogenerate by Attribute: Same basic idea, except that an attribute would be 
required to specify which protocols get automatic type-erasure like so:

@autoErasure protocol Foo { … }
let myArray:[Foo]   // Array of type-erased wrappers of Foo


I’m curious for people’s thoughts on the matter. I know that I for one am tired 
of defining type-erased wrappers that are just a heap of boiler-plate to 
properly wrap an instance. It’s also something I’ve seen people doing wrong 
(and done wrong myself), for example by using closures to invoke methods on an 
instance; this is a much more elegant looking solution but very quickly bloats 
the size of the type-erased wrapper compared to more correct boxing method 
(though for single method protocols it may be fine). It seems like something 
that would be good to take out of the hands of developers who mostly don’t want 
to have to define these in the first place, though of course the capability to 
defining customised versions would remain if anyone actually needs it.

I’m particularly curious about other features in discussion or that are 
upcoming that may affect this, as I’m sure I’ll have missed some. Anything that 
might render this obsolete (or less necessary)? Also whether anyone thinks it 
could be a bad idea to essentially hide the type-erasure.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]Add support for extension variables

[Haravikk via swift-evolution]

There was a proposal for this a little while ago, what you’re looking for are 
mixins, though I’m not sure they would solve your problem either.

The reason this can’t be done as part of an extension is that there are only 
really two ways to implement it:

Expand the Type: Basically the new data has to be added to the type somehow. 
For example, a struct of four Ints is about 32 bytes, to add a stored property 
you’d need to increase that. This could be fine if it’s internal to a module, 
as it can be computed in advance, but if you’re extending an imported type (as 
in your case) then this isn’t ideal as your version of UITextFields would be a 
different from the size expected by other libraries that don’t know about your 
extension, which would mean that some kind of transformation is required 
between your version of UITextFields and any other variation of it that you 
need to work with; not impossible, but not the nicest thing to have to do and 
potentially not great for performance.

Lookup Added Properties: I believe this is exactly what you’re doing with your 
workaround; namely your added properties are being stored separately and 
associated to an instance so that they can be looked up/changed without 
touching the size of the original. However, this kind of lookup isn’t great for 
performance either.

So both options would have to trade performance for stored property style 
syntax, which IMO would not be a great thing to do as it would hide what’s 
going on behind the scenes to make it work. Maybe if we had some kind of 
Swiftier methods for doing either option explicitly that might be okay, since 
it could give simpler means that explicitly expose the performance impact, but 
APIs designed to handle type-erased wrappers shouldn’t need anything like this. 
Of course that’s no comfort when dealing with APIs that do, especially legacy 
ones, but you’ve found a workaround that seems to do what you need, and there 
may be other options (can’t think of any just now).

Anyway, that’s the gist of the problem as I understand it, hope some of that 
helps to fill in why it’s not a straightforward thing to address.

> On 4 Apr 2016, at 11:00, Yogev Sitton via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I try to avoid using inheritance for just adding functionality - for that I 
> use (and love) extensions.
> This works great for functions - but I find the lack for stored properties 
> support limiting.
> 
> Here’s my use case:
> I want to map every textfield in my view controller to a JSON field - so it 
> would be very helpful to add a string Key property to all of the UITextFields 
> in my app.
> For now this is how I solve this issue (inside the extension):
> 
> struct customProperties {
>   static var key : String?
> }
>   
> var key : String? {
>   get {
>   return objc_getAssociatedObject(self, ) 
> as? String
>   }
>   set (value){
>   
> objc_setAssociatedObject(self,,value,.OBJC_ASSOCIATION_RETAIN_NONATOMIC)
>   }
> }
> 
> I would love to just add an actual variable to the extension without the need 
> to use Obj-C associated objects.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Sean Heber  wrote:

> This has been a very long and complex thread, but have some of these
> not-technically-mathy word pairs that have nice verb forms been
> considered:
>
> union -> combine / combining
> intersection -> intersect / intersecting
> symmetricDifference -> split / splitting

Yes, some of them have been considered.

> Example:
>
> var allowedUsers = Set()
> allowedUsers.combine(standardUsers)
> allowedUsers.combine(superUsers)
>
> var users = allUsers
> users.intersect(allowedUsers)
>
> let users = allUsers.intersecting(allowedUsers)
>
> l8r
> Sean
>
>> On Apr 4, 2016, at 3:22 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> Indeed, OED points out that modern usage is "chiefly military." Probably an 
>>> argument against its usage here.
>> 
>> It seems to me that what you're sort of saying is "replaceWith", but
>> that's kind of a mouthful. A quick thesaurus check suggests that the
>> only decent single-world alternative would be "substitute", but that
>> sounds like a regex operation. I think this is a dead end.
>> 
>> -- 
>> 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

-- 
Dave

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

[swift-evolution] [Proposal] Custom operators

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

Sorry for breaking the thread, next time please mail me a copy :)
Link to the proposal:
https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md

1.  I strongly agree that the numeric precedence system is not great. From
> a implementation point of view, the way to specify them in your
> proposal
> essentially gave all visible operators a partial order, in which we can
> draw a directed gragh with operators being the nodes and their relation
> being arcs. A part of the graph might look like: '^' --> '*' --> '+',
> the
> nodes being the math operators. We can tell '*' has a higher precedence
> than '+', '^' has a higher precedence than '*' and '+', by follwing the
> arcs. If one operator is not reachable from another, and vice versa,
> then
> composing these two is illegal. We need to teach the compiler this
> concept.
>

Right, that semantics was actually the main driver of the proposal.

2.  Currently, it's not possible to specify precedence for pre- and postfix
> operators. Chris Lattner has mentioned that the
> following result is not desirable:
> ∆x + y
> … where ∆ has a lower precendence than + while it's required to have no
> space between ∆ and the operand. My understanding is that if spaces
> were
> to be allowed here, parsing such expression without ambiguity is a
> non-trivial challenge. So, will it be possible to specify precedence
> for
> pre/postfix operators under your proposal?
>

No, I currently leave prefix and postfix operators unchanged (apart from
syntax shuffling). I will add this as a future direction.
Prefix and postfix operators would behave the same as infix, but have
higher precedence than any infix operator by default.
This feature, if added, would be non-breaking.


> 3.  It may be a good exercise to work out how would each of the builtin
> operators would be defined with this change and mention it (not the
> entire
> definition, but the fact that it's possible, or reasons why it produces
> any difference) in the proposal.


Operators `is`, `as`, `as?`, `as!`, which are not actually Swift custom
operators (they contain letters), will not participate in this exercise.
(Let's not discuss allowing letters in operators here.)
That being said, great idea. I will add example declarations of standard
library operators.

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

Re: [swift-evolution] [Proposal] Custom operators

[Maximilian Hünenberger via swift-evolution]

Inline

> Am 04.04.2016 um 08:06 schrieb Антон Жилин :
> 
> Thank you for a helpful answer!
> I like the idea of overriding precedence from another module. We won't need 
> to introduce additional keywords or visibility for operators. I will add it 
> to the proposal.
> 
> I assume you mean precedence inside braces of operator, then operator scope 
> makes sense. Self operator could be omit as well, following the idea that we 
> are introducing a new operator and want to compare it to others:
> 
> infix operator * {
> associativity: left
> precedenceLess: ^
> precedenceEqual: /
> precedenceGreater: +
> }
> infix operator / {
> associativity: left
> precedenceLess: ^
> precedenceEqual: *
> precedenceGreater: +
> }
> 
> Equivalent precedence rules would be allowed for symmetry in the operator 
> definitions.
> We would still be able to reopen the scope and add precedence and 
> associativity rules.
> I agree that this scheme has advantage of being a smaller change.
> 
> I'm still concerned about syntax.
> Is it OK to have "less, equal, greater" in precedence name?

What do you mean by OK? Other operators like == are weird:

precedence(== == <)
// in comparison to
precedence(== equalTo <)

> Is it OK to have both curly brackets and dictionary syntax (a precedent, I 
> guess)?

That could be a consistency problem. However I'd like to keep a declaration 
syntax instead of defining operators through compiler directives.

> Is it OK to leave prefix and postfix operators always with empty braces?
> 

I'm fine with that.

> Would it be better to have multiple precedence comparisons at once:
> precedenceGreater: +, -, *, /
> Or one comparison per line will be more readable?
> 
> I will add this to alternatives, but will not swap it with currently stated 
> syntax for now, waiting for some more response.
> 
> What do you think?
> 
> - Anton

After thinking more about it I came to the conclusion that we should have 
something like "precedence groups" where all operators have the same precedence:

precedenceGroup Additive {
+, -
}

precedenceGroup Multiplicative {
*, /
}

// first we could allow an operator to be only
// in one p.Group. Later when we can infer
// precedences we can allow operators to be
// in more than one p.Group (if that is even necessary)


// precedence declaration
precedence(Additive lessThan Multiplicative)

// precedence declarations take
// "precedenceGroup"s and "operator"s.


// It could also work with extensions so you
// can easily insert it in the precedence hierarchy:

infix operator +- {
associativity: left
}

// more operator declarations ...

extension Additive {
+-, -+, ++, --
}

// the syntax I used is highly discussable.
// this should mainly be a concept suggestion.
// I think it allows for greater flexibility since you can define
// operator precedences much easier.

With kind regards
- Maximilian
> 
> 2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger :
>> See inline
>> 
>>> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution 
>>> :
>>> 
>>> There is a problem here of duplicated operators or custom precedence, and 
>>> how that gets passed between modules.
>>> Assume there are three modules, A, B and C. B defines a custom operator **. 
>>> A and C each define a custom operator ++, and their meanings are different 
>>> (though, even if their meanings were the same, I'm not sure if they could 
>>> unify).
>>> 
>>> Module D uses A and B as dependencies and sets a custom precedence on ++ 
>>> and **. Module E uses B and C and has a different precedence on ++ and **. 
>>> You're working on Module F which uses D and E. Which ++ and which 
>>> precedence does F get implicitly?
>>> 
>> 
>> We could allow operator precedence overriding to resolve ambiguity. However 
>> this overriding should only be module internal since it would override the 
>> existing precedences in the other modules.
>> 
>> @AHTOH
>> Why do you use #keyword ?
>> I think defining a operator with
>> 
>> infix operator + {
>>  associativity: left
>> }
>> 
>> is perfectly fine since it is similar to class/struct/enum declaration.
>> 
>> // and it's precedence
>> precedence(+ lessThan *)
>> 
>> Note the missing "," and ":" before and after "lessThan" in order to give 
>> both operators the same importance (minor issue).
>> 
>> I feel that
>> 
>> #precedence(+, lessThan: *)
>> 
>> puts too much importance on the first operator.
>> 
>> Best regards
>> - Maximilian
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Sean Heber via swift-evolution]

This has been a very long and complex thread, but have some of these 
not-technically-mathy word pairs that have nice verb forms been considered:

union -> combine / combining
intersection -> intersect / intersecting
symmetricDifference -> split / splitting

Example:

var allowedUsers = Set()
allowedUsers.combine(standardUsers)
allowedUsers.combine(superUsers)

var users = allUsers
users.intersect(allowedUsers)

let users = allUsers.intersecting(allowedUsers)

l8r
Sean



> On Apr 4, 2016, at 3:22 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Indeed, OED points out that modern usage is "chiefly military." Probably an 
>> argument against its usage here.
> 
> It seems to me that what you're sort of saying is "replaceWith", but that's 
> kind of a mouthful. A quick thesaurus check suggests that the only decent 
> single-world alternative would be "substitute", but that sounds like a regex 
> operation. I think this is a dead end.
> 
> -- 
> 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] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 4, 2016, at 1:39 PM, Howard Lovatt  wrote:
> 
> If the `.StaticMember` (no type name) notation discussed already at least 
> twice, in the context of expanding the `.EnumCase` syntax, was accepted, this 
> would eleviate the problem. 

I was thinking about the syntax a bit further and it seems like the capability 
that would be added is like #file, in that it does some compile-time textual 
replacement. So, perhaps #Self would work?

Also, along these lines, I would find use for call-site interpolation like 
#file has. I could then do a free function version of my property() call that 
was something like:

func property(ownerType: PropertyOwner.Type = #Self, ...) { }

which would only be callable from w/in things conforming to or subclassing 
PropertyOwner.

-tim

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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Howard Lovatt via swift-evolution]

 • What is your evaluation of the proposal?

Good idea, it gets rid of compiler magic

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

Yes, plenty of mixed projects. Plenty of Cocoa libraries that could be
improved with a Swift API.

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

Yes, obj-c is still important

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

No, but have wanted this in Swift

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

Followed discussions on swift-evolution


On Tuesday, 5 April 2016, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of “Allow Swift types to provide custom Objective-C
> representations” begins now and runs through April 11, 2016. The proposal
> is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.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. When replying, please try to keep the proposal link at
> the top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>
> Reply text
>
> Other replies
>
> *What goes into a review?*
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Joe
> Review Manager
>


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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Howard Lovatt via swift-evolution]

If the `.StaticMember` (no type name) notation discussed already at least
twice, in the context of expanding the `.EnumCase` syntax, was accepted,
this would eleviate the problem.

On Tuesday, 5 April 2016, Timothy Wood via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Are there reasons that prevent using `Self` as a synonym for an instance's
> type name?
>
> [...]
>
>
> I'd like to see `Self.staticMember` introduced as a synonym for
> `TypeName.staticMember`.
>
>
> I would love to see a way to get the type of the "enclosing thing at
> compile time”. In my particular case, I’m using the type as a generic
> parameter to tag a created resource with something like:
>
> class Client: PropertyOwner {
> let intProperty = Client.property(“name”, Int(0))
> }
>
>
> where PropertyOwner has a static property(...)
>
> With `Self` meaning the static version of the thing being compiled, I
> could at least write:
>
> class Client: PropertyOwner {
> let intProperty = Self.property(“name”, Int(0))
> }
>
>
> which would have the benefit of being harder to mess up due to
> copy-pasting between different PropertyOwner implementors.
>
> I would love to be able to omit the `Self.` entirely, but instances can’t
> call functions on themselves at init time, and instances don’t see static
> funcs, so that probably won’t fly =)
>
> The particular spelling of ‘static self` doesn’t matter too much to me, so
> if `Self` needs to be the runtime type of the executing class then maybe
> `StaticSelf` could be added.
>
> -tim
>
>

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Brent Royal-Gordon via swift-evolution]

> Indeed, OED points out that modern usage is "chiefly military." Probably an 
> argument against its usage here.

It seems to me that what you're sort of saying is "replaceWith", but that's 
kind of a mouthful. A quick thesaurus check suggests that the only decent 
single-world alternative would be "substitute", but that sounds like a regex 
operation. I think this is a dead end.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Howard Lovatt via swift-evolution]

Moving away from the compiler, I like the leading dot for the programmer to
distinguish static and instance members. The 'missing' receiver natural
means static to me.

On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Apr 04 2016, Joe Groff >
> wrote:
>
> >> On Apr 4, 2016, at 12:51 PM, Dave Abrahams  > wrote:
> >>
> >>
> >> on Mon Apr 04 2016, Joe Groff  wrote:
> >>
> >
>  On Apr 4, 2016, at 11:44 AM, Dave Abrahams  > wrote:
> 
> 
>  on Mon Apr 04 2016, Joe Groff  wrote:
> 
> >>>
> >> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>
> >>
> >> on Mon Apr 04 2016, Erica Sadun  > asked:
> >>
> >
> >>> Can you ping me off-list or in another thread and explain what the
> >>> issues are?
> >>
> >> All of the following make me uncomfortable with our leading-dot
> thang:
> >>
> >> * The rules for lookup don't seem obvious to me.  I admit this is
> very
> >> personal/subjective.
> >>
> >> * There is some evidence that people think it means something it
> doesn't
> >> (“enum case”), as mentioned in SE-0036.  That suggests it is a
> >> confusing feature.  That confusion may be fairly harmless so far,
> but
> >> still.
> >>
> >> * The dot doesn't seem to buy enough to be worth the complexity it
> adds
> >> to the language; why not just let those names be looked up without
> the
> >> dot?  You can always disambiguate with full qualification if you
> have
> >> to.
> >
> > Making every unqualified reference context-dependent would be
> > impractical. `foo.bar(bas)` would become an exponential search to
> find
> > a contextual type containing a `foo` which has a `bar` member that
> can
> > accept an type containing a `bas` member.
> 
>  I don't think I'm talking about making every unqualified reference
>  context-dependent.  When I have a context that demands an instance of
> a
>  particular enum type, I think it's reasonable to look up the names in
>  the enum without qualification, and I strongly question the value of
>  leading-dot syntax for general static member lookup.
> >>>
> >>> Therein lies the rub—*any* context an unqualified name can appear in
> >>> could potentially demand an instance of a particular enum type, until
> >>> the type checker rules that out. Limiting the behavior to enums
> >>> doesn't simplify the implementation.
> >>
> >> I'm afraid I don't understand how that's a serious problem yet.
> >
> > Right now, we limit the contextual lookup to places where it's
> > syntactically asked for, using the leading dot. Without the leading
> > dot, we'd have to extend it to every unqualified name, which makes it
> > much more likely you'll fall into problematic cases.
>
> I don't know how to evaluate whether that likelihood is a problem in
> practice, or not, though.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Joe Groff  wrote:

>> On Apr 4, 2016, at 12:51 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Mon Apr 04 2016, Joe Groff  wrote:
>> 
>
 On Apr 4, 2016, at 11:44 AM, Dave Abrahams  wrote:
 
 
 on Mon Apr 04 2016, Joe Groff  wrote:
 
>>> 
>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Mon Apr 04 2016, Erica Sadun  asked:
>> 
> 
>>> Can you ping me off-list or in another thread and explain what the
>>> issues are?
>> 
>> All of the following make me uncomfortable with our leading-dot thang:
>> 
>> * The rules for lookup don't seem obvious to me.  I admit this is very
>> personal/subjective.
>> 
>> * There is some evidence that people think it means something it doesn't
>> (“enum case”), as mentioned in SE-0036.  That suggests it is a
>> confusing feature.  That confusion may be fairly harmless so far, but
>> still.
>> 
>> * The dot doesn't seem to buy enough to be worth the complexity it adds
>> to the language; why not just let those names be looked up without the
>> dot?  You can always disambiguate with full qualification if you have
>> to.
> 
> Making every unqualified reference context-dependent would be
> impractical. `foo.bar(bas)` would become an exponential search to find
> a contextual type containing a `foo` which has a `bar` member that can
> accept an type containing a `bas` member.
 
 I don't think I'm talking about making every unqualified reference
 context-dependent.  When I have a context that demands an instance of a
 particular enum type, I think it's reasonable to look up the names in
 the enum without qualification, and I strongly question the value of
 leading-dot syntax for general static member lookup.
>>> 
>>> Therein lies the rub—*any* context an unqualified name can appear in
>>> could potentially demand an instance of a particular enum type, until
>>> the type checker rules that out. Limiting the behavior to enums
>>> doesn't simplify the implementation.
>> 
>> I'm afraid I don't understand how that's a serious problem yet.
>
> Right now, we limit the contextual lookup to places where it's
> syntactically asked for, using the leading dot. Without the leading
> dot, we'd have to extend it to every unqualified name, which makes it
> much more likely you'll fall into problematic cases.

I don't know how to evaluate whether that likelihood is a problem in
practice, or not, though.

-- 
Dave

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

[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Brad Hilton via swift-evolution]

The Completing Generics Manifesto suggests a more universal solution with 
generic value parameters which is my vote:
Generic value parameters

Currently, Swift’s generic parameters are always types. One could imagine 
allowing generic parameters that are values, e.g.,

struct MultiArray { // specify the number of dimensions 
to the array
  subscript (indices: Int...) -> T {
get {
  require(indices.count == Dimensions)
  // ...
}
}

A suitably general feature might allow us to express fixed-length array or 
vector types as a standard library component, and perhaps also allow one to 
implement a useful dimensional analysis library. Tackling this feature 
potentially means determining what it is for an expression to be a “constant 
expression” and diving into dependent-typing, hence the “maybe”.

> To better support interfacing with lower level systems, like graphics
> libraries for example, it would be helpful to support the concept of
> contiguous variables. The most common use case for this would be to create
> a Matrix struct that can be passed as data into something like Metal. This
> can be accomplished now, using something like the following:
> 
> Current Option 1:
> 
> struct Matrix2x2 {
> var m00: Float
> var m01: Float
> var m10: Float
> var m11: Float
> }
> 
> OR
> Current Option 2:
> 
> struct Matrix2x2 {
> var m: (Float, Float, Float, Float)
> }
> 
> OR
> Current Option 3:
> 
> struct Matrix2x2 {
> var m: [Float]
> }
> 
> Options 1&2 allow for the compiler to enforce the fixed number of
> elements and also for the data to be easily passed into graphics libraries
> as their memory layout is somewhat predictable using sizeof, strideof, and
> alignof. The downside is that you lose the ability to easily subscript or
> iterate the elements.
> 
> Option 3 does allow subscripting and iteration, but does not at compile
> time enforce a fixed number of elements and is not as easily passed into a
> library that expects to receive the raw data of the matrix.
> 
> 
> Contiguous Variables:
> 
> struct Matrix2x2 {
> var m: Float:2*2
> }
> 
> The variable `m` represents a series of 4 contiguous Float values. The
> specific number of values must be a compile time constant. The only needed
> functionality includes `count`, `subscript`, and iteration. To make things
> easier to implement and to help avoid confusion and more complex
> documentation, multiple dimensions are not allowed. To define multiple
> dimensions you must provide your own ordering by wrapping this type in
> another type and providing a custom subscript implementation. For example:
> 
> struct RowMajorMatrix2x2 {
> var m: Float:2*2
> 
> static let rows = 2
> static let columns = 2
> 
> subscript(row: Int, column: Int) ->Float {
> return m[column * Matrix2x2.rows + row]
> }
> }
> 
> sizeof(Matrix2x2) is 16
> strideof(Matrix2x2) is 16
> 
> m.count is essentially a compile time constant and is not stored with the
> rest of the data but is available and can also be used to do runtime bounds
> checking.
> 
> struct Vector3 {
> var v: Float:3
> }
> 
> sizeof(Vector3) is 12
> strideof(Vector3) is 12
> 
> C code should also now be able to expose data types that contain fixed
> sized arrays within them.
> 
> 
> ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Ilya Belenkiy  wrote:

> I think that it’s very useful (I use it frequently in unit tests). I
> hope that this stays the way it is now.

Seeing some examples with an explanation of how this capability is
important in those examples would be very helpful.

-- 
Dave

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

Re: [swift-evolution] Question about heterogeneous collections

[Dave Abrahams via swift-evolution]

on Fri Apr 01 2016, Maximilian Hünenberger  wrote:

> See inline
>
>> Am 31.03.2016 um 20:14 schrieb Dave Abrahams via swift-evolution 
>> :
>> 
>> 
>>> on Tue Mar 29 2016, Jason Sadler  wrote:
>>> 
>>> Hi folks,
>>> 
>>> I have an issue with using a heterogeneous array of objects conforming
>>> to a protocol - I want to write an extension on Array (or
>>> CollectionType) that applies only when Element : MyProtocol, but I
>>> can’t call methods in that extension from an instance of [MyProtocol]
>>> because "Using ‘MyProtocol' as a concrete type conforming to protocol
>>> ‘MyProtocol' is not supported”
>> 
>> Hint: write your extension so it applies when Element == MyProtocol instead.
>> 
>
> Why don't we also imply `Element == MyProtocol` when using `Element:
> MyProtocol` ?

Because Element == MyProtocol is more restrictive; it doesn't allow
arbitrary types that conform to—but are not—MyProtocol.

>
> Both extensions can have the exact same functions/implementation.
> Am I missing something?
> I currently don't see why we are forced to distinguish between homogeneous 
> and heterogeneous Collections.
>
> Kind regards
> - Maximilian
>
>>> (For more background, my full use case can be seen in this gist: 
>>> https://gist.github.com/sadlerjw/2cc16b4375b02fe7f400)
>>> 
>>> I’ve asked about this on swift-users
>>> (https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160321/001560.html)
>>> and got some good workarounds but no one was able to provide me with
>>> information on any future plans in swift to address this issue -
>>> whether that’s making protocols conform to themselves, or some other
>>> improved approach to heterogeneous collections. I wonder if anyone
>>> here can shed some light on this? (I’m new to the mailing lists,
>>> sorry!)
>> 
>> -- 
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Joe Groff  wrote:

>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Mon Apr 04 2016, Joe Groff  wrote:
>> 
>
 On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
  wrote:
 
 
 on Mon Apr 04 2016, Erica Sadun  asked:
 
>>> 
> Can you ping me off-list or in another thread and explain what the
> issues are?
 
 All of the following make me uncomfortable with our leading-dot thang:
 
 * The rules for lookup don't seem obvious to me.  I admit this is very
 personal/subjective.
 
 * There is some evidence that people think it means something it doesn't
 (“enum case”), as mentioned in SE-0036.  That suggests it is a
 confusing feature.  That confusion may be fairly harmless so far, but
 still.
 
 * The dot doesn't seem to buy enough to be worth the complexity it adds
 to the language; why not just let those names be looked up without the
 dot?  You can always disambiguate with full qualification if you have
 to.
>>> 
>>> Making every unqualified reference context-dependent would be
>>> impractical. `foo.bar(bas)` would become an exponential search to find
>>> a contextual type containing a `foo` which has a `bar` member that can
>>> accept an type containing a `bas` member.
>> 
>> I don't think I'm talking about making every unqualified reference
>> context-dependent.  When I have a context that demands an instance of a
>> particular enum type, I think it's reasonable to look up the names in
>> the enum without qualification, and I strongly question the value of
>> leading-dot syntax for general static member lookup.
>
> Therein lies the rub—*any* context an unqualified name can appear in
> could potentially demand an instance of a particular enum type, until
> the type checker rules that out. Limiting the behavior to enums
> doesn't simplify the implementation.

I'm afraid I don't understand how that's a serious problem yet.

>> I would normally
>> never think of using it that way—because, guess what? I think of
>> leading-dot as a notation for enums like everybody else does—and I don't
>> think there are any important idioms it supports, that couldn't be
>> equally well handled by something like `Self.x` if we were allowed to
>> use it.
>
> Enums are only the most common place where static members of Self type
> appear in numbers, but option sets also do. While this may be a matter
> of taste, being able to refer to `.max`, `.infinity`, `.nan`, or other
> abstract constants of numeric types in a concrete-type-agnostic way
> also seems like a win to me.

Agreed.  Let me ask the question differently: what value does the 
leading `.` provide to the user of the language?

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 12:51 PM, Dave Abrahams  wrote:
> 
> 
> on Mon Apr 04 2016, Joe Groff  wrote:
> 
>>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Mon Apr 04 2016, Joe Groff  wrote:
>>> 
>> 
> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Erica Sadun  asked:
> 
 
>> Can you ping me off-list or in another thread and explain what the
>> issues are?
> 
> All of the following make me uncomfortable with our leading-dot thang:
> 
> * The rules for lookup don't seem obvious to me.  I admit this is very
> personal/subjective.
> 
> * There is some evidence that people think it means something it doesn't
> (“enum case”), as mentioned in SE-0036.  That suggests it is a
> confusing feature.  That confusion may be fairly harmless so far, but
> still.
> 
> * The dot doesn't seem to buy enough to be worth the complexity it adds
> to the language; why not just let those names be looked up without the
> dot?  You can always disambiguate with full qualification if you have
> to.
 
 Making every unqualified reference context-dependent would be
 impractical. `foo.bar(bas)` would become an exponential search to find
 a contextual type containing a `foo` which has a `bar` member that can
 accept an type containing a `bas` member.
>>> 
>>> I don't think I'm talking about making every unqualified reference
>>> context-dependent.  When I have a context that demands an instance of a
>>> particular enum type, I think it's reasonable to look up the names in
>>> the enum without qualification, and I strongly question the value of
>>> leading-dot syntax for general static member lookup.
>> 
>> Therein lies the rub—*any* context an unqualified name can appear in
>> could potentially demand an instance of a particular enum type, until
>> the type checker rules that out. Limiting the behavior to enums
>> doesn't simplify the implementation.
> 
> I'm afraid I don't understand how that's a serious problem yet.

Right now, we limit the contextual lookup to places where it's syntactically 
asked for, using the leading dot. Without the leading dot, we'd have to extend 
it to every unqualified name, which makes it much more likely you'll fall into 
problematic cases.

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

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[Ted F.A. van Gaalen via swift-evolution]

Hello John
I subscribe completely to this point(s) of view!
TedvG



> Date: Sun, 3 Apr 2016 19:25:09 +
> From: John Heerema >
> To: "swift-evolution@swift.org " 
> >
> Subject: Re: [swift-evolution] Revisiting 0004,   0007 etc. - Swift
>   deprecations
> Message-ID:  >
> Content-Type: text/plain; charset="windows-1252"
> 
> Thanks to all those who thoughtfully responded to this post! The folks who 
> responded provided kind thoughts and advice.
> 
> Ross O’Brian asked if I was familiar with the original discussion for 0004 
> and 0007.
> 
> To answer: Yes, I read the discussions several times over a period of a few 
> weeks before writing anything myself. Unless the repo is somehow missing an 
> awful lot of discussion, I would say that both of these proposals received 
> startlingly little discussion at the time. These are very early proposals 
> (numbers 4 and 7), and were conducted before a lot of people (including me) 
> had any idea that feedback was being solicited.
> 
> My thoughts on these deprecations are aimed more at the human side of how 
> developers actually behave, than on the strict “desirability" of the 
> deprecated features.
> 
> Let’s take proposal 0004 – to deprecate the ++ and — operators.
> 
> A few years ago, I’ve have chimed in to say “sure, let’s deprecate those 
> things. += is more general and obvious”. But that’s how those of us who think 
> about orthogonality think.
> 
> On the human side, what do the human being who write code actually do?
> Human beings notoriously do not act in the way we think they “should”.
> 
> Lots of languages, like C, C++, C#, Objective C, Java, etc., already have 
> both the prefix and suffix versions of ++ and --.
> All of those language also allow developers to use += 1. So, each and every 
> one of the millions of people who use those languages already have a choice 
> of using any of:
> a = a + 1
> a += 1, or
> a++
> 
> So an enormous social experiment has already been done, and we can benefit 
> from it, if we are willing. Given that millions of people have already been 
> given the choice of using any of the three forms shown above, what do they 
> actually prefer to use? There are many, many millions of lines of extant code 
> that can be parsed to determine what developers actually use when they are 
> given the choice.
> 
> I’m pretty sure that everyone on this list already knows the answer, and it’s 
> not the choice we might think that all those millions of developers “should” 
> have made. Given a free choice, developers overwhelmingly chose to use ++ and 
> —. They predominately use the suffix version, but the prefix version is also 
> common. If you don’t believe me, it’s easy to find out for yourself. 
> Actually, I would encourage you not to believe me. Please conduct your own 
> experiment if you have access to a significant body of code. At a more 
> personal level, did you have to refactor your own code to eliminate them? Of 
> course it's easy to do, but why didn’t you make the “right” choice in the 
> first place?
> 
> So, why would we deprecate the option that developers overwhelmingly choose 
> to use?
> Is it “for their own good”? Let’s remember that most people resent being told 
> to do something “for their own good”.
> 
> There’s something inside most people’s brains that wants to make other people 
> do something “for their own good”. I’d argue that this applies in spades to 
> language designers. We want to make Swift even better than it already is (and 
> I think that it’s already pretty darn good).  So it’s really tempting to have 
> the compiler enforce doing the right thing.
> 
> But we also want other developers to make a voluntary choice to use Swift, 
> when they could just as easily stick with Objective C, C, Java, or whatever 
> they are using right now. At least, I hope that’s what everyone on this list 
> wants.
> 
> Or do we want just Swift to be the cool language that those of us in the “in” 
> club use, without necessarily wanting other people to join our exclusive 
> little club? The answer to that question affects the discussion.
> 
> Taras Zakharko suggests that Swift isn’t trying to appeal to everyone. 
> Perhaps not, but I hope that it does. We are long overdue for a modern 
> general purpose language that compiles to, and is interoperable with native 
> code. I think that Swift is great enough to be that language.
> 
> If we have already made a particular choice, and we’re used to defending our 
> choice as being the right one, it’s really hard for us to even imagine that 
> we might have made a decision that doesn’t further our eventual goal.  So, 
> what’s the goal for Swift? Is it to be the language that finally takes over 
> from C’s popularity? Or is it to be a specialized 

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

Hey all!

Just updated the proposal with all the recent changes, and you can check it 
here: 
https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
 


Planning on submitting the PR later tonight, so please let me know if you have 
any last minute feedback!
Riley

> On Mar 30, 2016, at 1:35 PM, Jonathan Hull  wrote:
> 
> Probably ‘no' in this proposal to keep things simple.
> 
> Long term, I would like overriding of the factory init to be the mechanism 
> for a post-hoc extendable factory.  Disallowing it now probably makes that 
> easier in the future.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 1:20 PM, Riley Testut > > wrote:
>> 
>> Another point to consider: should factory initializers be able to be 
>> overridden by subclasses? I vote no, just as you can't override convenience 
>> initializers.
>> 
>> On Mar 30, 2016, at 3:50 AM, Jonathan Hull > > wrote:
>> 
>>> Yeah.  I was thinking we would want to mirror the convenience initializer 
>>> syntax, but I am completely ok with this as well.  Honestly this is the 
>>> syntax I first tried to use in convenience inits while learning swift, and 
>>> I would love to see that migrate to something like this.  My only worry 
>>> would be that people would be confused on when to use ClassName() and when 
>>> to use self.init().  Best to choose one and stick with it.
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Mar 30, 2016, at 3:36 AM, Riley Testut > wrote:
 
 If we are to enforce a different type signature for factory initializers 
 vs required/convenience initializers (which would greatly simplify this 
 issue), if I’m understanding correctly, there shouldn’t be a need to be 
 able to “return” self.init(), right? Because you could do this instead:
 
 public class ConcreteBase {
 
private init(type2: InformationToSwitchOn) {
//Default implementation here
}
 
public factory init (type: InformationToSwitchOn) {
if … {
return SpecialSubclass(type)  //Handle a special case 
 with a more efficient implementation
}
return ConcreteBase(type) //Handle the general case with the 
 main class
}
 }
 
 class SpecialSubclass : ConcreteBase {}
 
> On Mar 30, 2016, at 3:30 AM, Jonathan Hull  > wrote:
> 
> Doh!  
> 
> Sorry, typed that up in mail while working on something else at the same 
> time.  We shouldn’t allow an init with the same signature.  self.init() 
> could be called with different parameters.  Trying to call the factory 
> method from the factory method should generate an error.
> 
> We probably also want to disallow having an init with the same signature 
> in subclasses as well (we could pass the same info with different 
> parameter names) as a subclass which doesn’t override it would again be 
> calling the factory method.  Ultimately, I would like to see the ability 
> to override the factory method with the behavior I described earlier… but 
> that is for a later proposal.
> 
> Basically we should be able to return anything which adheres to the type, 
> so we are free to use other initializers on the class/subclasses.
> 
> Thanks,
> Jon
> 
> 
>> On Mar 30, 2016, at 3:10 AM, Riley Testut > > wrote:
>> 
>> Ah, good catch. Would that be confusing as to whether self.init() would 
>> lead to an infinite loop, or call the required initializer? Unlike 
>> convenience initializers, factory initializers might have the same 
>> signature as the required ones.
>> 
>>> On Mar 30, 2016, at 2:52 AM, Jonathan Hull >> > wrote:
>>> 
>>> Agreed.  I would like to see what I was referring to as “stage 1” in 
>>> this proposal, and we can (hopefully) add on a full solution over time. 
>>>  (I just wanted to make sure we considered those cases so we didn’t 
>>> block future improvements)
>>> 
>>> Looking at the proposal, my only contention would be that we should 
>>> also allow self.init() to be called from the factory init (similar to a 
>>> convenience init).  It could still be used with an AbstractBase as 
>>> shown in your example (especially when dealing with protocols), but it 
>>> shouldn’t force us to be abstract in the class case.
>>> 
>>> In other words, we should also be able to do the following:
>>> 
>>> public class ConcreteBase {
>>> 
>>> 

Re: [swift-evolution] My personal beef with leading-dot syntax

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 11:44 AM, Dave Abrahams  wrote:
> 
> 
> on Mon Apr 04 2016, Joe Groff  wrote:
> 
>>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Mon Apr 04 2016, Erica Sadun  asked:
>>> 
>> 
 Can you ping me off-list or in another thread and explain what the
 issues are?
>>> 
>>> All of the following make me uncomfortable with our leading-dot thang:
>>> 
>>> * The rules for lookup don't seem obvious to me.  I admit this is very
>>> personal/subjective.
>>> 
>>> * There is some evidence that people think it means something it doesn't
>>> (“enum case”), as mentioned in SE-0036.  That suggests it is a
>>> confusing feature.  That confusion may be fairly harmless so far, but
>>> still.
>>> 
>>> * The dot doesn't seem to buy enough to be worth the complexity it adds
>>> to the language; why not just let those names be looked up without the
>>> dot?  You can always disambiguate with full qualification if you have
>>> to.
>> 
>> Making every unqualified reference context-dependent would be
>> impractical. `foo.bar(bas)` would become an exponential search to find
>> a contextual type containing a `foo` which has a `bar` member that can
>> accept an type containing a `bas` member.
> 
> I don't think I'm talking about making every unqualified reference
> context-dependent.  When I have a context that demands an instance of a
> particular enum type, I think it's reasonable to look up the names in
> the enum without qualification, and I strongly question the value of
> leading-dot syntax for general static member lookup.

Therein lies the rub—*any* context an unqualified name can appear in could 
potentially demand an instance of a particular enum type, until the type 
checker rules that out. Limiting the behavior to enums doesn't simplify the 
implementation.

> I would normally
> never think of using it that way—because, guess what? I think of
> leading-dot as a notation for enums like everybody else does—and I don't
> think there are any important idioms it supports, that couldn't be
> equally well handled by something like `Self.x` if we were allowed to
> use it.

Enums are only the most common place where static members of Self type appear 
in numbers, but option sets also do. While this may be a matter of taste, being 
able to refer to `.max`, `.infinity`, `.nan`, or other abstract constants of 
numeric types in a concrete-type-agnostic way also seems like a win to me.

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

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 7:54 AM, Ilya Belenkiy  wrote:
> 
> Just to double check: do I need to do anything with the proposal? It sounds 
> like it was decided, and Doug will update the proposal, but I 'd like to make 
> sure that there is nothing to be done on my end.

I’ll handle the update to the proposal, thank you!

- Doug

> 
> On Fri, Apr 1, 2016 at 5:07 PM Ilya Belenkiy  > wrote:
> Great! Glad that we have a decision.
> 
> On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution 
> > wrote:
> On Mar 30, 2016, at 9:22 PM, Chris Lattner  > wrote:
> >
> > I’ve seen a number of concerns on this list about moduleprivate, and how it 
> > penalizes folks who want to explicitly write their access control.  I’ve 
> > come to think that there is yes-another possible path forward here (which I 
> > haven’t seen mentioned so far):
> >
> > public
> > internal
> > fileprivate
> > private
> 
> Hi Everyone,
> 
> Thank you for all of the input.  I know that this was a highly contentious 
> topic, that it is impossible to make everyone happy.  Getting the different 
> inputs and perspectives has been very very useful.
> 
> The core team met to discuss this, and settled on the list above: 
> public/internal/fileprivate/private.  This preserves the benefit of the 
> “fileprivate” concept that we have today in Swift, while aligning the 
> “private” keyword with common expectations of people coming to Swift. This 
> also makes “private" the "safe default” for cases where you don’t think about 
> which one you want to use, and this schema will cause minimal churn for 
> existing Swift code.
> 
> Thank you again for all of the input and discussion!
> 
> -Chris
> 
> btw, to be clear, this is *not* an April 1 joke.
> ___
> 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] My personal beef with leading-dot syntax

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Joe Groff  wrote:

>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Mon Apr 04 2016, Erica Sadun  asked:
>> 
>
>>> Can you ping me off-list or in another thread and explain what the
>>> issues are?
>> 
>> All of the following make me uncomfortable with our leading-dot thang:
>> 
>> * The rules for lookup don't seem obvious to me.  I admit this is very
>>  personal/subjective.
>> 
>> * There is some evidence that people think it means something it doesn't
>>  (“enum case”), as mentioned in SE-0036.  That suggests it is a
>>  confusing feature.  That confusion may be fairly harmless so far, but
>>  still.
>> 
>> * The dot doesn't seem to buy enough to be worth the complexity it adds
>>  to the language; why not just let those names be looked up without the
>>  dot?  You can always disambiguate with full qualification if you have
>>  to.
>
> Making every unqualified reference context-dependent would be
> impractical. `foo.bar(bas)` would become an exponential search to find
> a contextual type containing a `foo` which has a `bar` member that can
> accept an type containing a `bas` member.

I don't think I'm talking about making every unqualified reference
context-dependent.  When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup.  I would normally
never think of using it that way—because, guess what? I think of
leading-dot as a notation for enums like everybody else does—and I don't
think there are any important idioms it supports, that couldn't be
equally well handled by something like `Self.x` if we were allowed to
use it.


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

[swift-evolution] [Proposal]Add support for extension variables

[Yogev Sitton via swift-evolution]

Hi,

I try to avoid using inheritance for just adding functionality - for that I use 
(and love) extensions.
This works great for functions - but I find the lack for stored properties 
support limiting.

Here’s my use case:
I want to map every textfield in my view controller to a JSON field - so it 
would be very helpful to add a string Key property to all of the UITextFields 
in my app.
For now this is how I solve this issue (inside the extension):

struct customProperties {
static var key : String?
}

var key : String? {
get {
return objc_getAssociatedObject(self, ) 
as? String
}
set (value){

objc_setAssociatedObject(self,,value,.OBJC_ASSOCIATION_RETAIN_NONATOMIC)
}
}

I would love to just add an actual variable to the extension without the need 
to use Obj-C associated objects.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Sat Apr 02 2016, Xiaodi Wu  wrote:

> All righty, here's a proof-of-concept for non-error-accumulating
> stride based on the swift-3-indexing-model branch. I tried to
> incorporate the feedback received in the interim. Namely:
>
> 1. Only floating point types get this slightly more computationally
> intensive "new" stride; all other types get the "classic" stride. If
> accepted, this new code could be appended to Stride.swift and exist
> alongside current code, which doesn't need to be modified.
>
> 2. Based on discussions about UnsafePointer, etc., it dawned on me
> that what really determines whether a StrideTo accumulates error
> isn't T but rather T.Stride, so based on Dave's insights above we get
> "new stride" if T.Stride == FloatingPoint.
>
> 3. I need to multiply floating point values, and if I understand
> correctly multiplication will be guaranteed by a revised SignedNumber
> protocol; for now, I've used a _FloatingPointStrideable protocol as a
> workaround. Note that Float80 doesn't conform to FloatingPoint, so it
> isn't retroactively modeled to conform to _FloatingPointStrideable.
> Nothing's lost for the moment because we can't use Float80 values for
> "new stride" anyway, since it doesn't currently implement the isNormal
> property (see below for why I use that property).
>
> 4. I considered Dave's suggestion whether we could avoid introducing
> new types, instead modifying the existing StrideToIterator and
> StrideThroughIterator and relying on compiler optimization to turn
> "new" stride into "classic" stride for StrideTo, etc.; however,
> because the differences between "classic" stride and "new" stride
> extend beyond the iterator's next() method (see below), I thought it
> best to keep the floating point logic in distinct types.
>
> 5. One difference discussed was how to handle edge cases involving
> lots of iterations; I incorporated Howard's suggestions here, so
> whether a stride requires more than Int.max steps is tested
> upfront--as a consequence, infinite loops are impossible. I would love
> it if, as Thorsten suggests, we could use BigInts, but of course
> there's no such type in the stdlib and adding one would have to be
> another discussion altogether.
>
> 6. The stride increment can't be zero; for a floating point type, it
> also obviously can't be infinity or NaN. I'm inclined to think that
> subnormal increments should be out of the question as well, so my
> proposed streamlined criterion is simply `stride.isNormal`. Comments
> on this are welcome...
>
> Not included:
> 1. I know Ranges are in flux, so I've held off on extending Range with
> a striding(by:) method in this proof-of-concept.

They're not in flux, except for not having been reviewed yet; they are
settled in the swift-3-indexing-model branch.

> 2. No attempt at the suggested stride(from:to:steps:) quite yet.

#1 and #2 are mutually exclusive; we prefer #1 as it removes questions
about the meaning of "to" or "through."

> 2. No tests written yet for this proof-of-concept; I noticed that
> there's a stub for testing strides with bounds of type Double, but
> there's a comment about things not being ready because Double conforms
> to RandomIndexType--not sure what to make of that.  

Comments in that branch are badly out-of-date.  It's worth trying that,
especially since there is no RandomAccessIndexType in that branch any
longer.

> 3. Haven't gotten around to testing performance.
>
> On Wed, Mar 30, 2016 at 12:03 PM, Erica Sadun  wrote:
>>
>> On Mar 29, 2016, at 11:26 PM, Xiaodi Wu via swift-evolution
>>  wrote:
>>
>> On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams  wrote:
>>
>>
>> on Tue Mar 29 2016, Xiaodi Wu  wrote:
>>
>> Relatedly, while you're tackling this big revision:
>>
>> I've tried to play around with what it would take to write a generic
>> non-error-accumulating striding method, and afaict, it would be
>> enormously cleaner if Strideable types are guaranteed to have + and *
>> (well, Strideable.Stride needs *, to be more accurate),
>>
>>
>> That should happen automatically, since it conforms to SignedNumber,
>> when we get the Integer protocols updated (project currently on hold while
>> we land this other revision).
>>
>> since the iterator needs to be able to compute end = start + iteration
>> * stride.
>>
>>
>> Don't you need division too if you're going to do this?
>>
>>
>> I didn't seem to ever need division. See attached playground (which
>> borrows shamelessly from existing code and Erica's proposal, and which
>> is written in Swift 2.2 because that's what I had handy).
>>
>>
>> Have you considered trying to extend the `swift-3-indexing-model` branch
>> at the Swift repo to take the floating point approach into account? Dave A
>> is working on a massive overhaul of ranges (including `Countable` items
>> and one would presume floating point closed and open intervals as well),
>> and I'd love to see better implementations 

Re: [swift-evolution] [Proposal] Custom operators

[Daniel Duan via swift-evolution]

> Антон Жилин via swift-evolution  writes:

> 
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.


I have a few thoughts and a question regarding precedence:

1.  I strongly agree that the numeric precedence system is not great. From
a implementation point of view, the way to specify them in your proposal
essentially gave all visible operators a partial order, in which we can
draw a directed gragh with operators being the nodes and their relation
being arcs. A part of the graph might look like: '^' --> '*' --> '+', the
nodes being the math operators. We can tell '*' has a higher precedence
than '+', '^' has a higher precedence than '*' and '+', by follwing the
arcs. If one operator is not reachable from another, and vice versa, then
composing these two is illegal. We need to teach the compiler this concept.

2.  Currently, it's not possible to specify precedence for pre- and postfix
operators. Chris Lattner has mentioned that the
following result is not desirable:

∆x + y

… where ∆ has a lower precendence than + while it's required to have no
space between ∆ and the operand. My understanding is that if spaces were
to be allowed here, parsing such expression without ambiguity is a
non-trivial challenge. So, will it be possible to specify precedence for
pre/postfix operators under your proposal?

3.  It may be a good exercise to work out how would each of the builtin
operators would be defined with this change and mention it (not the entire
definition, but the fact that it's possible, or reasons why it produces
any difference) in the proposal.

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Timothy Wood via swift-evolution]

> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Are there reasons that prevent using `Self` as a synonym for an instance's 
> type name?
> 
[...]
> 
> I'd like to see `Self.staticMember` introduced as a synonym for 
> `TypeName.staticMember`.

I would love to see a way to get the type of the "enclosing thing at compile 
time”. In my particular case, I’m using the type as a generic parameter to tag 
a created resource with something like:

class Client: PropertyOwner {
let intProperty = Client.property(“name”, Int(0))
}

where PropertyOwner has a static property(...)

With `Self` meaning the static version of the thing being compiled, I could at 
least write:

class Client: PropertyOwner {
let intProperty = Self.property(“name”, Int(0))
}

which would have the benefit of being harder to mess up due to copy-pasting 
between different PropertyOwner implementors.

I would love to be able to omit the `Self.` entirely, but instances can’t call 
functions on themselves at init time, and instances don’t see static funcs, so 
that probably won’t fly =)

The particular spelling of ‘static self` doesn’t matter too much to me, so if 
`Self` needs to be the runtime type of the executing class then maybe 
`StaticSelf` could be added.

-tim

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

> On Apr 4, 2016, at 12:13 PM, Joe Groff  wrote:
> 
>> 
>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Are there reasons that prevent using `Self` as a synonym for an instance's 
>> type name?
>> 
>> Consider:
>> 
>> struct MyStruct {
>>static func foo() { print("foo") }
>>func bar() {
>>MyStruct.foo() // works
>>self.dynamicType.foo() // works
>>Self.foo() // error
>>}
>> }
>> 
>> Obviously, you can always name a type directly or use `self.dynamicType` but
>> neither solution does any favors for readability. Both approaches obscure 
>> intent, 
>> especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
>> for example. Plus, as Kevin B pointed out to me,  
>> `self.dynamicType.classMember`  
>> and `TypeName.classMember` may not be synonyms in class types with non-final 
>> members.
>> 
>> I'd like to see `Self.staticMember` introduced as a synonym for 
>> `TypeName.staticMember`.
> 
> There's the wrinkle of inheritance, as there so often is. `Self` inside a 
> class scope already means "the dynamic class of 'self'", not "the type this 
> declaration statically appears within". Now, we really ought to allow you to 
> utter Self in the bodies of class methods too. It would be consistent to 
> extend that courtesy to value types, where dynamic `Self` always matches the 
> static type, from that principle.
> 
> -Joe

Would using another word or symbol fix that problem?

-- E

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Erica Sadun  asked:
> 
>> Can you ping me off-list or in another thread and explain what the
>> issues are?
> 
> All of the following make me uncomfortable with our leading-dot thang:
> 
> * The rules for lookup don't seem obvious to me.  I admit this is very
>  personal/subjective.
> 
> * There is some evidence that people think it means something it doesn't
>  (“enum case”), as mentioned in SE-0036.  That suggests it is a
>  confusing feature.  That confusion may be fairly harmless so far, but
>  still.
> 
> * The dot doesn't seem to buy enough to be worth the complexity it adds
>  to the language; why not just let those names be looked up without the
>  dot?  You can always disambiguate with full qualification if you have
>  to.

Making every unqualified reference context-dependent would be impractical. 
`foo.bar(bas)` would become an exponential search to find a contextual type 
containing a `foo` which has a `bar` member that can accept an type containing 
a `bas` member.

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

Re: [swift-evolution] My personal beef with leading-dot syntax

[Erica Sadun via swift-evolution]

> On Apr 4, 2016, at 12:05 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 04 2016, Erica Sadun  asked:
> 
>> Can you ping me off-list or in another thread and explain what the
>> issues are?
> 
> All of the following make me uncomfortable with our leading-dot thang:
> 
> * The rules for lookup don't seem obvious to me.  I admit this is very
>  personal/subjective.

Indeed.

> * There is some evidence that people think it means something it doesn't
>  (“enum case”), as mentioned in SE-0036.  That suggests it is a
>  confusing feature.  That confusion may be fairly harmless so far, but
>  still.

Noted.

> * The dot doesn't seem to buy enough to be worth the complexity it adds
>  to the language; why not just let those names be looked up without the
>  dot?  You can always disambiguate with full qualification if you have
>  to.

I kind of like the enumeration looking like an enumeration but I get your point.

> * Static members generally are too verbose to access from within members
>  of a type (`Self.x` doesn't work; you have to write out
>  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
>  so. If we're going to have a special syntax for accessing static
>  members, it should *at least* solve this problem.
> 

Just happened to start a thread a little while ago:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708 


-- E


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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Joe Groff via swift-evolution]

> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Are there reasons that prevent using `Self` as a synonym for an instance's 
> type name?
> 
> Consider:
> 
> struct MyStruct {
> static func foo() { print("foo") }
> func bar() {
> MyStruct.foo() // works
> self.dynamicType.foo() // works
> Self.foo() // error
> }
> }
> 
> Obviously, you can always name a type directly or use `self.dynamicType` but
> neither solution does any favors for readability. Both approaches obscure 
> intent, 
> especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
> for example. Plus, as Kevin B pointed out to me,  
> `self.dynamicType.classMember`  
> and `TypeName.classMember` may not be synonyms in class types with non-final 
> members.
> 
> I'd like to see `Self.staticMember` introduced as a synonym for 
> `TypeName.staticMember`.

There's the wrinkle of inheritance, as there so often is. `Self` inside a class 
scope already means "the dynamic class of 'self'", not "the type this 
declaration statically appears within". Now, we really ought to allow you to 
utter Self in the bodies of class methods too. It would be consistent to extend 
that courtesy to value types, where dynamic `Self` always matches the static 
type, from that principle.

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Sean Heber via swift-evolution]

I’ve wondered this as well. Using “self.dynamicType” is noisy and somewhat 
esoteric, and using “MyStruct.foo” is bad the moment you want to rename 
“MyStruct”.

l8r
Sean


> On Apr 4, 2016, at 1:00 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Are there reasons that prevent using `Self` as a synonym for an instance's 
> type name?
> 
> Consider:
> 
> struct MyStruct {
> static func foo() { print("foo") }
> func bar() {
> MyStruct.foo() // works
> self.dynamicType.foo() // works
> Self.foo() // error
> }
> }
> 
> Obviously, you can always name a type directly or use `self.dynamicType` but
> neither solution does any favors for readability. Both approaches obscure 
> intent, 
> especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
> for example. Plus, as Kevin B pointed out to me,  
> `self.dynamicType.classMember`  
> and `TypeName.classMember` may not be synonyms in class types with non-final 
> members.
> 
> I'd like to see `Self.staticMember` introduced as a synonym for 
> `TypeName.staticMember`.
> 
> Thoughts?
> 
> -- E
> 
> 
> 
> ___
> 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] My personal beef with leading-dot syntax

[Dave Abrahams via swift-evolution]

on Mon Apr 04 2016, Erica Sadun  asked:

> Can you ping me off-list or in another thread and explain what the
> issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me.  I admit this is very
  personal/subjective.

* There is some evidence that people think it means something it doesn't
  (“enum case”), as mentioned in SE-0036.  That suggests it is a
  confusing feature.  That confusion may be fairly harmless so far, but
  still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
  to the language; why not just let those names be looked up without the
  dot?  You can always disambiguate with full qualification if you have
  to.

* Static members generally are too verbose to access from within members
  of a type (`Self.x` doesn't work; you have to write out
  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
  so. If we're going to have a special syntax for accessing static
  members, it should *at least* solve this problem.

-- 
Dave

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

[swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Erica Sadun via swift-evolution]

Are there reasons that prevent using `Self` as a synonym for an instance's type 
name?

Consider:

struct MyStruct {
static func foo() { print("foo") }
func bar() {
MyStruct.foo() // works
self.dynamicType.foo() // works
Self.foo() // error
}
}

Obviously, you can always name a type directly or use `self.dynamicType` but
neither solution does any favors for readability. Both approaches obscure 
intent, 
especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
for example. Plus, as Kevin B pointed out to me,  
`self.dynamicType.classMember`  
and `TypeName.classMember` may not be synonyms in class types with non-final 
members.

I'd like to see `Self.staticMember` introduced as a synonym for 
`TypeName.staticMember`.

Thoughts?

-- E



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

[swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Joe Groff via swift-evolution]

Hello Swift community,

The review of “Allow Swift types to provide custom Objective-C representations” 
begins now and runs through April 11, 2016. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.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. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:


https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md

Reply text

Other replies

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

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

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

[Max Howell via swift-evolution]

> This is a very welcome addition. Thanks!
> 
> A nitpicky detail: I’d prefer the format for the lock file to be yaml or toml 
> over json, since those read a little easier in git diffs (which is, in my 
> experience with cocoapods lockfiles, the only place I ever interact with the 
> lockfiles contents).

Probably we could do TOML.

I picked JSON because it is a more familiar and more widely supported (by 
tools) format.

YAML would be more work since we have no available YAML parser.

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 9:20 AM, Xiaodi Wu  wrote:
> 
> Hmm, "emplace" looks like more or less a synonym for "install." I
> don't think it suggests that the object is being put in place of the
> subject.

It’s roughly a synonym. “emplaceUnion” is "putting the union into position". 
There is no other position than “self”.

> The latest example in the Oxford English Dictionary, from
> 2010, is:
> "Insurgents would hastily emplace victim-activated IEDs...after
> Pathfinder came through."
> Here, the IEDs are not taking the place of the insurgents.

I was going to comment about your choice of a terrorism-related example 
sentence, but the online OED *only* uses war-related examples for this verb.

- Doug

> 
> On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution
>  wrote:
>> 
>> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
>> 
>> 
>> 
>> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  wrote:
>>> 
>>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution
>>>  wrote:
 
> What is your evaluation of the proposal?
 
 I don't like "form" as a prefix. To me there is no difference between
 `union` and `formUnion`: both sounds functional-style, and actually the
 second one perhaps a bit more to my ears. There's basically two dictionary
 definitions of "form":
 
 1. "bring together parts or combine to create (something)" which to me
 implies a new value is created, and
 2. "make or fashion into a certain shape or form" which would imply that
 the material you start with is transformed, which is apparently the 
 intended
 meaning and also the reverse meaning from the above.
 
 I mean, doesn't this make sense as an API?
 
let donut = baker.formDonut(dough) // non-mutating
 
 Perhaps instead of "form" we could use "become" as a prefix when the
 operation is naturally described by a noun. That would seem less ambiguous
 to me:
 
a.becomeUnion(b)
a.becomeIntersection(b)
a.becomeSuccessor(b)
 
 It's a bit passive, but I find it fits well when the operation is a noun.
 
 And there's no way the term lends itself to non-mutating cases without
 things becoming nonsensical:
 
let donut = baker.becomeDonut(dough) // non-mutating?
>>> 
>>> 
>>> I also am having difficulty coming to terms with the use of "form" (I am a
>>> native English speaker). As you note "form" can imply the creation of
>>> something from parts (more like assembling a new thing) as well as the
>>> creation of something out of a material say a of block clay (more like
>>> molding something out of an existing thing). It doesn't seem clear cut to me
>>> to imply in place mutation.
>>> 
>>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>>> type of issue is generally true with any short word made up of the same set
>>> of letters (made worse since "from" is more common in programming then
>>> "form"). The mind quickly narrows in on a set of possible words given the
>>> letters we see and then uses context to help get the correct one and/or
>>> additional visual parsing to understand the exact ordering of letters (more
>>> energy expended). Anyway since I keep seeing "from" instead of "form" I keep
>>> going in the direction of thinking it returns something made from the two
>>> (or more) items involved (not really sure why "from" goes that direction in
>>> my head, it could also go the in place direction).
>>> 
>>> I would prefer something other then "form" (note I just typed "from" by
>>> mistake)... I think your suggestion of "become" has merit.
>>> 
>>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
>>> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
>>> y.formIntersection(x) --read to me as--> "y from oops... y forming an
>>> intersection with x"
>> 
>> 
>> After stepping away for a bit and looking at it from the POV of the API of
>> Set and not in the context of "y" I could read things in the abstract as...
>> 
>> "becomeUnion(with other:Self)" --> "I become a union with other"
>> "formUnion(with other:Self)" --> "I form a union with other"
>> 
>> No clear winner to me however when used in code "become" still feels more
>> strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)
>> 
>> All in all the API would have mutating in front of it (at least for structs)
>> and it wouldn't have a return type. It would become clear fairly quickly as
>> a result (hence learned).
>> 
>> Just still not that happy with "form" but with use my mind would likely
>> quickly adapt.
>> 
>> 
>> I think the best English verb for this construction is “emplace”:
>> 
>> http://www.dictionary.com/browse/emplace

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Douglas Gregor via swift-evolution]

> On Apr 1, 2016, at 5:37 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Protocol requirements with default (no-op) implementations already satisfy 
>> that design goal, no?
> 
> Kind of. If I may steelman* optional members for a moment...
> 
> In cases where a default implementation would do, the default implementation 
> will usually also be the behavior you want for a nil instance, but there's no 
> convenient way to share logic between the two. For example, consider this:
> 
>   protocol UITableViewDelegate {
>   ...
>   func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
>   }
>   extension UITableViewDelegate {
>   func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
>   return tableView.rowHeight
>   }
>   }
>   
>   class UITableView {
>   ...
>   private func addRow(at indexPath: NSIndexPath) {
>   ...
>   cell.size.height = delegate?.tableView(self, 
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>   ...
>   }
>   ...
> 
> You have to duplicate the default logic both in the default implementation 
> and at the call site, but there is no convenient way to share it—the 
> extension method can't call into an expression at some call site, and 
> contrarily the call site can't invoke the default logic from the extension.

Interesting point.

> 
> If the method were optional, then optional chaining would solve this problem 
> for us:
> 
>   protocol UITableViewDelegate {
>   ...
>   optional func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
>   }
>   
>   class UITableView {
>   ...
>   private func addRow(at indexPath: NSIndexPath) {
>   ...
>   cell.size.height = delegate?.tableView?(self, 
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>   ...
>   }
>   ...
> 
> This way, there is only one source of default behavior: the call site.

It’s “each" call site, not “the” call site. If there are multiple call sites, 
we’d presumably want to factor out the default behavior computation anyway.

> I'm also concerned by the thought of just how many sub-protocols we might end 
> up with. When I try to fully factor NSTableViewDelegate (as it currently 
> exists in the headers), I end up with ten protocols:
> 
>   NSTableViewDelegate
>   - tableView:willDisplayCell:forTableColumn:row:
> 
>   NSTableViewLayoutDelegate: NSTableViewDelegate
>   - tableView:heightOfRow:
> 
>   NSTableViewRowSelectionDelegate: NSTableViewDelegate
>   - tableView:shouldSelectRow:
>   - selectionShouldChangeInTableView:
>   - tableViewSelectionIsChanging:
>   - tableViewSelectionDidChange:
>   - tableView:shouldTrackCell:forTableColumn:row: (10.5)
>   - tableView:selectionIndexesForProposedSelection: (10.5)
> 
>   NSTableViewTypeSelectDelegate: NSTableViewDelegate (10.5)
>   - tableView:typeSelectStringForTableColumn:row:
>   - tableView:nextTypeSelectMatchFromRow:toRow:forString:
>   - tableView:shouldTypeSelectForEvent:withCurrentSearchString:
> 
>   NSTableViewToolTipDelegate: NSTableViewDelegate
>   - tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:
> 
>   NSTableViewColumnDelegate: NSTableViewDelegate
>   - tableView:shouldEditTableColumn:row:
>   - tableView:shouldSelectTableColumn:
>   - tableView:mouseDownInHeaderOfTableColumn:
>   - tableView:didClickTableColumn:
>   - tableView:didDragTableColumn:
>   - tableViewColumnDidMove:
>   - tableViewColumnDidResize:
>   - tableView:sizeToFitWidthOfColumn: (10.6)
>   - tableView:shouldReorderColumn:toColumn: (10.6)
> 
>   NSTableViewCellExpansionDelegate: NSTableViewDelegate (10.5)
>   - tableView:shouldShowCellExpansionForTableColumn:row:
>   
>   NSTableViewCustomCellDelegate: NSTableViewDelegate (10.5)
>   - tableView:dataCellForTableColumn:row:
>   - tableView:isGroupRow:
> 
>   NSTableViewCellViewDelegate: NSTableViewDelegate (10.7)
>   - tableView:viewForTableColumn:row:
> 
>   NSTableViewRowViewDelegate: NSTableViewDelegate (10.7)
>   - tableView:rowViewForRow:
>   - tableView:didAddRowView:forRow:
>   - tableView:didRemoveRowView:forRow:
>   - tableView:rowActionsForRow:edge: (10.11)
> 
> Some of these are probably unnecessary; they could 

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Xiaodi Wu via swift-evolution]

On Mon, Apr 4, 2016 at 11:18 AM, Haravikk via swift-evolution
 wrote:
>
>> On 4 Apr 2016, at 15:49, Jeremy Pereira  
>> wrote:
>>
>>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
>>>  wrote:
>>>
>>> Although I use trailing closures a lot less now, I think I’m a +1 anyway 
>>> for consistency’s sake.
>>>
>>> I actually really like the idea of having trailing keywords in loops and if 
>>> statements, these needn’t be required (except where a trailing closure is 
>>> used) but for example it means I could do a fully natural language loop 
>>> like:
>>>
>>>  for eachValue in theValues do { … }
>>
>> This is actually kind of bizarre. Here we are trying to invent new syntax so 
>> that the trailing closure can be used in if/while conditions and for 
>> sequences. However, there is already a perfectly good syntax for putting 
>> closures in these positions: put the closure in the parentheses of the 
>> function call. Are people really so desperate to use trailing closures 
>> everywhere that we have to add new keywords to the language? I don’t think 
>> they are.
>
> While I kind of agree (and personally prefer the use of parenthesis in most 
> places anyway) it’s an inconsistency to be unable to use them I think. While 
> It’s understandable from a parsing/ambiguity perspective, it’s not really 
> intuitive.

I think it's quite consistent. Trailing closures must be trailing.
Interpret that to mean that it must be the last thing surrounded by
braces, not just the last closure. If a function takes two closures,
only the last can be written with trailing closure syntax. In the
context of a control statement, if a block of code surrounded by
braces follows the closure, the closure cannot be written in trailing
closure syntax. By your argument for "consistency," all closures
should be allowed to be written in trailing syntax, so that for `func
foo(_: Int, _: () -> (), _: () -> ())`, I should be able to write
`func foo(2) { /* code */ } { /* code */ }`. I don't think we need
that level of "consistency."

>
>>> I like the consistency of every block having a kind of type (do, else, 
>>> defer, catch etc.).
>>
>> That is a rabbit hole down which you probably shouldn't go. If we go down 
>> the route of blocks having a “type”, the current situation in Swift becomes 
>> somewhat inconsistent. I would argue that the `else` block on a `guard` is 
>> of a different type to the `else` block on an `if`. If anything, the `else` 
>> block of an `if` is closer to the `then` block. Also, would you allow the 
>> `do` block in a `for` or `while` to have a `catch` block following it? If 
>> not, then these blocks are different to the  existing bare `do` block.
>
> Actually that’s not quite what I meant by “type”; while there is a case to be 
> made for unifying these more (else and catch on loops for example) I just 
> meant more along the lines that “do” would always group the main branch, 
> “else” indicates an alternative path if a condition isn’t met and so-on. For 
> the short term however this would just be a case of allowing do on the end to 
> eliminate ambiguity and thus allow trailing closures, but in the long term it 
> could be explored further.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Erica Sadun via swift-evolution]

On Apr 2, 2016, at 11:13 AM, Dave Abrahams via swift-evolution 
 wrote:
> I believe I misread the proposal and you are right.
> 
> I do have reservations about leading dot syntax that are highlighted by
> this sentence in the proposal:
> 
> A leading dot has become a conventional shorthand for "enumeration case"
> across the language.
> 
> That isn't in fact what it means, and if we have to play into that
> misperception I think it indicates a bigger problem. But we can handle that
> outside of this review. 

Can you ping me off-list or in another thread and explain what the issues are?

Thank you,

-- Erica

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Douglas Gregor via swift-evolution]

> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> As the problem seems to be to eliminate having to write the extension with 
> all its duplication, I'd prefer a more general solution instead of 
> introducing the notion of an "optional" function: just make it possible to 
> write default implementations inline in a protocol definition. 

I think we can consider it as a given that, at some point, we’ll be able to 
write default implementations inline in the protocol definition. It’s not there 
now because we never got around to implementing it.

> Documenting the optionality can be done in the doc comment, maybe with a new 
> documentation keyword "default". Having "optional" in the code has no 
> additional value over a comment because the method is not optional in the 
> Obj-C sense and the proposal requires a default value. Therefore the presence 
> of "optional" has essentially no effect at all and is better moved into a 
> comment.

I tend to agree. ‘optional’ and the ‘= value’ syntax are fairly heavyweight 
language mechanisms for what is effectively documentation.

- Doug

> 
> -Thorsten 
> 
> Am 04.04.2016 um 00:13 schrieb Chris Lattner via swift-evolution 
> >:
> 
>> 
>>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov >> > wrote:
>>> 
 Protocol requirements with default (no-op) implementations already satisfy 
 that design goal, no?
>>> 
>>> Chris, as we've discussed in a thread that I think got forked from this one:
>>> 
>>> Yes, they do technically, but it would be nice to both:
>>> 
>>> 1) make it an obvious documented part of the signature, possibly including 
>>> the default return value
>>> 
>>> 2) possibly make it less verbose by getting rid of the explicitly spelled 
>>> out protocol extension
>> 
>> Right, but “more is worse” when it comes to language design.  Having a "more 
>> general" facility that greatly overlaps with a “more narrow” facility always 
>> makes us question whether it is worth the complexity to have both.
>> 
>> -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] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Xiaodi Wu via swift-evolution]

Hmm, "emplace" looks like more or less a synonym for "install." I
don't think it suggests that the object is being put in place of the
subject. The latest example in the Oxford English Dictionary, from
2010, is:
"Insurgents would hastily emplace victim-activated IEDs...after
Pathfinder came through."
Here, the IEDs are not taking the place of the insurgents.


On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution
 wrote:
>
> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
>
>
>
> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  wrote:
>>
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution
>>  wrote:
>>>
>>> > What is your evaluation of the proposal?
>>>
>>> I don't like "form" as a prefix. To me there is no difference between
>>> `union` and `formUnion`: both sounds functional-style, and actually the
>>> second one perhaps a bit more to my ears. There's basically two dictionary
>>> definitions of "form":
>>>
>>> 1. "bring together parts or combine to create (something)" which to me
>>> implies a new value is created, and
>>> 2. "make or fashion into a certain shape or form" which would imply that
>>> the material you start with is transformed, which is apparently the intended
>>> meaning and also the reverse meaning from the above.
>>>
>>> I mean, doesn't this make sense as an API?
>>>
>>> let donut = baker.formDonut(dough) // non-mutating
>>>
>>> Perhaps instead of "form" we could use "become" as a prefix when the
>>> operation is naturally described by a noun. That would seem less ambiguous
>>> to me:
>>>
>>> a.becomeUnion(b)
>>> a.becomeIntersection(b)
>>> a.becomeSuccessor(b)
>>>
>>> It's a bit passive, but I find it fits well when the operation is a noun.
>>>
>>> And there's no way the term lends itself to non-mutating cases without
>>> things becoming nonsensical:
>>>
>>> let donut = baker.becomeDonut(dough) // non-mutating?
>>
>>
>> I also am having difficulty coming to terms with the use of "form" (I am a
>> native English speaker). As you note "form" can imply the creation of
>> something from parts (more like assembling a new thing) as well as the
>> creation of something out of a material say a of block clay (more like
>> molding something out of an existing thing). It doesn't seem clear cut to me
>> to imply in place mutation.
>>
>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>> type of issue is generally true with any short word made up of the same set
>> of letters (made worse since "from" is more common in programming then
>> "form"). The mind quickly narrows in on a set of possible words given the
>> letters we see and then uses context to help get the correct one and/or
>> additional visual parsing to understand the exact ordering of letters (more
>> energy expended). Anyway since I keep seeing "from" instead of "form" I keep
>> going in the direction of thinking it returns something made from the two
>> (or more) items involved (not really sure why "from" goes that direction in
>> my head, it could also go the in place direction).
>>
>> I would prefer something other then "form" (note I just typed "from" by
>> mistake)... I think your suggestion of "become" has merit.
>>
>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
>> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
>> y.formIntersection(x) --read to me as--> "y from oops... y forming an
>> intersection with x"
>
>
> After stepping away for a bit and looking at it from the POV of the API of
> Set and not in the context of "y" I could read things in the abstract as...
>
> "becomeUnion(with other:Self)" --> "I become a union with other"
> "formUnion(with other:Self)" --> "I form a union with other"
>
> No clear winner to me however when used in code "become" still feels more
> strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)
>
> All in all the API would have mutating in front of it (at least for structs)
> and it wouldn't have a return type. It would become clear fairly quickly as
> a result (hence learned).
>
> Just still not that happy with "form" but with use my mind would likely
> quickly adapt.
>
>
> I think the best English verb for this construction is “emplace”:
>
> http://www.dictionary.com/browse/emplace
>
> It means “to put in position”, and is always used with an object (the noun).
> It’s basically free from incorrect connotations because it’s obscure enough
> that most English speakers won’t know it, and is easily searchable for
> English- and non-English speakers alike.
>
> - Doug
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
> 
> 
> 
> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  > wrote:
> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution 
> > wrote:
> > What is your evaluation of the proposal?
> 
> I don't like "form" as a prefix. To me there is no difference between `union` 
> and `formUnion`: both sounds functional-style, and actually the second one 
> perhaps a bit more to my ears. There's basically two dictionary definitions 
> of "form":
> 
> 1. "bring together parts or combine to create (something)" which to me 
> implies a new value is created, and
> 2. "make or fashion into a certain shape or form" which would imply that the 
> material you start with is transformed, which is apparently the intended 
> meaning and also the reverse meaning from the above.
> 
> I mean, doesn't this make sense as an API?
> 
> let donut = baker.formDonut(dough) // non-mutating
> 
> Perhaps instead of "form" we could use "become" as a prefix when the 
> operation is naturally described by a noun. That would seem less ambiguous to 
> me:
> 
> a.becomeUnion(b)
> a.becomeIntersection(b)
> a.becomeSuccessor(b)
> 
> It's a bit passive, but I find it fits well when the operation is a noun.
> 
> And there's no way the term lends itself to non-mutating cases without things 
> becoming nonsensical:
> 
> let donut = baker.becomeDonut(dough) // non-mutating?
> 
> I also am having difficulty coming to terms with the use of "form" (I am a 
> native English speaker). As you note "form" can imply the creation of 
> something from parts (more like assembling a new thing) as well as the 
> creation of something out of a material say a of block clay (more like 
> molding something out of an existing thing). It doesn't seem clear cut to me 
> to imply in place mutation.
> 
> Additionally my eyes / brain keep seeing "from" instead of "form". This type 
> of issue is generally true with any short word made up of the same set of 
> letters (made worse since "from" is more common in programming then "form"). 
> The mind quickly narrows in on a set of possible words given the letters we 
> see and then uses context to help get the correct one and/or additional 
> visual parsing to understand the exact ordering of letters (more energy 
> expended). Anyway since I keep seeing "from" instead of "form" I keep going 
> in the direction of thinking it returns something made from the two (or more) 
> items involved (not really sure why "from" goes that direction in my head, it 
> could also go the in place direction).
> 
> I would prefer something other then "form" (note I just typed "from" by 
> mistake)... I think your suggestion of "become" has merit.
> 
> y.becomeUnion(x) --reads to me as--> "y become union with x"
> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
> y.formIntersection(x) --read to me as--> "y from oops... y forming an 
> intersection with x"
> 
> After stepping away for a bit and looking at it from the POV of the API of 
> Set and not in the context of "y" I could read things in the abstract as...
> 
> "becomeUnion(with other:Self)" --> "I become a union with other"
> "formUnion(with other:Self)" --> "I form a union with other"
> 
> No clear winner to me however when used in code "become" still feels more 
> strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)
> 
> All in all the API would have mutating in front of it (at least for structs) 
> and it wouldn't have a return type. It would become clear fairly quickly as a 
> result (hence learned).
> 
> Just still not that happy with "form" but with use my mind would likely 
> quickly adapt.

I think the best English verb for this construction is “emplace”:

http://www.dictionary.com/browse/emplace

It means “to put in position”, and is always used with an object (the noun). 
It’s basically free from incorrect connotations because it’s obscure enough 
that most English speakers won’t know it, and is easily searchable for English- 
and non-English speakers alike.

- Doug

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

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Thorsten Seitz via swift-evolution]

> Am 04.04.2016 um 13:00 schrieb Ilya Belenkiy via swift-evolution 
> :
> 
> I think that it’s very useful (I use it frequently in unit tests). I hope 
> that this stays the way it is now.

Do you really use the ability to reorder the arguments or just the ability to 
omit any combination of default arguments?

-Thorsten 

> 
>> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Many people are surprised when they find out defaulted parameters can be 
>> reordered, unlike required arguments. This special case adds complexity to 
>> the language, and runs against our general trend of treating argument labels 
>> as a significant part of an API's name, and preferring a single way of 
>> writing API calls. I think it's worth revisiting this design choice—is the 
>> special case worth the complexity? How many people take advantage of default 
>> argument reordering?
>> 
>> -Joe
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Thorsten Seitz via swift-evolution]

> Am 04.04.2016 um 16:49 schrieb Jeremy Pereira via swift-evolution 
> :
> 
> 
>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
>>  wrote:
>> 
>> Although I use trailing closures a lot less now, I think I’m a +1 anyway for 
>> consistency’s sake.
>> 
>> I actually really like the idea of having trailing keywords in loops and if 
>> statements, these needn’t be required (except where a trailing closure is 
>> used) but for example it means I could do a fully natural language loop like:
>> 
>>for eachValue in theValues do { … }
> 
> This is actually kind of bizarre. Here we are trying to invent new syntax so 
> that the trailing closure can be used in if/while conditions and for 
> sequences. However, there is already a perfectly good syntax for putting 
> closures in these positions: put the closure in the parentheses of the 
> function call. Are people really so desperate to use trailing closures 
> everywhere that we have to add new keywords to the language? I don’t think 
> they are.

I agree.
While I'm a big proponent of trailing closures to create DSL like control 
constructs and prefer them over nesting closures within parentheses I don't 
think it is a good idea to mix such DSL like control constructs with existing 
control constructs as this would not increase readability but rather decrease 
it (compare e.g. the example given by Xiaodi).

Therefore I'm -1 on this proposal and think it's fine having to use parentheses 
instead of trailing closures in such cases.

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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Dave Abrahams via swift-evolution]

on Fri Apr 01 2016, Brent Royal-Gordon  wrote:

>> My apologies if this was previously discussed. Was there ever a
>> reason given for not using operators for set combiners? That is, | &
>> - ^ for union, intersection, subtracting, and symmetricDifference,
>> and |= &= -= ^= for the mutating versions.
>
> With a few exceptions (like `+` for concatenation), Swift doesn't
> overload operators to give them different meanings, even if they're
> kinda similar if you squint enough.

In my opinion these operators would be perfectly appropriate for Sets.
They have exactly the right semantic implications and relationships.
This is the same reason we use + for both scalars and vectors in math,
even though they're different in some ways.

If someone else would like to write a proposal for making these
operators available on sets, I'd support it.

-- 
Dave

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

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

[Ilya Belenkiy via swift-evolution]

Just to double check: do I need to do anything with the proposal? It sounds
like it was decided, and Doug will update the proposal, but I 'd like to
make sure that there is nothing to be done on my end.

On Fri, Apr 1, 2016 at 5:07 PM Ilya Belenkiy 
wrote:

> Great! Glad that we have a decision.
>
> On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mar 30, 2016, at 9:22 PM, Chris Lattner  wrote:
>> >
>> > I’ve seen a number of concerns on this list about moduleprivate, and
>> how it penalizes folks who want to explicitly write their access control.
>> I’ve come to think that there is yes-another possible path forward here
>> (which I haven’t seen mentioned so far):
>> >
>> > public
>> > internal
>> > fileprivate
>> > private
>>
>> Hi Everyone,
>>
>> Thank you for all of the input.  I know that this was a highly
>> contentious topic, that it is impossible to make everyone happy.  Getting
>> the different inputs and perspectives has been very very useful.
>>
>> The core team met to discuss this, and settled on the list above:
>> public/internal/fileprivate/private.  This preserves the benefit of the
>> “fileprivate” concept that we have today in Swift, while aligning the
>> “private” keyword with common expectations of people coming to Swift. This
>> also makes “private" the "safe default” for cases where you don’t think
>> about which one you want to use, and this schema will cause minimal churn
>> for existing Swift code.
>>
>> Thank you again for all of the input and discussion!
>>
>> -Chris
>>
>> btw, to be clear, this is *not* an April 1 joke.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Jeremy Pereira via swift-evolution]

> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution 
>  wrote:
> 
> Although I use trailing closures a lot less now, I think I’m a +1 anyway for 
> consistency’s sake.
> 
> I actually really like the idea of having trailing keywords in loops and if 
> statements, these needn’t be required (except where a trailing closure is 
> used) but for example it means I could do a fully natural language loop like:
> 
>   for eachValue in theValues do { … }

This is actually kind of bizarre. Here we are trying to invent new syntax so 
that the trailing closure can be used in if/while conditions and for sequences. 
However, there is already a perfectly good syntax for putting closures in these 
positions: put the closure in the parentheses of the function call. Are people 
really so desperate to use trailing closures everywhere that we have to add new 
keywords to the language? I don’t think they are.

> 
> I like the consistency of every block having a kind of type (do, else, defer, 
> catch etc.). 

That is a rabbit hole down which you probably shouldn't go. If we go down the 
route of blocks having a “type”, the current situation in Swift becomes 
somewhat inconsistent. I would argue that the `else` block on a `guard` is of a 
different type to the `else` block on an `if`. If anything, the `else` block of 
an `if` is closer to the `then` block. Also, would you allow the `do` block in 
a `for` or `while` to have a `catch` block following it? If not, then these 
blocks are different to the  existing bare `do` block. 

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

Re: [swift-evolution] Enable omitting `let` for constant declarations

[Yuta Koshizawa via swift-evolution]

> Radosław

Hi. I found Stephen Celis proposed exactly same notations in the
thread "Mutability inference". I guess it is what you talked about.

> let a: String = "string"
> b: String = "string" // short-hand avoids let
> b := "string" // shorter-hand

But it seems that it was not well discussed, and I think it is worth
discussing it.

> Macko

Thanks!

-- Yuta


2016-04-03 16:23 GMT+09:00 Macko Jeffrey :
> I love your propositions Yuta.
>
> ---
> Macko Jeffrey
>
>> Le 1 avr. 2016 à 20:58, Yuta Koshizawa via swift-evolution 
>>  a écrit :
>>
>> Did you mean the thread "Mutability inference"? What I talked about is
>> different from it. I am against the idea of "Mutability inference".
>>
>> What I talked about is just enabling to omit `let` for constant
>> declarations. It distinguishes the following three explicitly.
>>
>>> - assignment
>>> - declaration of a constant
>>> - declaration of a mutable variable
>>
>> `:=` makes it possible to distinguish assignments and constant declarations.
>>
>> -- Yuta
>>
>>
>> 2016-04-01 23:55 GMT+09:00 Radosław Pietruszewski :
>>> I can’t easily find it, but there’s been at least one thread proposing this 
>>> exact thing, and there was very little interest in the proposal.
>>>
>>> TL;DR is that Swift *by design* wants to make the difference between these 
>>> three concepts:
>>>
>>> - assignment
>>> - declaration of a constant
>>> - declaration of a mutable variable
>>>
>>> as explicit and obvious as possible.
>>>
>>> — Radek
>>>
 On 01 Apr 2016, at 13:58, Yuta Koshizawa via swift-evolution 
  wrote:

 I think it would be good if the following three declarations were 
 equivalent

 let a: Int = 42
 a: Int = 42
 a := 42

 and also the following two were.

 let a: Int
 a: Int

 Then constant declarations become shorter than variable declarations.
 It encourages people to use constants in preference to variables.

 It also prevents repeating `let` for property declarations and makes
 type declarations simpler.

 struct Person {
   firstName: String
   lastName: String
   age: Int
 }

 Omitting `let` is consistent with that we don't write `let` for
 arguments of functions and iterated values in for-in loops.

 Not `=` but `:=` for type inferences because `=` cannot distinguish
 whether it means a constant declaration or an assignment to a variable
 declared in an outer scope. I think `:=` is a natural notation for
 type inferences because omitting the type from `a: Int = 42` makes
 `a:= 42`. Because I have not strictly checked if it can be parsed in
 Swift properly, it may have some other parsing issues.

 What do you think about it?

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

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Patrick Gili via swift-evolution]

If I understand you correctly, you think adding keywords represents an 
inconsistency. However, I think it would add considerable consistency and 
utility to the Swift language. Yes, it would make it inconsistent with the 
generations of C-like languages that have come before it. However, I think 
we've already taken considerable steps from away from C-like languages; for 
example, removing C-like for-loop syntax and unary increment/decrement 
operators.

-Patrick

> On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution 
>  wrote:
> 
> 
> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution 
> > a écrit :
> 
>>> What is your evaluation of the proposal?
>> I think there is a lot of value to allowing trailing closures in the guard 
>> condition clause. However, not at the cost of inconsistency. We have 
>> reviewed many proposals over the last month that addressed consistency 
>> issues in the Swift language, and if I'm not mistaken, all of them have been 
>> accepted by the community, larger to eliminate the inconsistency.
>> 
>> Because of this, I think two of the alternatives stated by the proposal have 
>> credibility:
>> 1) Eliminate the "else" keyword from the guard syntax.
>> 2) Add keywords to "if", "while", "for", and "switch" to delineate the 
>> condition clause from the body of the statement.
>> 
>> The second alternative has more appeal, because it supports trailing 
>> closures without "heroics".
> 
> It have been mentioned multiple times that allowing trailing closure only for 
> guard is creating an inconsistency, but these keywords already are 
> inconsistent with the each other (beside the presence of the 'trailing' else 
> keyword) on the variable scoping:
> 
> - guard let: outer scope immutable variable
> - if let: inner scope immutable variable
> - for: inner scope immutable variable without let keyword
> 
> Consistency is good, but since each keywords are not for the exact same 
> thing, it is normal to see some variances.  Like the global scope of the 
> immutable variable created by guard; as per the intent of the keyword, or its 
> trailing else keyword; needed to clarify that what follow is for, for lack of 
> better word, the 'else' case.
> 
> So as long as such inconsistency have a "raison d'être", that they have been 
> designed and are not an oversight; there should be no reason to not allow 
> them.
> 
> Dany
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> No.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> No. Please don't add inconsistencies to the language, as we're just going to 
>> have to deal with it down the road.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> Not in my experience.
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> In-depth study.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Patrick Gili via swift-evolution]

Personally, I don't like any of the options. However, I mentioned this during 
the review of the API naming guidelines. Using the English language to 
construct function names that distinguish between functional and imperative 
forms of the operation places constraints on API designers that produce 
undesirable results. The operations on an algebraic set is merely one example. 
My preference is a symbol appended to the function name (e.g., the exclamation 
point in Ruby). However, it was pointed out at the time that introducing this 
syntax was out-of-scope for Swift 3. What does this mean? We'll revisit this 
later and have to endure the rigor of another API renaming exercise?

Without rehashing the utility of a symbol to distinguish between functional and 
imperative, what is my preference?

Pseudo-verbs? I don't know if this is any better.

A suffix, such as "InPlace", has some appeal for two reasons:

1) It is descriptive and doesn't obfuscate the meaning of the operation.

2) If at sometime later the community sees a practical need to introduce syntax 
to distinguish between functional and imperative forms of an operation, 
removing such a suffix and replacing it with the symbol will mitigate confusion 
of another renaming transition.

Cheers,
-Patrick

> On Apr 2, 2016, at 5:15 PM, Brent Royal-Gordon  wrote:
> 
>> For example, changing union() to formUnion() for the sake of aligning 
>> compliance to API name guidelines simply doesn't make sense to me.
> 
> Given the need for separate names for the functional and imperative forms of 
> this operation, what sorts of names would be better? Pseudo-verbs like 
> `unioning`? An `InPlace` suffix?
> 
> (Everyone else, please don't take this as an invitation to start the 
> bikeshedding again. I'm trying to understand what *this reviewer* prefers.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

[Lukas Stabe via swift-evolution]

This is a very welcome addition. Thanks!

A nitpicky detail: I’d prefer the format for the lock file to be yaml or toml 
over json, since those read a little easier in git diffs (which is, in my 
experience with cocoapods lockfiles, the only place I ever interact with the 
lockfiles contents).

— Lukas

> On 17 Mar 2016, at 19:23, Max Howell via swift-evolution 
>  wrote:
> 
> The following is a draft proposal, feedback welcome.
> 
> 
> SwiftPM Dependency Version Locking
> Proposal: SE- 
> 
> Author(s): Ankit Agarwal , Max Howell 
> 
> Status: Discussion
> Review manager: Rick Ballard
> Introduction
> This proposal seeks to declare a new, generated file 
> Packages/VersionLocks.json that describes the exact state of a package’s 
> dependency graph and then by default will be respected when executing most 
> package manager commands. Thus it is considered a “version lock” for a 
> package’s dependency sources.
> 
> Swift-evolution thread 
> 
> Terminology
> A package refers to a published, versioned git repository designed to be 
> consumed as a dependency by SwiftPM.
> A project refers to an end-user workspace that uses SwiftPM (via a 
> Package.swift and swift build) fetching and building packages as part of its 
> build
> Describing this distinction is required because both the above have the same 
> form, but are used differently by an end-user. An end-user may publish 
> packages, but will eventually consume those packages in a project.
> 
> As justification for this confusion, it is considered a feature that projects 
> can easily and trivially become packages when using SwiftPM. Encouraging a 
> vibrant packaging ecosystem is one of our goals.
> 
> Motivation
> In a vibrant packaging ecosystem, dependencies update continuously with 
> bug-fixes and new features. A development team needs:
> 
> To ensure they are all using the same versions of their dependencies for any 
> given version-control commit.
> Ensure they are all using the same versions of the underlying Swift toolchain
> Be able to override or modify dependency specifications for the whole team 
> for specific commits.
> Currently with SwiftPM it is possible to fulfill 1. by committing the sources 
> of a package’s dependencies with the package itself, but this is not always 
> desirable. There is no way to achieve 2. and 3. with SwiftPM alone.
> 
> Additionally, there is not currently a way to know which version of Swift a 
> package requires to build. At this time this situation is particularly 
> precarious because Swift itself is not backwards compatible. As a Swift 
> developer at the very least recording which Swift version a package was built 
> with by the package developer is essential information in order to assess a 
> package's suitability. Practically the package manager could in the future 
> use this information to aid an end-user or even fix the problem when packages 
> fail to compile.
> 
> Proposed Solution
> A file: Packages/VersionLocks.json will be created alongside the 
> Package.swift file. Its contents will describe:
> 
> The URL and versions of cloned dependencies
> An inline diff of any local modifications made to those packages relative to 
> their pristine cloned states
> The exact version of the Swift toolchain used as part of the last successful 
> build of the package
> This file is generated by SwiftPM.
> 
> This file should be checked-in with projects.
> 
> This file is generated and should not be edited by users. If the file is 
> edited by users the behavior is undefined.
> 
> This file should be checked-in with packages designed for consumption in 
> projects, however SwiftPM will not use the checkout files of dependencies 
> when determining a project’s dependency graph (this would make dependency 
> graphs much less likely to resolve due to overly strict versioning 
> requirements). In the future we may choose to make it possible for end-users 
> to attempt to build a package using all checkout files since in certain 
> deployment scenarios where an exact graph has already been tested, this is a 
> solid reliabiity feature.
> 
> Any local, modifications made to the clones in Packages are recorded in 
> Packages/VersionLocks.json as part of the flow described in the next section. 
> Modifications here means: changes to git remotes and the git-ref of the 
> checked-out HEAD.
> 
> Detailed Design
> In a fresh clone that does not contain a Packages directory swift build will 
> determine the dependency graph, clone the packages into Packages and generate 
> a Packages/VersionLocks.json file.
> 
> The user can now step into the Packages directory and modify package sources. 
> If the user then runs swift build again the package 

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Ilya Belenkiy via swift-evolution]

I think that it’s very useful (I use it frequently in unit tests). I hope that 
this stays the way it is now.

> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Many people are surprised when they find out defaulted parameters can be 
> reordered, unlike required arguments. This special case adds complexity to 
> the language, and runs against our general trend of treating argument labels 
> as a significant part of an API's name, and preferring a single way of 
> writing API calls. I think it's worth revisiting this design choice—is the 
> special case worth the complexity? How many people take advantage of default 
> argument reordering?
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Proposal] Custom operators

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

Just to clarify, with currently proposed
behaviour, corresponding expressions would be parsed as follows:

a + b * c  // a + (b * c)
a * b ^ c  // a * (b ^ c)
a ^ b + c  // a ^ (b + c)

The compiler would look only at explicitly stated precedence between two
given operators and would not try to use transcendency.

Having said that, at least two opinions were that operators should form a
DAG by precedence. If no objections are stated, I will change the proposal
accordingly, also without future directions.

On, Apr 4, 2016, Ross O'Brien wrote:

> How is a non-transitive relation different from a conflict?
> If we use:
> #precedence(+, lessThan: *)
> #precedence(*, lessThan: ^)
> #precedence(^, lessThan: +)
> Surely that should be an error, even with none of the operators actually
> used?
>
> The compiler would be asked to verify two things: that the relationships
> of all operators in the program can be expressed with a topological
> ordering, and any pair of operators used together in an expression in the
> program has an unambiguous precedence in that ordering. (I have no idea how
> relatable this comparison actually is, but it seems like it would be a
> simpler problem than analysing NSLayoutConstraints for violations.)
>
> On Mon, Apr 4, 2016 at 7:49 AM, Антон Жилин 
> wrote:
>
>> In the poposed model, all relations are not transitive. Example:
>>
>> #precedence(+, lessThan: *)
>> #precedence(*, lessThan: ^)
>> 1 ^ 2 + 3  // error
>> #precedence(+, lessThan: ^)
>> 1 ^ 2 + 3  // now ok
>>
>> Would it be better to have such indirect relations inferred? Or would it
>> put too much responsibility on the compiler?
>> Maybe add it to future directions?
>>
>> Cycles of length >2 are also allowed. This was not added intentionally,
>> but follows from other specified rules.
>> Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
>> stretched, otherwise quite logical.
>>
>> > - I wonder if there are cases in the standard operators which would be
>> better modeled as a non-linear chain.
>> In the standard library, non-linearity will be primarily used to break a
>> single hierarchy into multiple small ones. I doubt that any trees or cycles
>> will form, although that would be good news.
>>
>> - Anton
>>
>> 2016-04-04 8:55 GMT+03:00 David Waite :
>>
>>> Interesting model!
>>>
>>> If I understand correctly: this changes the precedence from being based
>>> on a numeric value, to being represented as a bit of a DAG of precedence
>>> groups. A precedence group is defined implicitly for each operator, with
>>> one group around each set of operators where equalTo has been declared.
>>>
>>> The groups are lazily evaluated, so if an expression can be resolved
>>> without ambiguity due to lack of reachability between two individual
>>> operators in the DAG, there is no issue/error.
>>>
>>> Comments:
>>> - I wonder if there are cases in the standard operators which would be
>>> better modeled as a non-linear chain.  The compiler could warn around usage
>>> which is defined by operator precedence, but is commonly considered
>>> ambiguous or error prone.
>>>
>>> For example, if users commonly get confused about the conjunctive and
>>> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
>>> precedence, you could just omit the lessThan relationship between the two
>>> of them. The compiler would then error on ambiguous cases, prompting the
>>> user to use parenthesis.
>>>
>>> - I’d prefer instead of operator precedence groups just being implicit
>>> by use of #precedence equalTo, that the operators are bound to a group
>>> explicitly. Something like
>>> #precedence(+, group: “additive”)
>>> #precedence(“additive”, lessThan: “multiplicative”)
>>>
>>> However, this may create more issues than it solves (two frameworks
>>> creating their own custom operators, putting them in custom precedence
>>> groups, and the consumer decides the two precedence groups are really
>>> equivalent)
>>>
>>> -DW
>>>
>>> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Swift 2.2 is out, and I restart discussion on syntax for custom
>>> operators. I insist that this time we should focus less on linguistic
>>> aspects.
>>>
>>>
>>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.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] [Proposal] Custom operators

[Ross O'Brien via swift-evolution]

How is a non-transitive relation different from a conflict?
If we use:
#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
#precedence(^, lessThan: +)
Surely that should be an error, even with none of the operators actually
used?

The compiler would be asked to verify two things: that the relationships of
all operators in the program can be expressed with a topological ordering,
and any pair of operators used together in an expression in the program has
an unambiguous precedence in that ordering. (I have no idea how relatable
this comparison actually is, but it seems like it would be a simpler
problem than analysing NSLayoutConstraints for violations.)

On Mon, Apr 4, 2016 at 7:49 AM, Антон Жилин 
wrote:

> In the poposed model, all relations are not transitive. Example:
>
> #precedence(+, lessThan: *)
> #precedence(*, lessThan: ^)
> 1 ^ 2 + 3  // error
> #precedence(+, lessThan: ^)
> 1 ^ 2 + 3  // now ok
>
> Would it be better to have such indirect relations inferred? Or would it
> put too much responsibility on the compiler?
> Maybe add it to future directions?
>
> Cycles of length >2 are also allowed. This was not added intentionally,
> but follows from other specified rules.
> Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
> stretched, otherwise quite logical.
>
> > - I wonder if there are cases in the standard operators which would be
> better modeled as a non-linear chain.
> In the standard library, non-linearity will be primarily used to break a
> single hierarchy into multiple small ones. I doubt that any trees or cycles
> will form, although that would be good news.
>
> - Anton
>
> 2016-04-04 8:55 GMT+03:00 David Waite :
>
>> Interesting model!
>>
>> If I understand correctly: this changes the precedence from being based
>> on a numeric value, to being represented as a bit of a DAG of precedence
>> groups. A precedence group is defined implicitly for each operator, with
>> one group around each set of operators where equalTo has been declared.
>>
>> The groups are lazily evaluated, so if an expression can be resolved
>> without ambiguity due to lack of reachability between two individual
>> operators in the DAG, there is no issue/error.
>>
>> Comments:
>> - I wonder if there are cases in the standard operators which would be
>> better modeled as a non-linear chain.  The compiler could warn around usage
>> which is defined by operator precedence, but is commonly considered
>> ambiguous or error prone.
>>
>> For example, if users commonly get confused about the conjunctive and
>> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
>> precedence, you could just omit the lessThan relationship between the two
>> of them. The compiler would then error on ambiguous cases, prompting the
>> user to use parenthesis.
>>
>> - I’d prefer instead of operator precedence groups just being implicit by
>> use of #precedence equalTo, that the operators are bound to a group
>> explicitly. Something like
>> #precedence(+, group: “additive”)
>> #precedence(“additive”, lessThan: “multiplicative”)
>>
>> However, this may create more issues than it solves (two frameworks
>> creating their own custom operators, putting them in custom precedence
>> groups, and the consumer decides the two precedence groups are really
>> equivalent)
>>
>> -DW
>>
>> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift 2.2 is out, and I restart discussion on syntax for custom
>> operators. I insist that this time we should focus less on linguistic
>> aspects.
>>
>>
>> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.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] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Xiaodi Wu via swift-evolution]

My read on the API guidelines is that the mutating/non-mutating distinction
is made by verbs vs. nouns. The verb itself doesn't have to "suggest" or
"feel" mutating, it just has to be clearly a verb. Thus, IMO, `form` is as
good a verb as any, although if we're going to return to bikeshedding I
would suggest that `do` is even shorter.

On Mon, Apr 4, 2016 at 1:20 AM Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> Looking at other languages:
>
>
>1. A Java like API would be:
>   - mutating func remove(T) -> Void
>   - mutating func remove(all: S) -> Void
>   - func removed(T) -> Self
>   - func removed(all: S) -> Self
>   - Similarly for retain and add
>   2. In Scala they primarily use operators, so a Scala like API would
>be:
>   - func -=(inout Self, T) -> Void
>   - func -=(inout Self, S) -> Void
>   - func -(T) -> Self
>   - func -(all: S) -> Self
>   - Similarly for & and +
>
>
> Either of these naming patterns seems better than those proposed :(.
>
>   -- Howard.
>
> On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think Michel and Shawn did raise some good points here.
>>
>> -Thorsten
>>
>> Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution <
>> swift-evolution@swift.org>:
>>
>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> > What is your evaluation of the proposal?
>>>
>>> I don't like "form" as a prefix. To me there is no difference between
>>> `union` and `formUnion`: both sounds functional-style, and actually the
>>> second one perhaps a bit more to my ears. There's basically two dictionary
>>> definitions of "form":
>>>
>>> 1. "bring together parts or combine to create (something)" which to me
>>> implies a new value is created, and
>>> 2. "make or fashion into a certain shape or form" which would imply that
>>> the material you start with is transformed, which is apparently the
>>> intended meaning and also the reverse meaning from the above.
>>>
>>> I mean, doesn't this make sense as an API?
>>>
>>> let donut = baker.formDonut(dough) // non-mutating
>>>
>>> Perhaps instead of "form" we could use "become" as a prefix when the
>>> operation is naturally described by a noun. That would seem less ambiguous
>>> to me:
>>>
>>> a.becomeUnion(b)
>>> a.becomeIntersection(b)
>>> a.becomeSuccessor(b)
>>>
>>> It's a bit passive, but I find it fits well when the operation is a noun.
>>>
>>> And there's no way the term lends itself to non-mutating cases without
>>> things becoming nonsensical:
>>>
>>> let donut = baker.becomeDonut(dough) // non-mutating?
>>>
>>
>> I also am having difficulty coming to terms with the use of "form" (I am
>> a native English speaker). As you note "form" can imply the creation of
>> something from parts (more like assembling a new thing) as well as the
>> creation of something out of a material say a of block clay (more like
>> molding something out of an existing thing). It doesn't seem clear cut to
>> me to imply in place mutation.
>>
>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>> type of issue is generally true with any short word made up of the same set
>> of letters (made worse since "from" is more common in programming then
>> "form"). The mind quickly narrows in on a set of possible words given the
>> letters we see and then uses context to help get the correct one and/or
>> additional visual parsing to understand the exact ordering of letters (more
>> energy expended). Anyway since I keep seeing "from" instead of "form" I
>> keep going in the direction of thinking it returns something made from the
>> two (or more) items involved (not really sure why "from" goes that
>> direction in my head, it could also go the in place direction).
>>
>> I would prefer something other then "form" (note I just typed "from" by
>> mistake)... I think your suggestion of "become" has merit.
>>
>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
>> y.becomeIntersection(x) --reads to me as--> "y become intersection with
>> x"
>> y.formIntersection(x) --read to me as--> "y from oops... y forming an
>> intersection with x"
>>
>> In the "forming" situations it – to me – is ambiguous on if that is in
>> place or not. To me it implies more of giving something new back.
>>
>> I am -1 on "form" aspect of this proposal. ...of course things are
>> learnable as long as things are fairly consistent and not to far out of the
>> norm for typical language use. Personally I don't see "form" as that
>> typical in English.
>>
>> -Shawn
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> 

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[T.J. Usiyan via swift-evolution]

+1

I use it but won't fight for it or miss it.

On Thu, Mar 31, 2016 at 12:45 PM, Javier Soto via swift-evolution <
swift-evolution@swift.org> wrote:

> I have never taken advantage of this. In fact, I didn't know this was
> possible until just now :) and I would've definitely found it confusing to
> see a function call with "out of order" parameters.
> On Thu, Mar 31, 2016 at 7:58 AM Developer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1
>>
>> ~Robert Widmann
>>
>> 2016/03/31 10:26、Jeff Kelley via swift-evolution <
>> swift-evolution@swift.org> のメッセージ:
>>
>> I have never taken advantage of this, personally. Given that there isn’t
>> anything that this feature enables that can’t be done if it’s removed—aside
>> from reordering arguments—I’d be in favor of removing it for simplicity’s
>> sake.
>>
>> Jeff Kelley
>>
>> slauncha...@gmail.com | @SlaunchaMan  |
>> jeffkelley.org
>>
>> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Many people are surprised when they find out defaulted parameters can be
>> reordered, unlike required arguments. This special case adds complexity to
>> the language, and runs against our general trend of treating argument
>> labels as a significant part of an API's name, and preferring a single way
>> of writing API calls. I think it's worth revisiting this design choice—is
>> the special case worth the complexity? How many people take advantage of
>> default argument reordering?
>>
>> -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
>>
> --
> Javier Soto
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

[T.J. Usiyan via swift-evolution]

   - What is your evaluation of the proposal?

+1

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

Yes

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

Yes. In particular, @noescape fits much better as a type attribute

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

no

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

I followed the discussion and have puzzled over and discussed @noescape and
@autoclosure many times.

On Mon, Mar 28, 2016 at 12:48 PM, Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0049 "Move @noescape and @autoclosure to be type
> attributes" begins now and runs through March 31, 2016. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.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. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -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] Custom operators

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

In the poposed model, all relations are not transitive. Example:

#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
1 ^ 2 + 3  // error
#precedence(+, lessThan: ^)
1 ^ 2 + 3  // now ok

Would it be better to have such indirect relations inferred? Or would it
put too much responsibility on the compiler?
Maybe add it to future directions?

Cycles of length >2 are also allowed. This was not added intentionally, but
follows from other specified rules.
Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
stretched, otherwise quite logical.

> - I wonder if there are cases in the standard operators which would be
better modeled as a non-linear chain.
In the standard library, non-linearity will be primarily used to break a
single hierarchy into multiple small ones. I doubt that any trees or cycles
will form, although that would be good news.

- Anton

2016-04-04 8:55 GMT+03:00 David Waite :

> Interesting model!
>
> If I understand correctly: this changes the precedence from being based on
> a numeric value, to being represented as a bit of a DAG of precedence
> groups. A precedence group is defined implicitly for each operator, with
> one group around each set of operators where equalTo has been declared.
>
> The groups are lazily evaluated, so if an expression can be resolved
> without ambiguity due to lack of reachability between two individual
> operators in the DAG, there is no issue/error.
>
> Comments:
> - I wonder if there are cases in the standard operators which would be
> better modeled as a non-linear chain.  The compiler could warn around usage
> which is defined by operator precedence, but is commonly considered
> ambiguous or error prone.
>
> For example, if users commonly get confused about the conjunctive and
> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
> precedence, you could just omit the lessThan relationship between the two
> of them. The compiler would then error on ambiguous cases, prompting the
> user to use parenthesis.
>
> - I’d prefer instead of operator precedence groups just being implicit by
> use of #precedence equalTo, that the operators are bound to a group
> explicitly. Something like
> #precedence(+, group: “additive”)
> #precedence(“additive”, lessThan: “multiplicative”)
>
> However, this may create more issues than it solves (two frameworks
> creating their own custom operators, putting them in custom precedence
> groups, and the consumer decides the two precedence groups are really
> equivalent)
>
> -DW
>
> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Daniel Dunbar via swift-evolution]

Hi Max,

The proposal refers to "the pkg-config specification", can you add a link to 
that? In particular, I am curious how SwiftPM will know where to look for those 
files.

 - Daniel

> On Mar 31, 2016, at 4:04 PM, Max Howell via swift-evolution 
>  wrote:
> 
> I have updated the proposal with everyone’s feedback:
> 
> SwiftPM System Module Search Paths
> 
> Proposal: SE- 
> 
> Author: Max Howell 
> Status: Awaiting review
> Review manager: Anders Bertelrud
>  
> Introduction
> 
> Swift is able to import C libraries in the same manner as Swift libraries.
> 
> For this to occur the library must be represented by a clang module-map file.
> 
> The current system for using these module-map files with SwiftPM works, but 
> with a number of caveats that must be addressed.
> 
>  
> Motivation
> 
> The current implementation of system module packages have a number of 
> problems:
> 
> Install locations vary across platforms and modulemap files require absolute 
> paths
> /usr/lib:/usr/local/lib is not always a sufficient -L search path
> /usr/include:/usr/local/include is not always a sufficient -I C compiler 
> search path
> Installing the system library is left up to the end-user to figure out
> For example to import a module map representing the GTK library, the include 
> search path must be supplemented with -I/usr/include/gtk so that a number of 
> includes in the gtk.h header can be sourced for the complete modular 
> definition of GTK.
> 
> For example to import a module map representing the GTK library a user must 
> first have a copy of GTK and its headers installed. On Debian based systems 
> the install name for this system package is libgtk-3-0-dev which is not 
> entirely intuitive.
> 
> For example, Homebrew and MacPorts on OS X install to prefixes other than 
> /usr. .modulemap files must specify headers with absolute paths. The standard 
> we encourage with modulemaps is for the headers to be specified with an 
> assumed prefix of /usr, but you will not find eg. jpeglib.h at 
> /usr/include/jpeglib.h if it is installed with Homebrew or MacPorts.
> 
>  
> Proposed
>  Solution
> 
> We propose that SwiftPM gains the ability to use the cross-platform 
> pkg-config tool so that it can query pkg-config for the missing path and flag 
> arguments.
> 
> We propose that SwiftPM gains the ability to use the cross-platform 
> pkg-config tool to identify when the system package is not installed to a 
> /usr and in such a case preprocess the modulemap changing the prefix it uses.
> 
> We propose that Package.swift is supplemented with metadata that provides the 
> package-install-name for specific platforms.
> 
>  
> Detailed
>  Design
> 
>  
> Solving
>  Path/Flags Issues
> 
> Some of our problems can be solved by using the cross platform tool: 
> pkg-config.
> 
> A C package can provide a pkg-config file (.pc) which describes:
> 
> Its install location
> Supplementary C-flags that should be used when compiling against this library
> Supplementary C-flags that should be used when linking against this library
> If SwiftPM used the .pc file that comes with packages, this solves problems 1 
> through 3.
> 
> Of the tickets we currently have open describing issues using 
> Swift-system-module-packages, reading the .pc file would fix all of them.
> 
> It is a convention to name the .pc file after the library link-name, so we 
> can determine which .pc file to ask pkg-configfor by parsing the .modulemap 
> file in the Swift package. However sometimes this is not true, (eg. GTK-3 on 
> Ubuntu), so we will make it possible to specify the .pc file name in 
> Package.swift.
> 
> pkg-config is not currently a dependency of the Swift toolchain, and thus to 
> avoid depending on it we will schedule work to interpret .pc files without 
> requiring pkg-config to be installed. The file format for .pc files is simple 
> and standard so despite reinventing the wheel, this is a low risk choice.
> 
>  
> 

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Howard Lovatt via swift-evolution]

Looking at other languages:


   1. A Java like API would be:
  - mutating func remove(T) -> Void
  - mutating func remove(all: S) -> Void
  - func removed(T) -> Self
  - func removed(all: S) -> Self
  - Similarly for retain and add
  2. In Scala they primarily use operators, so a Scala like API would
   be:
  - func -=(inout Self, T) -> Void
  - func -=(inout Self, S) -> Void
  - func -(T) -> Self
  - func -(all: S) -> Self
  - Similarly for & and +


Either of these naming patterns seems better than those proposed :(.

  -- Howard.

On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> I think Michel and Shawn did raise some good points here.
>
> -Thorsten
>
> Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution <
> swift-evolution@swift.org>:
>
> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > What is your evaluation of the proposal?
>>
>> I don't like "form" as a prefix. To me there is no difference between
>> `union` and `formUnion`: both sounds functional-style, and actually the
>> second one perhaps a bit more to my ears. There's basically two dictionary
>> definitions of "form":
>>
>> 1. "bring together parts or combine to create (something)" which to me
>> implies a new value is created, and
>> 2. "make or fashion into a certain shape or form" which would imply that
>> the material you start with is transformed, which is apparently the
>> intended meaning and also the reverse meaning from the above.
>>
>> I mean, doesn't this make sense as an API?
>>
>> let donut = baker.formDonut(dough) // non-mutating
>>
>> Perhaps instead of "form" we could use "become" as a prefix when the
>> operation is naturally described by a noun. That would seem less ambiguous
>> to me:
>>
>> a.becomeUnion(b)
>> a.becomeIntersection(b)
>> a.becomeSuccessor(b)
>>
>> It's a bit passive, but I find it fits well when the operation is a noun.
>>
>> And there's no way the term lends itself to non-mutating cases without
>> things becoming nonsensical:
>>
>> let donut = baker.becomeDonut(dough) // non-mutating?
>>
>
> I also am having difficulty coming to terms with the use of "form" (I am a
> native English speaker). As you note "form" can imply the creation of
> something from parts (more like assembling a new thing) as well as the
> creation of something out of a material say a of block clay (more like
> molding something out of an existing thing). It doesn't seem clear cut to
> me to imply in place mutation.
>
> Additionally my eyes / brain keep seeing "from" instead of "form". This
> type of issue is generally true with any short word made up of the same set
> of letters (made worse since "from" is more common in programming then
> "form"). The mind quickly narrows in on a set of possible words given the
> letters we see and then uses context to help get the correct one and/or
> additional visual parsing to understand the exact ordering of letters (more
> energy expended). Anyway since I keep seeing "from" instead of "form" I
> keep going in the direction of thinking it returns something made from the
> two (or more) items involved (not really sure why "from" goes that
> direction in my head, it could also go the in place direction).
>
> I would prefer something other then "form" (note I just typed "from" by
> mistake)... I think your suggestion of "become" has merit.
>
> y.becomeUnion(x) --reads to me as--> "y become union with x"
> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
> y.formIntersection(x) --read to me as--> "y from oops... y forming an
> intersection with x"
>
> In the "forming" situations it – to me – is ambiguous on if that is in
> place or not. To me it implies more of giving something new back.
>
> I am -1 on "form" aspect of this proposal. ...of course things are
> learnable as long as things are fairly consistent and not to far out of the
> norm for typical language use. Personally I don't see "form" as that
> typical in English.
>
> -Shawn
>
>
> ___
> 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] Custom operators

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

Thank you for a helpful answer!
I like the idea of overriding precedence from another module. We won't need
to introduce additional keywords or visibility for operators. I will add it
to the proposal.

I assume you mean precedence inside braces of operator, then operator scope
makes sense. Self operator could be omit as well, following the idea that
we are introducing a new operator and want to compare it to others:

infix operator * {
associativity: left
precedenceLess: ^
precedenceEqual: /
precedenceGreater: +
}
infix operator / {
associativity: left
precedenceLess: ^
precedenceEqual: *
precedenceGreater: +
}

Equivalent precedence rules would be allowed for symmetry in the operator
definitions.
We would still be able to reopen the scope and add precedence and
associativity rules.
I agree that this scheme has advantage of being a smaller change.

I'm still concerned about syntax.
Is it OK to have "less, equal, greater" in precedence name?
Is it OK to have both curly brackets and dictionary syntax (a precedent, I
guess)?
Is it OK to leave prefix and postfix operators always with empty braces?

Would it be better to have multiple precedence comparisons at once:
precedenceGreater: +, -, *, /
Or one comparison per line will be more readable?

I will add this to alternatives, but will not swap it with currently stated
syntax for now, waiting for some more response.

What do you think?

- Anton

2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger :

> See inline
>
> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution <
> swift-evolution@swift.org>:
>
> There is a problem here of duplicated operators or custom precedence, and
> how that gets passed between modules.
> Assume there are three modules, A, B and C. B defines a custom operator
> **. A and C each define a custom operator ++, and their meanings are
> different (though, even if their meanings were the same, I'm not sure if
> they could unify).
>
> Module D uses A and B as dependencies and sets a custom precedence on ++
> and **. Module E uses B and C and has a different precedence on ++ and **.
> You're working on Module F which uses D and E. Which ++ and which
> precedence does F get implicitly?
>
>
> We could allow operator precedence overriding to resolve ambiguity.
> However this overriding should only be module internal since it would
> override the existing precedences in the other modules.
>
> @AHTOH
> Why do you use #keyword ?
> I think defining a operator with
>
> infix operator + {
>  associativity: left
> }
>
> is perfectly fine since it is similar to class/struct/enum declaration.
>
> // and it's precedence
> precedence(+ lessThan *)
>
> Note the missing "," and ":" before and after "lessThan" in order to give
> both operators the same importance (minor issue).
>
> I feel that
>
> #precedence(+, lessThan: *)
>
> puts too much importance on the first operator.
>
> Best regards
> - Maximilian
>
> ___
> 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