Re: [swift-evolution] Enhanced Existentials

[Rod Brown via swift-evolution]

> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution 
>  wrote:
> 
> Hello Mailing-list,
> 
> I remember we discussed enhanced existentials heavily during the Swift 3 
> timeframe but postponed it. I was wondering if we need to bring back for 
> discussion during Phase 1 or Phase 2? For reference, here is the proposal 
> which Austin Zhend wrote which represented the culmination of the discussions:
> 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
> 
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I'm a big proponent of this - it's a limitation that is actually more capable 
in Obj-C than it is in Swift, and considering Swift's increased focus on 
Protocols, this seems rather baffling!

Would love to see this come forward into discussion.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

[Xiaodi Wu via swift-evolution]

It's not, as far as I'm aware, working on master.

In any case, though, Box(T()) would be just as ergonomic as Box() in
Swift, which I don't think is the case in Rust, and the former is already
possible without the need for conditional conformances.

On Tue, Jan 3, 2017 at 16:57 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jan 3, 2017, at 11:31 AM, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > All in all, I don’t really have an opinion on whether Default makes
> sense for Swift. Haven’t thought about it all that much. Swift is still
> missing the features that make case 1 and 2 even viable motivations
> (conditional conformance and derive annotations), and I believe already
> mandates default initializers in several of the cases where 3 is relevant.
> I *think* conditional conformance has already been accepted and just
> hasn’t been implemented yet, at least not in an official “can use to
> publish to app store” toolchain release.
>
> - Dave Sweeris
> ___
> 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] Add the DefaultConstructible protocol to the standard library

[David Sweeris via swift-evolution]

> On Jan 3, 2017, at 11:31 AM, Alexis via swift-evolution 
>  wrote:
> 
> All in all, I don’t really have an opinion on whether Default makes sense for 
> Swift. Haven’t thought about it all that much. Swift is still missing the 
> features that make case 1 and 2 even viable motivations (conditional 
> conformance and derive annotations), and I believe already mandates default 
> initializers in several of the cases where 3 is relevant.
I *think* conditional conformance has already been accepted and just hasn’t 
been implemented yet, at least not in an official “can use to publish to app 
store” toolchain release.

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

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

[Alexis via swift-evolution]

Since people keep chiming in with “Rust has this”, I figured I should give the 
context for what’s up with Default in Rust. Disclaimer: I wasn’t around for the 
actual design of this API, but I worked with it a lot. So any justification I 
give is mostly my own posthoc perception of the purpose it serves today. I’ll 
also be using Swift terminology/syntax here since there’s no interesting aspect 
of Rust involved in this design.

There are three major use-cases for Default, as I see it:


1) providing conditional default initializers for generic types
2) providing a standard hook for easily writing “obvious” default initializers 
3) refining another protocol for one-off convenience methods



The first case is easy. I have a `Mutex`, `Box`, `Rc`, etc. Generic 
types which require an instance of their generic type to exist. So of course 
their initializer requires a T. But it would be nice to not have to do this for 
types which have default constructors. So you have `extension Mutex: Default 
where T: Default`, and now you can do `Mutex()` where inference makes it clear 
what the type is. 

Here there’s no need to care about the “semantics” of Default. We’re just 
saying “if you can init() I can too!”. 




The second case is fairly Rust-specific, in that it combines with other 
features to make default initialization more ergonomic. Default provides a 
custom deriver, which makes a super convenient way to write default 
constructors for Plain Old Data types. #[derive(Default)] just says “yeah add a 
default initializer that loads up every field with its default”. Often this is 
done on a concrete type full of integers/optionals, in which case it’s 
synonymous with zeroing.

Since initializers in Swift are totally first-class, one could conceivably 
create this kind of Derive system without the need for protocols. Although 
#[derive(Default)] is generics-aware, so it can provide conditional 
conformances for generic types too.




The third case is the most complex (and niche). In effect, there are several 
places where you can make a slightly more ergonomic thing if you refine a 
protocol with “has a default initializer”. These default initializers are in no 
sense a requirement of the protocol, so including the initializer as a 
requirement of the protocol is incorrect. At the same time, no one really wants 
a bunch of adhoc DefaultConstructibleX protocols that are used by maybe one or 
two functions in the entire world. 

So Default is used as a universal modifier that can be applied to any protocol 
to create DefaultConstructibleX without anyone having to actually define or 
know about it. It’s a kind of retroactive modelling. If your type has some kind 
of reasonable default value, you conform to Default and maybe someone uses it. 
A particular user of `X + Default` then infers by example what a reasonable 
Default would mean in this context. 

Examples in Rust:



* H: BuildHasher + Default — Default applies the BuildHasher’s default seeding 
algorithm. For some algorithms this will go out to /dev/urandom, for others 
this will just set it to 0. That’s the call of the BuildHasher’s designer, and 
is hopefully made clear in its docs. However, there’s no reason why default 
constructibility is fundamental to a hashing algorithm. One could reasonably 
make the call that there isn’t a good default, and require it to be manually 
constructed. Possibly they could provide a couple wrappers which provide a 
clear default (MySecureHasher, MyWeakHasher).

This constraint is used by HashMap ’s default constructor. So in a 
sense this is just a more complex version of the first case, but we’re 
definitely inferring some semantics here. If a Default implementation doesn’t 
exist, then one must use HashMap’s with_hasher constructor to provide an 
instance of BuildHasher. 



* R: Rng + Default — same basic idea. Default seeding strategy so you don’t 
have to pass an instance of Rng. No reason why all Rng’s must be default 
constructible.



* T: Extend + Default — if something can be Extended and provides a default 
constructor, then presumably it’s some kind of collection. So default is 
presumed to be the empty collection. Again, Extend is more primitive then 
collections — one of the ends of a channel reasonably implements Extend, but 
default construction doesn’t make sense in that context. This is used by 

partition(predicate: (Item) -> Bool) -> (C, C)
where C: Extend + Default

which is basically just:



var yes = C()
var no = C()

for x in self {
  if predicate(x) {
yes.extend(x)
  } else {
no.extend(x)
  }
}

return (yes, no)


This is used similarly for unzip, which converts Iterator<(A, B)> to 
(CollectionOfA, CollectionOfB) 



This case represents a situation where the Rust and Swift devs have diverged a 
bit philosophically. There’s a tendency in the Rust community to make small 
“lego” protocols which you snap together to get the semantics you want on the 
off chance 

Re: [swift-evolution] Pattern matching with Arrays

[Joe Groff via swift-evolution]

> On Dec 22, 2016, at 7:43 PM, Robert Widmann  wrote:
> 
> Do you think there’s room for a more general Pattern Synonyms-like 
>  feature that could 
> extend this to things that look tuple-y?  We had a short conversation on 
> Twitter 'round about the release of Swift 1.2 about Swiftz’s HList 
>  
> implementation and my desire to be able to destructure them into tuples for 
> native pattern matching.

My personal favorite design for user-extensible pattern syntax is F#'s "active 
pattern" feature, which lets you declare a set of mutual exclusive, total or 
partial conditions along with a function body that computes which condition 
holds. For the specific case of container patterns, though, I feel like it's 
worth keeping a close association with Collection semantics, so that:

- [] matches when the incoming collection's startIndex == endIndex,
- [, ] fails if startIndex == endIndex, or else matches 
collection[startIndex] against  and recursively matches 
collection[startIndex.advancedBy(1)..

Re: [swift-evolution] Move placement of 'throws' statement

[Derrick Ho via swift-evolution]

John McCall +1
I agree. The placement should remain the same.
On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Wed Dec 28 2016, Chris Lattner  > wrote:
>
> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>
> it would be ambiguous to move the ‘throws’ keyword to the end of the
> function type, because you'd get:
>
>
> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>
>
> I see.
>
> We *could* say that the "throws" keyword comes after the return type
> unless it's a function type, in which case it comes after the return
> type's parameter list
>
>  let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>
> I admit this is a horrible rule from a language designer's point of view
> but there's a chance it could end up being better for users.
>
>
> Indeed this is horrid for an ivory tower language designer, but the
> pragmatic among them often have to make concessions to the real world.
> That said, I think this would be worse for typical swift programmers
> as well: it introduces multiple ways to do things,
>
>
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.
>
>
> Chris's point is that we can't stop allowing "throws" where it currently
> is, and
> therefore any proposal which allows it in a new place creates two ways of
> spelling the same thing.
>
> Also, your proposal reinterprets the currently-valid syntax:
>   (_ a : Int) -> (_ b : Float) throws -> Double
> Currently this means a non-throwing function that returns a throwing
> function.
> Your proposal flips it around.
>
> Also, I would find this extremely surprising as a user.  A core aspect of
> the
> first function type is written *inside* the second?  With all respect,
> Dave,
> that is just bizarre. :)
>
> I'm sorry if people dislike the placement of "throws", but that ship has
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems
> for
> negligible benefit.
>
> As I see it, the current syntax has one mild deficiency, called out
> previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or
> returns an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.
>
> For what it's worth, this visual ambiguity is precisely why I would insist
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>
> John.
>
>
>
> which work inconsistently and surprisingly in some cases.
>
> Here is a different way of looking at this: The predictable case is
> the one we already have now (and we wouldn’t take it away).  Is your
> beef with the current syntax so great that you think it is worth
> adding complexity to the language to privilege some special cases?
>
>
> Not really, no.
>
> --
> -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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

[Guillaume DIDIER via swift-evolution]

If I understand correctly we are speaking of class definitions inside 
functions, so this doesn't affect classes defined at the global scope, which 
are what the beginner will first be told. Teaching them about defining classes 
in other places would then wait until they know more about closure, scopes and 
variable capture.

I would suggest treating a class defined within a function body the same way a 
function defined within a function body would be.

Guillaume DIDIER (ASP)
Section Escrime, 3ème Compagnie, 
Promotion X 2014


—
ÉCOLE POLYTECHNIQUE
91128 PALAISEAU CEDEX
M. +33 (0)7 70 43 18 40
guillaume.did...@polytechnique.edu
www.polytechnique.edu
—

> Le 23 déc. 2016 à 23:49, David Sweeris via swift-evolution 
>  a écrit :
> 
> 
>> On Dec 23, 2016, at 1:37 PM, Xiaodi Wu  wrote:
>> 
>> This has been an idea brought up in the distant past about other features. 
>> The core team has said very clearly that they do not want "dialects" of 
>> Swift.
> 
> That puts the nail on it for me… if it’s already been rejected, I don’t want 
> to rehash it.
> 
> - Dave Sweeris
> ___
> 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] Replace named returns with `out` parameters?

[Andrew Arnopoulos via swift-evolution]

Adrian,

I'm not entirely sure I understand. Are you looking for a way to pass 
parameters by reference? Because there is a way to do that with the inout 
keyword. If not would you mind providing a different example to elaborate? 
Again, I think I may be missing your point.

-Andrew

> On Dec 28, 2016, at 4:09 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> compiles:
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[John McCall via swift-evolution]

> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Dec 28 2016, Chris Lattner  > wrote:
> 
>>> On Dec 28, 2016, at 9:52 AM, Dave Abrahams  wrote:
>>> 
 it would be ambiguous to move the ‘throws’ keyword to the end of the
 function type, because you'd get:
 
>> 
let x : (_ a : Int) -> (_ b: Float) -> Double throws throws
>>> 
>>> I see.  
>>> 
>>> We *could* say that the "throws" keyword comes after the return type
>>> unless it's a function type, in which case it comes after the return
>>> type's parameter list
>>> 
>>>  let x : (_ a : Int) -> (_ b: Float) throws -> Double throws
>>> 
>>> I admit this is a horrible rule from a language designer's point of view
>>> but there's a chance it could end up being better for users.
>> 
>> Indeed this is horrid for an ivory tower language designer, but the
>> pragmatic among them often have to make concessions to the real world.
>> That said, I think this would be worse for typical swift programmers
>> as well: it introduces multiple ways to do things, 
> 
> Do you mean it introduces multiple ways to do the *same* thing?  I
> didn't think I was introducing any of those.  If you think I was, you
> probably misunderstood my suggestion (or I did!), FWIW.

Chris's point is that we can't stop allowing "throws" where it currently is, and
therefore any proposal which allows it in a new place creates two ways of
spelling the same thing.

Also, your proposal reinterprets the currently-valid syntax:
  (_ a : Int) -> (_ b : Float) throws -> Double
Currently this means a non-throwing function that returns a throwing function.
Your proposal flips it around.

Also, I would find this extremely surprising as a user.  A core aspect of the
first function type is written *inside* the second?  With all respect, Dave,
that is just bizarre. :)

I'm sorry if people dislike the placement of "throws", but that ship has sailed,
and any attempt to "fix" it at this point is just going to cause problems for
negligible benefit.

As I see it, the current syntax has one mild deficiency, called out previously
in this thread: a reader has to recognize that "throws -> X" does not mean
that the function throws an X, but instead that it either throws or returns an 
X.
It's always nice when something is immediately obvious and doesn't have to
be explicitly learned, and I appreciate and mourn that my design may have
fallen short of that standard here. However, overall I still do think the syntax
is much cleaner than the alternatives, especially as return types grow more
complicated, and that this small rule is not at all difficult to master.

For what it's worth, this visual ambiguity is precisely why I would insist that
any typed-throws addition be spelled "throws(X)" instead of "throws X".

John.


> 
>> which work inconsistently and surprisingly in some cases.
>> 
>> Here is a different way of looking at this: The predictable case is
>> the one we already have now (and we wouldn’t take it away).  Is your
>> beef with the current syntax so great that you think it is worth
>> adding complexity to the language to privilege some special cases?
> 
> Not really, no.
> 
> -- 
> -Dave
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Switch statement tuple labels

[Alexis via swift-evolution]

If the input has labels, including them in the pattern has clear value: the 
compiler can check that the labels you expected are there, preventing value 
swapping bugs. Being able to omit the labels in the pattern is a reasonable 
convenience to avoid repeating yourself over and over. But being able to insert 
arbitrary labels that don’t match anything from the input is very weird, 
because it doesn’t really make anything more convenient or give the compiler 
fuel to catch mistakes. 

The proposal is essentially asking for slightly nicer syntax for comments in 
patterns. That is,


switch (1, 2) {
case (width: 0, height: 0): 
…
}


is entirely equivalent to:


switch (1, 2) {
case (/*width:*/ 0, /*height:*/ 0): 
…
}



That said, there’s a very clear inconsistency here between if-case-let and 
switch-case-let, which you would expect to be semantically equivalent:



let t1: (Int, Int) = (0, 0)

// This works
if case let (a: 0, b: y5) = t1 {
  print("hello")
}

// This doesn't
switch t1 {
case let (a: 0, b: y6): 
print("hallo")
}


So unless someone has a compelling argument that if-case-let and 
switch-case-let should be different, one of these should probably be changed. 
Unless the behaviour of if-case-let is *clearly* a random compiler bug that no 
one is relying on, then source stability dictates that switch should become 
more permissive and allow these “comment" labels. I don’t have enough 
background in this feature’s design to say either way.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Enhanced Existentials

[David Hart via swift-evolution]

Hello Mailing-list,

I remember we discussed enhanced existentials heavily during the Swift 3 
timeframe but postponed it. I was wondering if we need to bring back for 
discussion during Phase 1 or Phase 2? For reference, here is the proposal which 
Austin Zhend wrote which represented the culmination of the discussions:

https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
 


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