Re: [swift-evolution] Nil-rejection operator

[Brent Royal-Gordon via swift-evolution]

> On Feb 8, 2017, at 12:00 PM, Jack Newcombe via swift-evolution 
>  wrote:
> 
> I propose the introduction of a nil-rejection operator (represented here as 
> !!) as a complement to the above operators.
> .
> This operator should allow an equivalent behaviour to the forced unwrapping 
> of a variable, but with the provision of an error to throw in place of 
> throwing a fatal error.
> 
> - value !! Error :
>   if value is nil, throw non-fatal error
>   if value is not nil, return value
> 
> Example of how this syntax might work (Where CustomError: Error):
> 
>   let value = try optionalValue !! CustomError.failure

Rather than invent a new operator, I'd prefer to make `throw` an expression 
rather than a statement. Then you could write:

let value = optionalValue ?? throw CustomError.Failure

One issue here would be figuring out the proper return type for `throw`. 
Although if `Never` were a subtype-of-all-types, that would of course work. :^)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jens Alfke via swift-evolution]

> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> May I ask why with so many great open source forums that junk Discourse got 
> chosen? I'm very perplexed by this decision...

I’ve looked at a lot of forum software, and most of the open-source ones are 
pretty poor* in terms of UI and usability.
Discourse is very good as a web app, although its email integration doesn’t 
work that well IMHO, so it’s not really a direct replacement for a mailing list.
If I were proposing something, I’d propose groups.io . 
(Which is also not open source, sorry.)

—Jens

* I’m being diplomatic. Many of them are worse than poor. The word “wretched” 
comes to mind.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Dave Abrahams via swift-evolution]

on Wed Feb 08 2017, Xiaodi Wu  wrote:

> I agree very much with rationalizing access levels, but I'm not sure I like
> this proposal for public vs. closed. How would the compiler stop me from
> editing my own code if something is closed? The answer must be that it
> can't, so I can't see it as a co-equal to open but rather simply a
> statement of intention. 

IMO we are eventually going to need to have tools for analyzing ABI and
API breakage.  It's reasonable to think that such tools might be built
into the compiler.

-- 
-Dave

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

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

[Dave Abrahams via swift-evolution]

on Wed Feb 08 2017, Slava Pestov  wrote:

> Hah, Doug and I were just discussing this.

Funny thing; Nate Cook and I were just discussing the same thing today.
It seems like this hack we did in the standard library points to a
missing language feature; one with possible ABI impact.

-- 
-Dave

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

Re: [swift-evolution] Protocol requirement `where` clauses constraining associated types

[Slava Pestov via swift-evolution]

> On Feb 8, 2017, at 10:30 PM, Douglas Gregor  wrote:
> 
> 
>> On Feb 8, 2017, at 10:21 PM, Slava Pestov  wrote:
>> 
>> Hah, Doug and I were just discussing this.
>> 
>> In Swift 3.1, we generalized where clauses to allow them to add requirements 
>> on outer generic parameters. However we did not remove the diagnostic 
>> prohibiting a where clause from being attached to a non-generic method. In 
>> theory this can be made to work; the only slightly tricky thing is we will 
>> get a GenericParamList with zero parameters but non-zero requirements, which 
>> would require shuffling some things around to avoid assertions.
>> 
>> This would be a good starter project for someone who wanted to learn more 
>> about the generics system.
>> 
>> As for index(of:) and the specific details of the stdlib that are involved 
>> here, I have no idea — I’m just talking about the bogus diagnostic itself.
> 
> Well, I think Brent is talking about doing this on a protocol requirement, 
> which is more interesting because not all conforming types would satisfy the 
> requirement…

Since there would be no way to invoke the requirement on such a type, could we 
leave the entry blank in the witness table or emit a fatalError() thunk or 
something?

Slava

> 
>   - Doug
> 
>> 
>> Slava
>> 
>>> On Feb 8, 2017, at 9:57 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> In an article on `Collection` today*, Ole Begemann points out that 
>>> `index(of:)`, along with other `Equatable`- and `Comparable`-constrained 
>>> `Collection` methods, cannot be overridden. Actually, it *can* be, but only 
>>> through a private mechanism—there's a `_customIndexOfEquatableElement(_:)` 
>>> method that's invisible in the generated interface. But that only proves 
>>> the need for a way to make methods like these overridable.
>>> 
>>> The problem is that the `index(of:)` method should only be offered when the 
>>> element is `Equatable`—otherwise it simply won't work. But there's no way 
>>> to specify this rule in current Swift. In theory, we could describe such a 
>>> requirement with something like this:
>>> 
>>> func index(of element: Iterator.Element) -> Index? where 
>>> Iterator.Element: Equatable
>>> 
>>> But this is not permitted—you get an error indicating that `where` clauses 
>>> are only allowed on generic methods. Adding a spurious generic parameter 
>>> allows this code to compile, but with a deprecation warning indicating that 
>>> this is deprecated. I don't know if it would actually behave correctly, 
>>> however.
>>> 
>>> Is this a feature we should add? Is this the way to add it? Would it have 
>>> non-additive ABI impact? (The private `index(of:)` override would certainly 
>>> go away, but that's why it's private, I suppose.) I don't seem to remember 
>>> seeing something like this in the generics manifesto, so I thought it was 
>>> worth bringing up.
>>> 
>>> 
>>> 
>>> * https://oleb.net/blog/2017/02/sorted-array/
>>> 
>>> -- 
>>> 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

[swift-evolution] Is it possible to compile swift code to dynamic library ?

[Zheng Ping via swift-evolution]

Compile swift code to dynamic library(a *.so file which is compatible with
C), and let the *.so file can be linked directly by a pure C project.

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

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[David Hart via swift-evolution]

Hi Ted,

Thanks so much for taking time to discuss this with the team. I feel very 
confident this is going to be a big plus for the community :)

David

> On 9 Feb 2017, at 01:03, Ted kremenek via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> There was a long thread on swift-evolution about whether we should use modern 
> forum software — like Discourse — as an alternative to the mailing lists we 
> have now.  After a long discussion, the Core Team has decided to move 
> swift-evolution and swift-users to Discourse.
> 
> There are tradeoffs to moving to a forum.  The main advantages are:
> 
> - Easy for people to participate without subscribing to the entire mailing 
> list, as well as no need to provide email address to participate.  A lot of 
> people have voiced concern that they feel resistance to participate because 
> of needing to subscribe to a mailing list.
> 
> - Consistent affordances and rendering of content, including Markdown 
> support.  This is really useful for having technical discussions.
> 
> - Better searching of topics, archiving, etc.
> 
> - More tools for moderation.
> 
> - Topic cross-referencing, and consistent organization of topics instead of 
> whatever threading support a mail client provides (which is inconsistent).
> 
> I also want to consider moving the -dev lists to the same forum setup as 
> well; but that will be a separate conversation on those lists.
> 
> A rollout plan has not been figured out.  People are busy and there are 
> logistics to figure out.  I will be engaging a handful of members from the 
> community to help with the transition.  Specifically, there are those who 
> really value using email for participation on swift-evolution and 
> swift-users, and the goal is to get the forum setup to allow those people to 
> continue to feel effective when using email for discussions on these "lists".
> 
> More details will be announced as they get figured out, but I felt it was 
> important to let the community know about this direction.
> 
> Ted
> 
> 
> 
> 
> ___
> 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] Protocol requirement `where` clauses constraining associated types

[Douglas Gregor via swift-evolution]

> On Feb 8, 2017, at 10:21 PM, Slava Pestov  wrote:
> 
> Hah, Doug and I were just discussing this.
> 
> In Swift 3.1, we generalized where clauses to allow them to add requirements 
> on outer generic parameters. However we did not remove the diagnostic 
> prohibiting a where clause from being attached to a non-generic method. In 
> theory this can be made to work; the only slightly tricky thing is we will 
> get a GenericParamList with zero parameters but non-zero requirements, which 
> would require shuffling some things around to avoid assertions.
> 
> This would be a good starter project for someone who wanted to learn more 
> about the generics system.
> 
> As for index(of:) and the specific details of the stdlib that are involved 
> here, I have no idea — I’m just talking about the bogus diagnostic itself.

Well, I think Brent is talking about doing this on a protocol requirement, 
which is more interesting because not all conforming types would satisfy the 
requirement...

- Doug

> 
> Slava
> 
>> On Feb 8, 2017, at 9:57 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> In an article on `Collection` today*, Ole Begemann points out that 
>> `index(of:)`, along with other `Equatable`- and `Comparable`-constrained 
>> `Collection` methods, cannot be overridden. Actually, it *can* be, but only 
>> through a private mechanism—there's a `_customIndexOfEquatableElement(_:)` 
>> method that's invisible in the generated interface. But that only proves the 
>> need for a way to make methods like these overridable.
>> 
>> The problem is that the `index(of:)` method should only be offered when the 
>> element is `Equatable`—otherwise it simply won't work. But there's no way to 
>> specify this rule in current Swift. In theory, we could describe such a 
>> requirement with something like this:
>> 
>>  func index(of element: Iterator.Element) -> Index? where 
>> Iterator.Element: Equatable
>> 
>> But this is not permitted—you get an error indicating that `where` clauses 
>> are only allowed on generic methods. Adding a spurious generic parameter 
>> allows this code to compile, but with a deprecation warning indicating that 
>> this is deprecated. I don't know if it would actually behave correctly, 
>> however.
>> 
>> Is this a feature we should add? Is this the way to add it? Would it have 
>> non-additive ABI impact? (The private `index(of:)` override would certainly 
>> go away, but that's why it's private, I suppose.) I don't seem to remember 
>> seeing something like this in the generics manifesto, so I thought it was 
>> worth bringing up.
>> 
>> 
>> 
>> * https://oleb.net/blog/2017/02/sorted-array/
>> 
>> -- 
>> 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] Protocol requirement `where` clauses constraining associated types

[Slava Pestov via swift-evolution]

Hah, Doug and I were just discussing this.

In Swift 3.1, we generalized where clauses to allow them to add requirements on 
outer generic parameters. However we did not remove the diagnostic prohibiting 
a where clause from being attached to a non-generic method. In theory this can 
be made to work; the only slightly tricky thing is we will get a 
GenericParamList with zero parameters but non-zero requirements, which would 
require shuffling some things around to avoid assertions.

This would be a good starter project for someone who wanted to learn more about 
the generics system.

As for index(of:) and the specific details of the stdlib that are involved 
here, I have no idea — I’m just talking about the bogus diagnostic itself.

Slava

> On Feb 8, 2017, at 9:57 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> In an article on `Collection` today*, Ole Begemann points out that 
> `index(of:)`, along with other `Equatable`- and `Comparable`-constrained 
> `Collection` methods, cannot be overridden. Actually, it *can* be, but only 
> through a private mechanism—there's a `_customIndexOfEquatableElement(_:)` 
> method that's invisible in the generated interface. But that only proves the 
> need for a way to make methods like these overridable.
> 
> The problem is that the `index(of:)` method should only be offered when the 
> element is `Equatable`—otherwise it simply won't work. But there's no way to 
> specify this rule in current Swift. In theory, we could describe such a 
> requirement with something like this:
> 
>   func index(of element: Iterator.Element) -> Index? where 
> Iterator.Element: Equatable
> 
> But this is not permitted—you get an error indicating that `where` clauses 
> are only allowed on generic methods. Adding a spurious generic parameter 
> allows this code to compile, but with a deprecation warning indicating that 
> this is deprecated. I don't know if it would actually behave correctly, 
> however.
> 
> Is this a feature we should add? Is this the way to add it? Would it have 
> non-additive ABI impact? (The private `index(of:)` override would certainly 
> go away, but that's why it's private, I suppose.) I don't seem to remember 
> seeing something like this in the generics manifesto, so I thought it was 
> worth bringing up.
> 
> 
> 
> * https://oleb.net/blog/2017/02/sorted-array/
> 
> -- 
> 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

[swift-evolution] Protocol requirement `where` clauses constraining associated types

[Brent Royal-Gordon via swift-evolution]

In an article on `Collection` today*, Ole Begemann points out that 
`index(of:)`, along with other `Equatable`- and `Comparable`-constrained 
`Collection` methods, cannot be overridden. Actually, it *can* be, but only 
through a private mechanism—there's a `_customIndexOfEquatableElement(_:)` 
method that's invisible in the generated interface. But that only proves the 
need for a way to make methods like these overridable.

The problem is that the `index(of:)` method should only be offered when the 
element is `Equatable`—otherwise it simply won't work. But there's no way to 
specify this rule in current Swift. In theory, we could describe such a 
requirement with something like this:

func index(of element: Iterator.Element) -> Index? where 
Iterator.Element: Equatable

But this is not permitted—you get an error indicating that `where` clauses are 
only allowed on generic methods. Adding a spurious generic parameter allows 
this code to compile, but with a deprecation warning indicating that this is 
deprecated. I don't know if it would actually behave correctly, however.

Is this a feature we should add? Is this the way to add it? Would it have 
non-additive ABI impact? (The private `index(of:)` override would certainly go 
away, but that's why it's private, I suppose.) I don't seem to remember seeing 
something like this in the generics manifesto, so I thought it was worth 
bringing up.



* https://oleb.net/blog/2017/02/sorted-array/

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

There will be discussions about each of the mailing lists on whether or not to 
move to Discourse.  My preference is that all of the mailing lists move, but 
the needs of the different lists are slightly different and I didn't want to 
gate moving swift-evolution to a forum based on the outcome of those 
discussions.  It is clear there is a real need that is solved by moving 
swift-evolution to a forum, and I want to get that moving.  As it is, this will 
take some effort to make happen, and likely by that point we'll have settled 
what to do with the other mailing lists.

> On Feb 8, 2017, at 9:50 PM, Muse M via swift-evolution 
>  wrote:
> 
> I don't see any discussions to have Swift Server Side shift to Discourse 
> forum too?
> 
>> On Thursday, February 9, 2017, James Hillhouse via swift-evolution 
>>  wrote:
>> I'll echo Nick and Joshua–thanks Swift Core team for taking the time to 
>> decide on this change.
>> 
>> Jim
>> 
>> 
>> > On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution 
>> >  wrote:
>> >
>> > I second this praise. FWIW, I recently installed Discourse using a 
>> > DigitalOcean droplet, and it couldn't have been easier. Upgrades are 
>> > surprisingly easy, too.
>> >
>> > I have yet to figure out the email integration; I hope you can get that 
>> > working.
>> >
>> > I also hope you give some effort to improving on the default Discourse 
>> > look. It's not bad, but I feel like it doesn't do a good job of 
>> > delineating functional areas on the page. Having said that, I'm more than 
>> > happy to wait indefinitely for such an improvement; it's not worth holding 
>> > up the roll-out.
>> >
>> > Thanks again!
>> >
>> >> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution 
>> >>  wrote:
>> >>
>> >> 
>> >> This is an awesome decision and a huge enhancement for the Swift 
>> >> community. Thanks (Core Team) for taking the time to entertain the 
>> >> discussion and move forward with what many community members have wanted.
>> >>
>> >> Alvarado, Joshua
>> >>
>> >>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> There was a long thread on swift-evolution about whether we should use 
>> >>> modern forum software — like Discourse — as an alternative to the 
>> >>> mailing lists we have now.  After a long discussion, the Core Team has 
>> >>> decided to move swift-evolution and swift-users to Discourse.
>> >>>
>> >>> There are tradeoffs to moving to a forum.  The main advantages are:
>> >>>
>> >>> - Easy for people to participate without subscribing to the entire 
>> >>> mailing list, as well as no need to provide email address to 
>> >>> participate.  A lot of people have voiced concern that they feel 
>> >>> resistance to participate because of needing to subscribe to a mailing 
>> >>> list.
>> >>>
>> >>> - Consistent affordances and rendering of content, including Markdown 
>> >>> support.  This is really useful for having technical discussions.
>> >>>
>> >>> - Better searching of topics, archiving, etc.
>> >>>
>> >>> - More tools for moderation.
>> >>>
>> >>> - Topic cross-referencing, and consistent organization of topics instead 
>> >>> of whatever threading support a mail client provides (which is 
>> >>> inconsistent).
>> >>>
>> >>> I also want to consider moving the -dev lists to the same forum setup as 
>> >>> well; but that will be a separate conversation on those lists.
>> >>>
>> >>> A rollout plan has not been figured out.  People are busy and there are 
>> >>> logistics to figure out.  I will be engaging a handful of members from 
>> >>> the community to help with the transition.  Specifically, there are 
>> >>> those who really value using email for participation on swift-evolution 
>> >>> and swift-users, and the goal is to get the forum setup to allow those 
>> >>> people to continue to feel effective when using email for discussions on 
>> >>> these "lists".
>> >>>
>> >>> More details will be announced as they get figured out, but I felt it 
>> >>> was important to let the community know about this direction.
>> >>>
>> >>> Ted
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> 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
>> >
>> >
>> > --
>> > Rick Mann
>> > rm...@latencyzero.com
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Muse M via swift-evolution]

I don't see any discussions to have Swift Server Side shift to Discourse
forum too?

On Thursday, February 9, 2017, James Hillhouse via swift-evolution <
swift-evolution@swift.org> wrote:

> I'll echo Nick and Joshua–thanks Swift Core team for taking the time to
> decide on this change.
>
> Jim
>
>
> > On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> > I second this praise. FWIW, I recently installed Discourse using a
> DigitalOcean droplet, and it couldn't have been easier. Upgrades are
> surprisingly easy, too.
> >
> > I have yet to figure out the email integration; I hope you can get that
> working.
> >
> > I also hope you give some effort to improving on the default Discourse
> look. It's not bad, but I feel like it doesn't do a good job of delineating
> functional areas on the page. Having said that, I'm more than happy to wait
> indefinitely for such an improvement; it's not worth holding up the
> roll-out.
> >
> > Thanks again!
> >
> >> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>
> >> 
> >> This is an awesome decision and a huge enhancement for the Swift
> community. Thanks (Core Team) for taking the time to entertain the
> discussion and move forward with what many community members have wanted.
> >>
> >> Alvarado, Joshua
> >>
> >>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>>
> >>> Hi everyone,
> >>>
> >>> There was a long thread on swift-evolution about whether we should use
> modern forum software — like Discourse — as an alternative to the mailing
> lists we have now.  After a long discussion, the Core Team has decided to
> move swift-evolution and swift-users to Discourse.
> >>>
> >>> There are tradeoffs to moving to a forum.  The main advantages are:
> >>>
> >>> - Easy for people to participate without subscribing to the entire
> mailing list, as well as no need to provide email address to participate.
> A lot of people have voiced concern that they feel resistance to
> participate because of needing to subscribe to a mailing list.
> >>>
> >>> - Consistent affordances and rendering of content, including Markdown
> support.  This is really useful for having technical discussions.
> >>>
> >>> - Better searching of topics, archiving, etc.
> >>>
> >>> - More tools for moderation.
> >>>
> >>> - Topic cross-referencing, and consistent organization of topics
> instead of whatever threading support a mail client provides (which is
> inconsistent).
> >>>
> >>> I also want to consider moving the -dev lists to the same forum setup
> as well; but that will be a separate conversation on those lists.
> >>>
> >>> A rollout plan has not been figured out.  People are busy and there
> are logistics to figure out.  I will be engaging a handful of members from
> the community to help with the transition.  Specifically, there are those
> who really value using email for participation on swift-evolution and
> swift-users, and the goal is to get the forum setup to allow those people
> to continue to feel effective when using email for discussions on these
> "lists".
> >>>
> >>> More details will be announced as they get figured out, but I felt it
> was important to let the community know about this direction.
> >>>
> >>> Ted
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com 
> >
> >
> > ___
> > 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] Plan to move swift-evolution and swift-users mailing lists to Discourse

[James Hillhouse via swift-evolution]

I'll echo Nick and Joshua–thanks Swift Core team for taking the time to decide 
on this change. 

Jim


> On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> I second this praise. FWIW, I recently installed Discourse using a 
> DigitalOcean droplet, and it couldn't have been easier. Upgrades are 
> surprisingly easy, too.
> 
> I have yet to figure out the email integration; I hope you can get that 
> working.
> 
> I also hope you give some effort to improving on the default Discourse look. 
> It's not bad, but I feel like it doesn't do a good job of delineating 
> functional areas on the page. Having said that, I'm more than happy to wait 
> indefinitely for such an improvement; it's not worth holding up the roll-out.
> 
> Thanks again!
> 
>> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution 
>>  wrote:
>> 
>> 
>> This is an awesome decision and a huge enhancement for the Swift community. 
>> Thanks (Core Team) for taking the time to entertain the discussion and move 
>> forward with what many community members have wanted. 
>> 
>> Alvarado, Joshua
>> 
>>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution 
>>>  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> There was a long thread on swift-evolution about whether we should use 
>>> modern forum software — like Discourse — as an alternative to the mailing 
>>> lists we have now.  After a long discussion, the Core Team has decided to 
>>> move swift-evolution and swift-users to Discourse.
>>> 
>>> There are tradeoffs to moving to a forum.  The main advantages are:
>>> 
>>> - Easy for people to participate without subscribing to the entire mailing 
>>> list, as well as no need to provide email address to participate.  A lot of 
>>> people have voiced concern that they feel resistance to participate because 
>>> of needing to subscribe to a mailing list.
>>> 
>>> - Consistent affordances and rendering of content, including Markdown 
>>> support.  This is really useful for having technical discussions.
>>> 
>>> - Better searching of topics, archiving, etc.
>>> 
>>> - More tools for moderation.
>>> 
>>> - Topic cross-referencing, and consistent organization of topics instead of 
>>> whatever threading support a mail client provides (which is inconsistent).
>>> 
>>> I also want to consider moving the -dev lists to the same forum setup as 
>>> well; but that will be a separate conversation on those lists.
>>> 
>>> A rollout plan has not been figured out.  People are busy and there are 
>>> logistics to figure out.  I will be engaging a handful of members from the 
>>> community to help with the transition.  Specifically, there are those who 
>>> really value using email for participation on swift-evolution and 
>>> swift-users, and the goal is to get the forum setup to allow those people 
>>> to continue to feel effective when using email for discussions on these 
>>> "lists".
>>> 
>>> More details will be announced as they get figured out, but I felt it was 
>>> important to let the community know about this direction.
>>> 
>>> Ted
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] SE-0152: Package Manager Tools Version

[Rick Ballard via swift-evolution]

> The review of SE-0152 "Package Manager Tools Version" begins now and runs 
> through February 13, 2017.  The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md
>  
> 
Hi Will,

Thanks for taking the time to review this.

Is there a particular reason you're envisioning that we might need to extend 
the metadata for the Swift tools version?

We've left ourself an escape hatch in case we ever do need to, where anything 
after a  ';' character in the tools version comment will be ignored for now, 
but I'm not expecting that we'll ever need to use that escape hatch. The Swift 
tools version itself needs to be stored in a special way since it dictates how 
we'll interpret the manifest, but once we've determined that, all other data 
should be able to be stored as Swift code in the manifest as per usual.

If you can think of some good reasons why we'd actually need this 
extensibility, please do suggest them. Otherwise I'd hope that we wouldn't need 
to choose a less convenient mechanism here for the sake of more convenient 
extensibility that will likely never be used.

Thanks,

- Rick

> On Feb 8, 2017, at 10:49 AM, Will Field-Thompson via swift-evolution 
>  wrote:
> 
>  
>   *  What is your evaluation of the proposal?
> 
> I fully support the goals of the proposal and have a question about the 
> implementation.
> 
>   *  Is the problem being addressed significant enough to warrant a 
> change to Swift?
> 
> Yep. It provides a good way to evolve the API, and putting it in place for 
> Swift 3.1 gives us the freedom to evolve the API as (or if) needed for Swift 
> 4.
> 
>   *  Does this proposal fit well with the feel and direction of Swift?
> 
> I agree that the placement of the tools version in a comment is unfortunate, 
> but I think that it's the best way to include it in Package.swift.
> 
> I'm interested in other people's thoughts on a .swift-tools-version file. I'm 
> not sure I prefer it to the comment in Package.swift, but the reasons 
> included in the proposal don't convince me the .swift-tools-version shouldn't 
> be used either.
> Eliminates the possibility of including either Package.swift or 
> .swift-tools-version: Seems like exactly the kind of mistake you make once 
> and then don't make again. I guess with a leading dot it's more likely to be 
> forgotten than a non-dot-file, but not a major issue IMO.
> Users may like to see the version in the Package.swift: Probably true, though 
> I'm not sure how much of an issue it is.
> Are these significant problems for other people? They don't seem that way to 
> me, but I may not represent the majority here as my work is in iOS dev and 
> the only time I get to use swiftpm is for side projects. 
> 
> The .swift-tools-version has the advantage that it is extendable in a 
> prettier (i.e. easier to read and easier to diff for VCS purposes) way than 
> the semicolon-separated syntax from the proposal. How likely is it that we'll 
> ever have to extend it? I think that, for me, is the determining factor for 
> which format I prefer.
> 
>   *  If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> The main package manager I use is CocoaPods and as far as I am aware 
> CocoaPods doesn't allow you to specify the tools version in the Podfile. This 
> did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I think 
> Podfile.lock records the version of CocoaPods, but I don't think that 
> actually helps in this regard.
> 
>   *  How much effort did you put into your review?  A glance, a quick 
> reading, or an in-depth study?
>  
> I spent some time reading through the proposal, but I lost track of the 
> discussion pre-proposal.
> 
> - Will

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

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Rick Mann via swift-evolution]

I second this praise. FWIW, I recently installed Discourse using a DigitalOcean 
droplet, and it couldn't have been easier. Upgrades are surprisingly easy, too.

I have yet to figure out the email integration; I hope you can get that working.

I also hope you give some effort to improving on the default Discourse look. 
It's not bad, but I feel like it doesn't do a good job of delineating 
functional areas on the page. Having said that, I'm more than happy to wait 
indefinitely for such an improvement; it's not worth holding up the roll-out.

Thanks again!

> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution 
>  wrote:
> 
> 
> This is an awesome decision and a huge enhancement for the Swift community. 
> Thanks (Core Team) for taking the time to entertain the discussion and move 
> forward with what many community members have wanted. 
> 
> Alvarado, Joshua
> 
>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution 
>>  wrote:
>> 
>> Hi everyone,
>> 
>> There was a long thread on swift-evolution about whether we should use 
>> modern forum software — like Discourse — as an alternative to the mailing 
>> lists we have now.  After a long discussion, the Core Team has decided to 
>> move swift-evolution and swift-users to Discourse.
>> 
>> There are tradeoffs to moving to a forum.  The main advantages are:
>> 
>> - Easy for people to participate without subscribing to the entire mailing 
>> list, as well as no need to provide email address to participate.  A lot of 
>> people have voiced concern that they feel resistance to participate because 
>> of needing to subscribe to a mailing list.
>> 
>> - Consistent affordances and rendering of content, including Markdown 
>> support.  This is really useful for having technical discussions.
>> 
>> - Better searching of topics, archiving, etc.
>> 
>> - More tools for moderation.
>> 
>> - Topic cross-referencing, and consistent organization of topics instead of 
>> whatever threading support a mail client provides (which is inconsistent).
>> 
>> I also want to consider moving the -dev lists to the same forum setup as 
>> well; but that will be a separate conversation on those lists.
>> 
>> A rollout plan has not been figured out.  People are busy and there are 
>> logistics to figure out.  I will be engaging a handful of members from the 
>> community to help with the transition.  Specifically, there are those who 
>> really value using email for participation on swift-evolution and 
>> swift-users, and the goal is to get the forum setup to allow those people to 
>> continue to feel effective when using email for discussions on these "lists".
>> 
>> More details will be announced as they get figured out, but I felt it was 
>> important to let the community know about this direction.
>> 
>> Ted
>> 
>> 
>> 
>> 
>> ___
>> 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


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Joshua Alvarado via swift-evolution]


This is an awesome decision and a huge enhancement for the Swift community. 
Thanks (Core Team) for taking the time to entertain the discussion and move 
forward with what many community members have wanted. 

Alvarado, Joshua

> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> There was a long thread on swift-evolution about whether we should use modern 
> forum software — like Discourse — as an alternative to the mailing lists we 
> have now.  After a long discussion, the Core Team has decided to move 
> swift-evolution and swift-users to Discourse.
> 
> There are tradeoffs to moving to a forum.  The main advantages are:
> 
> - Easy for people to participate without subscribing to the entire mailing 
> list, as well as no need to provide email address to participate.  A lot of 
> people have voiced concern that they feel resistance to participate because 
> of needing to subscribe to a mailing list.
> 
> - Consistent affordances and rendering of content, including Markdown 
> support.  This is really useful for having technical discussions.
> 
> - Better searching of topics, archiving, etc.
> 
> - More tools for moderation.
> 
> - Topic cross-referencing, and consistent organization of topics instead of 
> whatever threading support a mail client provides (which is inconsistent).
> 
> I also want to consider moving the -dev lists to the same forum setup as 
> well; but that will be a separate conversation on those lists.
> 
> A rollout plan has not been figured out.  People are busy and there are 
> logistics to figure out.  I will be engaging a handful of members from the 
> community to help with the transition.  Specifically, there are those who 
> really value using email for participation on swift-evolution and 
> swift-users, and the goal is to get the forum setup to allow those people to 
> continue to feel effective when using email for discussions on these "lists".
> 
> More details will be announced as they get figured out, but I felt it was 
> important to let the community know about this direction.
> 
> Ted
> 
> 
> 
> 
> ___
> 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] Partial Ranges (was: Strings in Swift 4)

[Ben Cohen via swift-evolution]

Hi Jonathan,

It looks like the majority of this is about finite vs infinite collections. 
This should be a separate thread, and one we certainly need to have, but 
doesn’t need to be mixed together with the wider one-sided ranges discussion. 
For now, I think it’s reasonable to say that 1) left-one-sided ranges of 
countable things can be sequences, 2) right-sided ranges shouldn’t, and 3) if 
infinite collections end up being a thing, left-sided ranges should be one.


> On Feb 7, 2017, at 9:18 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 
>>> Oh, sorry, I was referring to an earlier post I made in this thread,
>>> but didn’t make that clear.  I’ll give a longer explanation of my
>>> reasoning behind the statement that partial ranges shouldn’t conform
>>> to Sequence (on their own) below... but the short version is that the
>>> conformance, like cake, is a lie... and we are using the trap to lie
>>> to ourselves about it.
>> 
>> *If* the trap is a lie (and I'm not saying it is), it's a lie we tell
>> ourselves about Int, because practically speaking, most people can't
>> program correctly always keeping in mind that Int has finite expressive
>> range.  This is a conscious decision made by the Swift language a long
>> time ago.  It is *not* a lie about ranges, but if you make a range based
>> on Int it will contain a lie, just like everything else that uses Int.
> 
> I think I touched a 3rd rail here by mentioning trapping.  Trapping is a 
> symptom of a design issue here, not the underlying problem.
> 
> I wasn’t saying that the trap itself is a lie, just that it lets us lie to 
> ourselves about how the types fit together.  Basically we are trying to shove 
> things into collection which aren’t collections, and then things like ‘count’ 
> and ‘dropLast()’ start failing. You can no longer write reliable generic code 
> under those conditions.
> 
> I am not arguing against trapping in general here, or that Int shouldn’t 
> trap.  I am saying that PartialRange and Collection don’t mesh correctly, and 
> it is REALLY useful for them to mesh correctly.  I am also saying that 
> problem can be fixed by providing an upper bound (such as Int.max) instead of 
> saying it is infinite (with respect to Collection).  As you pointed out, for 
> something like Int, it won’t even get to the trap before locking up the 
> computer by counting through billions of numbers anyway, so it shouldn’t make 
> much practical difference there.  It will make a big practical difference in 
> being able to call things like ‘count’ and ‘dropLast()’ and write generic 
> code that works for all Collections.
> 
> 
> 
>>> If we continue down this path, we will find more and more edge cases
>>> that need to be papered over, until the design eventually needs to be
>>> scrapped or buttressed with compiler magic.  For example, let’s say we
>>> define a PartialRange as a simple struct with optional endpoints, then
>>> we conform it to Sequence.  Now we can say ’n…’ and get a sequence.
>>> But what happens when we say ‘…n’?  
>> 
>> You don't get a Sequence.
>> 
>>> Where does that sequence start if it has an implicit start point of
>>> negative infinity?  Well, we promised a Sequence, so our only real
>>> option is to trap (for some types anyway).  For UInt, ‘…n’ is a
>>> perfectly valid sequence (though we could trap on that as well for
>>> consistency sake and say that you have to say '0…n’).  We are using
>>> trapping to let us ignore the fact that we are promising something
>>> (conformance to Sequence) that isn’t really true...
>> 
>> This is a red herring.  Nobody has proposed making ...n a Sequence.
> 
> If ’n…’ and ‘…n’ are represented by different types, then I remove my 
> objection about adhering to Sequence.  I could have sworn the last version I 
> saw had them as a single type (and thus there was no way to enable one 
> without the other), but that may not have been an official version.  If they 
> are separate types, then it isn’t an issue (and trapping when the sequence 
> reaches above Int’s limit is perfectly fine here). 
> 

Don’t worry, you’re not imagining it :)

There have been some prototypes pass by on this list of one-sided ranges where 
left- and right-sided ranges were covered by the same type. I think one example 
had it so the upper and lower bound were optional. This has the benefit of 
simplicity, but misses out on the opportunity for the type system to enforce 
certain behavior so I don’t think would be the final implementation we want.

> I am still worried about adhering to Collection though.
> 
> 

Will take this up on a separate thread.

>> We had several discussions about infinite collections last year.  My
>> conclusion was that they were useful and there was no reason to prohibit
>> them, so we should lift the reachability requirement for endIndex.
> 
> I agree that it could be useful, but I believe we need to be able to spell 
> infinite collections differently than 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

Hurray, I cannot wait to get the consistent behavior of open/public protocols. 
I’m not sure I could follow the idea behind the proposed closed keyboard/access 
modifier. It almost felt like closed == final public, am I mistaken something 
here?

Furthermore, I really would love if the community could revisit how open/public 
really should behave. When open was implemented and I tried it out without 
reading the proposal first I bumped into things like open init() which felt 
really odd. I understand the argumentation from the proposal, but it feels 
wrong and inconsistent to me.

Here’s how I would have imagined open vs. public. IMHO public should really 
mean, you cannot subclass, conform or override something in module B from 
module A.

Modified samples from SE–0117:

// This class is not subclassable outside of ModuleA.
public class NonSubclassableParentClass {
// This method >is not overridable outside of ModuleA.
public func foo() {}

// This method is not overridable outside of ModuleA because
// its class restricts its access level.
// It is INVALID to declare it as `open`.
public func bar() {}

// The behavior of `final` methods remains unchanged.
public final func baz() {}
}

// This class is subclassable both inside and outside of ModuleA.
open class SubclassableParentClass {
 
// Designated initializer that is not overridable outside ModuleA
public init()
 
// Another designated initializer that is overridable outside ModuleA
open init(foo: Int)
 
// This property is not overridable outside of ModuleA.
public var size : Int

// This method is not overridable outside of ModuleA.
public func foo() {}

// This method is overridable both inside and outside of ModuleA.
open func bar() {}

/// The behavior of a `final` method remains unchanged.
public final func baz() {}
}

/// The behavior of `final` classes remains unchanged.
public final class FinalClass { }
/// ModuleB:

import ModuleA

// This is allowed since the superclass is `open`.
class SubclassB : SubclassableParentClass {
 
// Iff certain conditions are met, the superclass initializers are 
inherited.
// `init` will stay `public` and won't be overridable.
//
// If the conditions are not met, then `init` is not inherited. That does 
not
// mean that we can create a new designated `init` that matches it's 
superclass's
// designated initializer. The behavior should be consistent, like the  
// superclass's function `foo` is reserved and not overridable, so is `init`
// reserved in this case and not overridable.
 
// This is allowed since the superclass's initializer is `open`
override init(foo: Int) {
super.init(foo: foo)
}
 
init(bar: Int) {
// We could call a super designated initializer from here
super.init()
// or
super.init(foo: bar)
}
 
// This is invalid because it overrides a method that is
// defined outside of the current module but is not `open'.
override func foo() { }

// This is allowed since the superclass's method is overridable.
// It does not need to be marked `open` because it is defined on
// an `internal` class.
override func bar() { }
}
required should always match the same scope level as the type in which it’s 
defined. That means if the class is open, than any of it’s required 
initializers will be open as well.



-- 
Adrian Zubarev
Sent with Airmail

Am 9. Februar 2017 um 00:49:04, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

I agree very much with rationalizing access levels, but I'm not sure I like 
this proposal for public vs. closed. How would the compiler stop me from 
editing my own code if something is closed? The answer must be that it can't, 
so I can't see it as a co-equal to open but rather simply a statement of 
intention. Therefore I think use cases for the proposed behavior of closed 
would be better served by annotations and proper semantic versioning.

As this change didn't seem in scope for Swift 4 phase 1, I've held off on 
discussing my own thoughts on access levels. The idea I was going to propose in 
phase 2 was to have simply open and public enums (and protocols). I really 
think that completes access levels in a rational way without introducing 
another keyword.
On Wed, Feb 8, 2017 at 17:05 Matthew Johnson via swift-evolution 
 wrote:
I’ve been thinking a lot about our public access modifier story lately in the 
context of both protocols and enums.  I believe we should move further in the 
direction we took when introducing the `open` keyword.  I have identified what 
I think is a promising direction and am interested in feedback from the 
community.  If community feedback is positive I will flesh this out into a more 
complete proposal draft.


Background and Motivation:

In Swift 3 we had an extended debate 

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

Hi Jan,

There was a lot of discussion — albeit not on swift-users — and Discourse was 
the one put forward that those that were pro-forum were most advocating.  I 
actually didn't hear alternative forum software get strongly advocated.

Specific things about Discourse (which may be offered by other solutions):

- Good archiving and searching.
- Markdown support.
- Email bridging to those who still want to have a "mailing list" experience.
- Easy participation without needing to subscribe to a high-volume mailing list.

Not all of these benefits are specific to Discourse.

I'm happy to hear your thoughts, but I'd need more precise feedback than 
adjectives like "junk" to weigh in your concerns.  Specific suggestions for 
something better, and why they are better, would be great.

The key decision here is to move away from mailing lists.  Discourse so far 
seems like the best candidate put forth.

Ted


> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> May I ask why with so many great open source forums that junk Discourse got 
> chosen? I'm very perplexed by this decision...
> 
> Jan
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

Hi everyone,

There was a long thread on swift-evolution about whether we should use modern 
forum software — like Discourse — as an alternative to the mailing lists we 
have now.  After a long discussion, the Core Team has decided to move 
swift-evolution and swift-users to Discourse.

There are tradeoffs to moving to a forum.  The main advantages are:

- Easy for people to participate without subscribing to the entire mailing 
list, as well as no need to provide email address to participate.  A lot of 
people have voiced concern that they feel resistance to participate because of 
needing to subscribe to a mailing list.

- Consistent affordances and rendering of content, including Markdown support.  
This is really useful for having technical discussions.

- Better searching of topics, archiving, etc.

- More tools for moderation.

- Topic cross-referencing, and consistent organization of topics instead of 
whatever threading support a mail client provides (which is inconsistent).

I also want to consider moving the -dev lists to the same forum setup as well; 
but that will be a separate conversation on those lists.

A rollout plan has not been figured out.  People are busy and there are 
logistics to figure out.  I will be engaging a handful of members from the 
community to help with the transition.  Specifically, there are those who 
really value using email for participation on swift-evolution and swift-users, 
and the goal is to get the forum setup to allow those people to continue to 
feel effective when using email for discussions on these "lists".

More details will be announced as they get figured out, but I felt it was 
important to let the community know about this direction.

Ted




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

Re: [swift-evolution] I think we need more to our type calculus

[Slava Pestov via swift-evolution]

> On Feb 8, 2017, at 12:09 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> I’ve been trying to get the maximum of a list of counts. I started by using 
> “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I 
> should really use the value closest to negative infinity as the base. The 
> problem is how to get that value. The current hard-coded “0” works because 
> the count type ultimately aliases “Int”, but shouldn’t have to count on that. 
> I put in “MyCountType.min”, where “MyCountType” is hard coded from the docs 
> of “myCountProperty”, but I shouldn’t have to do that either.
> 
> There is a “type(of:)” global function, which I did use. But not only did I 
> have to make up an expression to go in there, its return value, some sort of 
> meta-type stuff I don’t understand, can’t be used on the right side of a 
> “typealias” construct. I ultimately used “let lowestCount = type(of: 
> anElement.myCountProperty).min” to get what I needed.
> 
> Some queries/requests:
> 
> 1. Is the expression within “type(of:)” evaluated?

Yes. Eg,

class Base {}
class Derived : Base {}

func foo() -> Base { return Derived() }

type(of: foo()) // this is Derived.self, not Base.self

> 2. I think we need the equivalent of "std::declval” from C++. Especially if 
> the answer to (1) is yes.
> 3. Why isn’t the return type(?) of “type(of:)” compile-time enough to be used 
> as a type-alias?

type(of:) is not a real function because it’s return type depends on the input 
type in a funny way. If the input type T is an existential, then type(of:) 
returns an existential metatype; otherwise, it returns a concrete metatype. So 
it’s almost as if the signature is (T) -> (T.Type), but not quite.

Slava

> 4. Should we add something like the C++ type-traits collection of generic 
> structures to give use type information as type-aliases or type-level 
> instances?
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 
> 
> ___
> 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] [Discussion] mailing list alternative

[Ted kremenek via swift-evolution]

There has been a tremendous amount of participation on this thread, with some 
extremely thoughtful analysis of how the mailing list serves the community and 
the tradeoffs of moving to a forum, like Discourse.

I've been thinking about the points made on this thread as well as looking at 
the experimental Discourse setup that Nate Cook provided.  While there are 
tradeoffs with moving swift-evolution to Discourse, I think the benefits 
outweigh the negatives.

After discussing this with the Core Team, the decision is to move 
swift-evolution and swift-users to Discourse.  I will also bring it up for 
discussion on the -dev mailing lists to do the same there, so that we all are 
using consistent infrastructure.

No rollout plan has been established yet.  People are busy, and there are a 
variety of logistics to figure out.  My intent is to engage with a handful of 
people across the community on helping with the transition, including making 
sure we configure Discourse properly so we have the best experience for those 
who want to continue to use email.  We also want to import the history of the 
mailing list as well so that we do not lose valuable conversation.  As a 
rollout plan gets figured out it will get communicated.

I realize that many people aren't following this thread anymore, so I'll send 
out a separate email just so people don't miss the decision.  Thank you all to 
EVERYONE who participated in this thread and expressed an opinion.

Ted


> On Jan 23, 2017, at 8:02 AM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> Hey swifters,
>   I would like to (re)open up discussion on moving away from email for the 
> swift evolution mailing list. I know this has probably been discussed before 
> but it really should be addressed again. I wouldn't even know how to find if 
> it has been discussed before because it would be too hard to go back through 
> the history. 
> 
> The main factors to move away from email is because email may deter 
> newcomers, history, and threads. I may be speaking for myself when saying 
> email may intimidate newcomers from expressing their opinions and thoughts. 
> It is hard to know what has already been discussed and who is even in the 
> active conversation. Keeping track of history is a pain as well. Searching 
> through many emails to find who said what and when is not effective in email 
> clients. Also, code formatting in emails is not effective. Let's discuss and 
> actually make an action to move away from email if the community so agrees. 
> Of course, recommendations are Slack, Hipchat (-1), and Gitter.
> 
> -- 
> Joshua Alvarado
> alvaradojosh...@gmail.com
> ___
> 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] consistent public access modifiers

[Xiaodi Wu via swift-evolution]

I agree very much with rationalizing access levels, but I'm not sure I like
this proposal for public vs. closed. How would the compiler stop me from
editing my own code if something is closed? The answer must be that it
can't, so I can't see it as a co-equal to open but rather simply a
statement of intention. Therefore I think use cases for the proposed
behavior of closed would be better served by annotations and proper
semantic versioning.

As this change didn't seem in scope for Swift 4 phase 1, I've held off on
discussing my own thoughts on access levels. The idea I was going to
propose in phase 2 was to have simply open and public enums (and
protocols). I really think that completes access levels in a rational way
without introducing another keyword.
On Wed, Feb 8, 2017 at 17:05 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve been thinking a lot about our public access modifier story lately in
> the context of both protocols and enums.  I believe we should move further
> in the direction we took when introducing the `open` keyword.  I have
> identified what I think is a promising direction and am interested in
> feedback from the community.  If community feedback is positive I will
> flesh this out into a more complete proposal draft.
>
>
> Background and Motivation:
>
> In Swift 3 we had an extended debate regarding whether or not to allow
> inheritance of public classes by default or to require an annotation for
> classes that could be subclassed outside the module.  The decision we
> reached was to avoid having a default at all, and instead make `open` an
> access modifier.  The result is library authors are required to consider
> the behavior they wish for each class.  Both behaviors are equally
> convenient (neither is penalized by requiring an additional boilerplate-y
> annotation).
>
> A recent thread (
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031566.html)
> discussed a similar tradeoff regarding whether public enums should commit
> to a fixed set of cases by default or not.  The current behavior is that
> they *do* commit to a fixed set of cases and there is no option (afaik) to
> modify that behavior.  The Library Evolution document (
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums)
> suggests a desire to change this before locking down ABI such that public
> enums *do not* make this commitment by default, and are required to opt-in
> to this behavior using an `@closed` annotation.
>
> In the previous discussion I stated a strong preference that closed enums
> *not* be penalized with an additional annotation.  This is because I feel
> pretty strongly that it is a design smell to: 1) expose cases publicly if
> consumers of the API are not expected to switch on them and 2) require
> users to handle unknown future cases if they are likely to switch over the
> cases in correct use of the API.
>
> The conclusion I came to in that thread is that we should adopt the same
> strategy as we did with classes: there should not be a default.
>
> There have also been several discussions both on the list and via Twitter
> regarding whether or not we should allow closed protocols.  In a recent
> Twitter discussion Joe Groff suggested that we don’t need them because we
> should use an enum when there is a fixed set of conforming types.  There
> are at least two  reasons why I still think we *should* add support for
> closed protocols.
>
> As noted above (and in the previous thread in more detail), if the set of
> types (cases) isn’t intended to be fixed (i.e. the library may add new
> types in the future) an enum is likely not a good choice.  Using a closed
> protocol discourages the user from switching and prevents the user from
> adding conformances that are not desired.
>
> Another use case supported by closed protocols is a design where users are
> not allowed to conform directly to a protocol, but instead are required to
> conform to one of several protocols which refine the closed protocol.
> Enums are not a substitute for this use case.  The only option is to resort
> to documentation and runtime checks.
>
>
> Proposal:
>
> This proposal introduces the new access modifier `closed` as well as
> clarifying the meaning of `public` and expanding the use of `open`.  This
> provides consistent capabilities and semantics across enums, classes and
> protocols.
>
> `open` is the most permissive modifier.  The symbol is visible outside the
> module and both users and future versions of the library are allowed to add
> new cases, subclasses or conformances.  (Note: this proposal does not
> introduce user-extensible `open` enums, but provides the syntax that would
> be used if they are added to the language)
>
> `public` makes the symbol visible without allowing the user to add new
> cases, subclasses or conformances.  The library reserves the right to add
> new cases, subclasses or conformances in a future version.
>
> 

[swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

I’ve been thinking a lot about our public access modifier story lately in the 
context of both protocols and enums.  I believe we should move further in the 
direction we took when introducing the `open` keyword.  I have identified what 
I think is a promising direction and am interested in feedback from the 
community.  If community feedback is positive I will flesh this out into a more 
complete proposal draft.


Background and Motivation:

In Swift 3 we had an extended debate regarding whether or not to allow 
inheritance of public classes by default or to require an annotation for 
classes that could be subclassed outside the module.  The decision we reached 
was to avoid having a default at all, and instead make `open` an access 
modifier.  The result is library authors are required to consider the behavior 
they wish for each class.  Both behaviors are equally convenient (neither is 
penalized by requiring an additional boilerplate-y annotation).

A recent thread 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031566.html
 
)
 discussed a similar tradeoff regarding whether public enums should commit to a 
fixed set of cases by default or not.  The current behavior is that they *do* 
commit to a fixed set of cases and there is no option (afaik) to modify that 
behavior.  The Library Evolution document 
(https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums 
) 
suggests a desire to change this before locking down ABI such that public enums 
*do not* make this commitment by default, and are required to opt-in to this 
behavior using an `@closed` annotation.

In the previous discussion I stated a strong preference that closed enums *not* 
be penalized with an additional annotation.  This is because I feel pretty 
strongly that it is a design smell to: 1) expose cases publicly if consumers of 
the API are not expected to switch on them and 2) require users to handle 
unknown future cases if they are likely to switch over the cases in correct use 
of the API.

The conclusion I came to in that thread is that we should adopt the same 
strategy as we did with classes: there should not be a default.

There have also been several discussions both on the list and via Twitter 
regarding whether or not we should allow closed protocols.  In a recent Twitter 
discussion Joe Groff suggested that we don’t need them because we should use an 
enum when there is a fixed set of conforming types.  There are at least two  
reasons why I still think we *should* add support for closed protocols.

As noted above (and in the previous thread in more detail), if the set of types 
(cases) isn’t intended to be fixed (i.e. the library may add new types in the 
future) an enum is likely not a good choice.  Using a closed protocol 
discourages the user from switching and prevents the user from adding 
conformances that are not desired.

Another use case supported by closed protocols is a design where users are not 
allowed to conform directly to a protocol, but instead are required to conform 
to one of several protocols which refine the closed protocol.  Enums are not a 
substitute for this use case.  The only option is to resort to documentation 
and runtime checks.


Proposal:

This proposal introduces the new access modifier `closed` as well as clarifying 
the meaning of `public` and expanding the use of `open`.  This provides 
consistent capabilities and semantics across enums, classes and protocols.

`open` is the most permissive modifier.  The symbol is visible outside the 
module and both users and future versions of the library are allowed to add new 
cases, subclasses or conformances.  (Note: this proposal does not introduce 
user-extensible `open` enums, but provides the syntax that would be used if 
they are added to the language)

`public` makes the symbol visible without allowing the user to add new cases, 
subclasses or conformances.  The library reserves the right to add new cases, 
subclasses or conformances in a future version.

`closed` is the most restrictive modifier.  The symbol is visible publicly with 
the commitment that future versions of the library are *also* prohibited from 
adding new cases, subclasses or conformances.  Additionally, all cases, 
subclasses or conformances must be visible outside the module.

Note: the `closed` modifier only applies to *direct* subclasses or 
conformances.  A subclass of a `closed` class need not be `closed`, in fact it 
may be `open` if the design of the library requires that.  A class that 
conforms to a `closed` protocol also need not be `closed`.  It may also be 
`open`.  Finally, a protocol that refines a `closed` protocol need not be 
`closed`.  It may also be `open`.

This proposal is consistent with the principle that libraries should opt-in to 
all public API 

Re: [swift-evolution] [swift-build-dev] SE-0152: Package Manager Tools Version

[Martin Waitz via swift-evolution]

Hello Rick,

thanks again for your time and to explain everything in so much detail! :-)

> Am 08.02.2017 um 18:34 schrieb Rick Ballard :
> 
> Ultimately, I think no one is thrilled with parsing the Swift tools version 
> out of a comment, but the feedback we've received so far (off-list) has 
> strongly favored that approach, and when we evaluated the tradeoffs vs. the 
> other approaches we considered, it seemed the best.

Yeah, I can follow your argumentation now.
And I don’t really have any better idea.
Thanks for the explanations.

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

Re: [swift-evolution] Nil-rejection operator

[Xiaodi Wu via swift-evolution]

As has been mentioned by the core team, syntactic sugar is not in scope for
this phase of Swift 4 evolution and was said to be the lowest priority for
the next. The bar for adding a new operator is going to be higher than for
justifying the continued existence of an existing one.

That said, the nil coalescing operator has problems of its own that have
been raised on this list, mostly to do with sometimes unintuitive behavior
as a result of its associativity and precedence.
On Wed, Feb 8, 2017 at 14:35 Jack Newcombe  wrote:

> It’s absolutely true that this is syntactic sugar, but then so is
> nil-coalescing where "x ?? y” is syntactic sugar for “x != nil ? x : y”.
>
> You can also similarly recreate the nil-coalescing operator in Swift
> yourself, so I’m not sure that’s a strong argument for any operator being
> or not being in the standard library.
>
>
> On 8 Feb 2017, at 20:29, Xiaodi Wu  wrote:
>
> This seems to boil down to sugar where `guard let foo = ... else { throw
> ... }` is spelled `let foo = try ... !! ...`.
>
> While the analysis is interesting I don't see that this is an obvious win
> sufficient for the standard library. As you show it's possible to create
> for yourself.
> On Wed, Feb 8, 2017 at 14:20 Jean-Daniel via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While I find the concept interesting, I give a big -1 for using the ‘!’
> operator for something else that fatal error.
>
> Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hi all,
>
> Currently there are a number of different operators for dealing with
> optionals that cover most of the use cases. However, I think I’ve
> identified a missing complement for the existing operators for optionals.
>
> Take the following outcomes for interacting with an optional using
> existing operators (!, ?, ??). The outcomes of using these are as follows:
>
> - value? :
> if value is nil, do nothing and return nil
> if value is not nil, complete the chain by evaluating the rest of the
> expression. Return the result of the expression
> - value! :
> if value is nil, throw.a fatal error.
> If value is not nil, complete the chain by evaluating the rest of the
> expression. Return the result of the expression
> - value ?? default :
> if value is nil, return default
> if value is not nil, return value
>
> It seems to me that, if it is possible to coalesce a nil value with a
> default value, it should also be possible to reject a nil value a non-fatal
> error.
>
> I propose the introduction of a nil-rejection operator (represented here
> as !!) as a complement to the above operators.
> .
> This operator should allow an equivalent behaviour to the forced
> unwrapping of a variable, but with the provision of an error to throw in
> place of throwing a fatal error.
>
> - value !! Error :
> if value is nil, throw non-fatal error
> if value is not nil, return value
>
> Example of how this syntax might work (Where CustomError: Error):
>
> let value = try optionalValue !! CustomError.failure
>
> It is possible to implement this in Swift 3 with the following declaration:
>
> infix operator !! : NilCoalescingPrecedence
>
> func !!(lhs: Optional, 
> rhs: ErrorType) throws -> UnwrappedType
> {
> guard let unwrappedValue = lhs else {
> throw rhs
> }
> return unwrappedValue
> }
>
> I’ve added further examples including composition with the nil-coalescence
> operator here:
> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d
>
> This would be particularly convenient in cases where a functions expects
> significant number of optional to contain non-nil values, without the need
> to repeat non-generic guard-let structures with the same else code-block.
>
> Best regards,
>
> Jack
>
> ___
> 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] Nil-rejection operator

[Jack Newcombe via swift-evolution]

It’s absolutely true that this is syntactic sugar, but then so is 
nil-coalescing where "x ?? y” is syntactic sugar for “x != nil ? x : y”. 

You can also similarly recreate the nil-coalescing operator in Swift yourself, 
so I’m not sure that’s a strong argument for any operator being or not being in 
the standard library.


> On 8 Feb 2017, at 20:29, Xiaodi Wu  wrote:
> 
> This seems to boil down to sugar where `guard let foo = ... else { throw ... 
> }` is spelled `let foo = try ... !! ...`.
> 
> While the analysis is interesting I don't see that this is an obvious win 
> sufficient for the standard library. As you show it's possible to create for 
> yourself.
> On Wed, Feb 8, 2017 at 14:20 Jean-Daniel via swift-evolution 
> > wrote:
> While I find the concept interesting, I give a big -1 for using the ‘!’ 
> operator for something else that fatal error.
> 
>> Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution 
>> > a écrit :
>> 
>> Hi all,
>> 
>> Currently there are a number of different operators for dealing with 
>> optionals that cover most of the use cases. However, I think I’ve identified 
>> a missing complement for the existing operators for optionals.
>> 
>> Take the following outcomes for interacting with an optional using existing 
>> operators (!, ?, ??). The outcomes of using these are as follows:
>> 
>> - value? : 
>>  if value is nil, do nothing and return nil
>>  if value is not nil, complete the chain by evaluating the rest of the 
>> expression. Return the result of the expression
>> - value! : 
>>  if value is nil, throw.a fatal error. 
>>  If value is not nil, complete the chain by evaluating the rest of the 
>> expression. Return the result of the expression
>> - value ?? default :
>>  if value is nil, return default
>>  if value is not nil, return value
>> 
>> It seems to me that, if it is possible to coalesce a nil value with a 
>> default value, it should also be possible to reject a nil value a non-fatal 
>> error.
>> 
>> I propose the introduction of a nil-rejection operator (represented here as 
>> !!) as a complement to the above operators.
>> .
>> This operator should allow an equivalent behaviour to the forced unwrapping 
>> of a variable, but with the provision of an error to throw in place of 
>> throwing a fatal error.
>> 
>> - value !! Error :
>>  if value is nil, throw non-fatal error
>>  if value is not nil, return value
>> 
>> Example of how this syntax might work (Where CustomError: Error):
>> 
>>  let value = try optionalValue !! CustomError.failure
>> 
>> It is possible to implement this in Swift 3 with the following declaration:
>> 
>>  infix operator !! : NilCoalescingPrecedence
>> 
>>  func !!(lhs: 
>> Optional, rhs: ErrorType) throws -> UnwrappedType {
>>  guard let unwrappedValue = lhs else {
>>  throw rhs
>>  }
>>  return unwrappedValue
>>  }
>> 
>> I’ve added further examples including composition with the nil-coalescence 
>> operator here: 
>> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d 
>> 
>> 
>> This would be particularly convenient in cases where a functions expects 
>> significant number of optional to contain non-nil values, without the need 
>> to repeat non-generic guard-let structures with the same else code-block.
>> 
>> Best regards,
>> 
>> Jack
>> 
>> ___
>> 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] Nil-rejection operator

[Jack Newcombe via swift-evolution]

I picked !! because it seemed to follow somewhat naturally from force-unwrap 
and nil-coalescing; however, that does depend on how you interpret the syntax 
of the operator. 

I interpreted ?? to figuratively mean “? with a default result instead of nil”, 
and so derived !! As figuratively meaning “! with default error instead of 
fatal error”.

Regardless, I’m definitely open to alternatives, although can’t think of 
anything more appropriate offhand.


> On 8 Feb 2017, at 20:20, Jean-Daniel  wrote:
> 
> While I find the concept interesting, I give a big -1 for using the ‘!’ 
> operator for something else that fatal error.
> 
>> Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution 
>> > a écrit :
>> 
>> Hi all,
>> 
>> Currently there are a number of different operators for dealing with 
>> optionals that cover most of the use cases. However, I think I’ve identified 
>> a missing complement for the existing operators for optionals.
>> 
>> Take the following outcomes for interacting with an optional using existing 
>> operators (!, ?, ??). The outcomes of using these are as follows:
>> 
>> - value? : 
>>  if value is nil, do nothing and return nil
>>  if value is not nil, complete the chain by evaluating the rest of the 
>> expression. Return the result of the expression
>> - value! : 
>>  if value is nil, throw.a fatal error. 
>>  If value is not nil, complete the chain by evaluating the rest of the 
>> expression. Return the result of the expression
>> - value ?? default :
>>  if value is nil, return default
>>  if value is not nil, return value
>> 
>> It seems to me that, if it is possible to coalesce a nil value with a 
>> default value, it should also be possible to reject a nil value a non-fatal 
>> error.
>> 
>> I propose the introduction of a nil-rejection operator (represented here as 
>> !!) as a complement to the above operators.
>> .
>> This operator should allow an equivalent behaviour to the forced unwrapping 
>> of a variable, but with the provision of an error to throw in place of 
>> throwing a fatal error.
>> 
>> - value !! Error :
>>  if value is nil, throw non-fatal error
>>  if value is not nil, return value
>> 
>> Example of how this syntax might work (Where CustomError: Error):
>> 
>>  let value = try optionalValue !! CustomError.failure
>> 
>> It is possible to implement this in Swift 3 with the following declaration:
>> 
>>  infix operator !! : NilCoalescingPrecedence
>> 
>>  func !!(lhs: 
>> Optional, rhs: ErrorType) throws -> UnwrappedType {
>>  guard let unwrappedValue = lhs else {
>>  throw rhs
>>  }
>>  return unwrappedValue
>>  }
>> 
>> I’ve added further examples including composition with the nil-coalescence 
>> operator here: 
>> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d 
>> 
>> 
>> This would be particularly convenient in cases where a functions expects 
>> significant number of optional to contain non-nil values, without the need 
>> to repeat non-generic guard-let structures with the same else code-block.
>> 
>> Best regards,
>> 
>> Jack
>> 
>> ___
>> 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] Nil-rejection operator

[Xiaodi Wu via swift-evolution]

This seems to boil down to sugar where `guard let foo = ... else { throw
... }` is spelled `let foo = try ... !! ...`.

While the analysis is interesting I don't see that this is an obvious win
sufficient for the standard library. As you show it's possible to create
for yourself.
On Wed, Feb 8, 2017 at 14:20 Jean-Daniel via swift-evolution <
swift-evolution@swift.org> wrote:

> While I find the concept interesting, I give a big -1 for using the ‘!’
> operator for something else that fatal error.
>
> Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hi all,
>
> Currently there are a number of different operators for dealing with
> optionals that cover most of the use cases. However, I think I’ve
> identified a missing complement for the existing operators for optionals.
>
> Take the following outcomes for interacting with an optional using
> existing operators (!, ?, ??). The outcomes of using these are as follows:
>
> - value? :
> if value is nil, do nothing and return nil
> if value is not nil, complete the chain by evaluating the rest of the
> expression. Return the result of the expression
> - value! :
> if value is nil, throw.a fatal error.
> If value is not nil, complete the chain by evaluating the rest of the
> expression. Return the result of the expression
> - value ?? default :
> if value is nil, return default
> if value is not nil, return value
>
> It seems to me that, if it is possible to coalesce a nil value with a
> default value, it should also be possible to reject a nil value a non-fatal
> error.
>
> I propose the introduction of a nil-rejection operator (represented here
> as !!) as a complement to the above operators.
> .
> This operator should allow an equivalent behaviour to the forced
> unwrapping of a variable, but with the provision of an error to throw in
> place of throwing a fatal error.
>
> - value !! Error :
> if value is nil, throw non-fatal error
> if value is not nil, return value
>
> Example of how this syntax might work (Where CustomError: Error):
>
> let value = try optionalValue !! CustomError.failure
>
> It is possible to implement this in Swift 3 with the following declaration:
>
> infix operator !! : NilCoalescingPrecedence
>
> func !!(lhs: Optional, 
> rhs: ErrorType) throws -> UnwrappedType
> {
> guard let unwrappedValue = lhs else {
> throw rhs
> }
> return unwrappedValue
> }
>
> I’ve added further examples including composition with the nil-coalescence
> operator here:
> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d
>
> This would be particularly convenient in cases where a functions expects
> significant number of optional to contain non-nil values, without the need
> to repeat non-generic guard-let structures with the same else code-block.
>
> Best regards,
>
> Jack
>
> ___
> 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] Nil-rejection operator

[Jean-Daniel via swift-evolution]

While I find the concept interesting, I give a big -1 for using the ‘!’ 
operator for something else that fatal error.

> Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution 
>  a écrit :
> 
> Hi all,
> 
> Currently there are a number of different operators for dealing with 
> optionals that cover most of the use cases. However, I think I’ve identified 
> a missing complement for the existing operators for optionals.
> 
> Take the following outcomes for interacting with an optional using existing 
> operators (!, ?, ??). The outcomes of using these are as follows:
> 
> - value? : 
>   if value is nil, do nothing and return nil
>   if value is not nil, complete the chain by evaluating the rest of the 
> expression. Return the result of the expression
> - value! : 
>   if value is nil, throw.a fatal error. 
>   If value is not nil, complete the chain by evaluating the rest of the 
> expression. Return the result of the expression
> - value ?? default :
>   if value is nil, return default
>   if value is not nil, return value
> 
> It seems to me that, if it is possible to coalesce a nil value with a default 
> value, it should also be possible to reject a nil value a non-fatal error.
> 
> I propose the introduction of a nil-rejection operator (represented here as 
> !!) as a complement to the above operators.
> .
> This operator should allow an equivalent behaviour to the forced unwrapping 
> of a variable, but with the provision of an error to throw in place of 
> throwing a fatal error.
> 
> - value !! Error :
>   if value is nil, throw non-fatal error
>   if value is not nil, return value
> 
> Example of how this syntax might work (Where CustomError: Error):
> 
>   let value = try optionalValue !! CustomError.failure
> 
> It is possible to implement this in Swift 3 with the following declaration:
> 
>   infix operator !! : NilCoalescingPrecedence
> 
>   func !!(lhs: 
> Optional, rhs: ErrorType) throws -> UnwrappedType {
>   guard let unwrappedValue = lhs else {
>   throw rhs
>   }
>   return unwrappedValue
>   }
> 
> I’ve added further examples including composition with the nil-coalescence 
> operator here: 
> https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d 
> 
> 
> This would be particularly convenient in cases where a functions expects 
> significant number of optional to contain non-nil values, without the need to 
> repeat non-generic guard-let structures with the same else code-block.
> 
> Best regards,
> 
> Jack
> 
> ___
> 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] I think we need more to our type calculus

[Xiaodi Wu via swift-evolution]

type(of:) is the Swift 3 spelling of what was known in Swift 2 as
dynamicType.
On Wed, Feb 8, 2017 at 14:09 Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

> I’ve been trying to get the maximum of a list of counts. I started by
> using “myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I
> thought I should really use the value closest to negative infinity as the
> base. The problem is how to get that value. The current hard-coded “0”
> works because the count type ultimately aliases “Int”, but shouldn’t have
> to count on that. I put in “MyCountType.min”, where “MyCountType” is hard
> coded from the docs of “myCountProperty”, but I shouldn’t have to do that
> either.
>
> There is a “type(of:)” global function, which I did use. But not only did
> I have to make up an expression to go in there, its return value, some sort
> of meta-type stuff I don’t understand, can’t be used on the right side of a
> “typealias” construct. I ultimately used “let lowestCount = type(of:
> anElement.myCountProperty).min” to get what I needed.
>
> Some queries/requests:
>
> 1. Is the expression within “type(of:)” evaluated?
> 2. I think we need the equivalent of "std::declval” from C++. Especially
> if the answer to (1) is yes.
> 3. Why isn’t the return type(?) of “type(of:)” compile-time enough to be
> used as a type-alias?
> 4. Should we add something like the C++ type-traits collection of generic
> structures to give use type information as type-aliases or type-level
> instances?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> ___
> 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] I think we need more to our type calculus

[Daryle Walker via swift-evolution]

I’ve been trying to get the maximum of a list of counts. I started by using 
“myCollection.map { $0.myCountProperty }.reduce(0, max)”. Then I thought I 
should really use the value closest to negative infinity as the base. The 
problem is how to get that value. The current hard-coded “0” works because the 
count type ultimately aliases “Int”, but shouldn’t have to count on that. I put 
in “MyCountType.min”, where “MyCountType” is hard coded from the docs of 
“myCountProperty”, but I shouldn’t have to do that either.

There is a “type(of:)” global function, which I did use. But not only did I 
have to make up an expression to go in there, its return value, some sort of 
meta-type stuff I don’t understand, can’t be used on the right side of a 
“typealias” construct. I ultimately used “let lowestCount = type(of: 
anElement.myCountProperty).min” to get what I needed.

Some queries/requests:

1. Is the expression within “type(of:)” evaluated?
2. I think we need the equivalent of "std::declval” from C++. Especially if the 
answer to (1) is yes.
3. Why isn’t the return type(?) of “type(of:)” compile-time enough to be used 
as a type-alias?
4. Should we add something like the C++ type-traits collection of generic 
structures to give use type information as type-aliases or type-level instances?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Nil-rejection operator

[Jack Newcombe via swift-evolution]

Hi all,

Currently there are a number of different operators for dealing with optionals 
that cover most of the use cases. However, I think I’ve identified a missing 
complement for the existing operators for optionals.

Take the following outcomes for interacting with an optional using existing 
operators (!, ?, ??). The outcomes of using these are as follows:

- value? : 
if value is nil, do nothing and return nil
if value is not nil, complete the chain by evaluating the rest of the 
expression. Return the result of the expression
- value! : 
if value is nil, throw.a fatal error. 
If value is not nil, complete the chain by evaluating the rest of the 
expression. Return the result of the expression
- value ?? default :
if value is nil, return default
if value is not nil, return value

It seems to me that, if it is possible to coalesce a nil value with a default 
value, it should also be possible to reject a nil value a non-fatal error.

I propose the introduction of a nil-rejection operator (represented here as !!) 
as a complement to the above operators.
.
This operator should allow an equivalent behaviour to the forced unwrapping of 
a variable, but with the provision of an error to throw in place of throwing a 
fatal error.

- value !! Error :
if value is nil, throw non-fatal error
if value is not nil, return value

Example of how this syntax might work (Where CustomError: Error):

let value = try optionalValue !! CustomError.failure

It is possible to implement this in Swift 3 with the following declaration:

infix operator !! : NilCoalescingPrecedence

func !!(lhs: 
Optional, rhs: ErrorType) throws -> UnwrappedType {
guard let unwrappedValue = lhs else {
throw rhs
}
return unwrappedValue
}

I’ve added further examples including composition with the nil-coalescence 
operator here: 
https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d 


This would be particularly convenient in cases where a functions expects 
significant number of optional to contain non-nil values, without the need to 
repeat non-generic guard-let structures with the same else code-block.

Best regards,

Jack

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

Re: [swift-evolution] !? operator for ternary conditional unwrapping

[Adrian Zubarev via swift-evolution]

For more information about optional chaining read this docs: 
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Februar 2017 um 20:05:31, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

Swift does already have a great solution in such a scenario.

func handler() -> Result? {
  return callback?.result()
}
Does the trick. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Februar 2017 um 20:02:38, Maxim Veksler (ma...@vekslers.org) schrieb:

For example, assume that we're dealing with a callback of some form.

let callback: CallbackProtocol? = StructExampleCallback()

You could write inside you handler function:

func handler() -> Result? {
  return callback ?! callback.result() : nil
}

Which would return either nil, or the callback result. I don't think you can do 
it with ?? but then again guard is a valid solution for this specific use case.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] !? operator for ternary conditional unwrapping

[Maxim Veksler via swift-evolution]

Thanks for teaching me about .map on Optional. Very cool.

I agree with the comment of $! misleading, maybe a better alternative would
be "??" ?

On Wed, Feb 8, 2017 at 5:12 PM Tony Allevato 
wrote:

> What you're asking for is already possible (avoiding the optional unwrap)
> by combining map() on Optional with ??:
>
> ```
> let name1: String? = "name"
> print(name1.map { "\"\($0)\"" } ?? "null")  // prints "\"name\""
>
> let name2: String? = nil
> print(name2.map { "\"\($0)\"" } ?? "null")  // prints "null"
> ```
>
> So I guess the question is, does simplifying that rise to the level of
> wanting a custom operator? I personally don't think it does, but I could
> see an argument being made that an operator with defined semantics might be
> a small amount clearer than map + ??. But I think the benefits would have
> to be very strong, though.
>
> And as other folks have mentioned, having "!" in the operator name is
> somewhat misleading, since when I see that I expect a trap to occur in nil
> cases.
>
>
>
> On Wed, Feb 8, 2017 at 6:04 AM Maxim Veksler via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> Let's assume I have an optional "name" parameter, based on the optional
> status of the parameters I would like to compose string with either the
> unwrapped value of name, or the string "null". The use case for is
> syntactic sugar to compose a GraphQL queries.
>
> A (sampled) illustration of the code that currently solves it looks as
> following:
>
> func query(name: String?) {
>   let variables_name = name != nil ? "\"\(name!)\"" : "null"
> return "{ param: \(variables_name) }"
> }
>
> Based on optional status the following output is expected
>
> let name = "Max"
> query(name: name)
> // { param: "Max" }
>
> let name: String? = nil
> query(name: name)
> // { param: null }
>
> I think it might be useful to have an conditional unwrap operator !? that
> would enable syntax sugar uch as the following built into the language:
>
> func query(name: String?) {
>   return "{ param: \(name !? "\"\(name)\"": "null") }"
> }
>
> This expression is expected to produce same output as the examples above.
> It means check the Optional state of name: String?, in case it has a
> value, unwrap it and make the unwrapped value accessible under the same
> name to the true condition part of the expression, otherwise return the false
> condition part of the expression.
>
> The effectively removes the need to have the "if != nil" and the forced
> unwrap syntactical code, and IMHO improves code readability and
> expressiveness.
>
> I'm wondering what the community thinks of the displayed use case, and
> proposed solution?
>
>
> -m
>
> ___
> 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] !? operator for ternary conditional unwrapping

[Adrian Zubarev via swift-evolution]

Swift does already have a great solution in such a scenario.

func handler() -> Result? {
  return callback?.result()
}
Does the trick. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Februar 2017 um 20:02:38, Maxim Veksler (ma...@vekslers.org) schrieb:

For example, assume that we're dealing with a callback of some form.

let callback: CallbackProtocol? = StructExampleCallback()

You could write inside you handler function:

func handler() -> Result? {
  return callback ?! callback.result() : nil
}

Which would return either nil, or the callback result. I don't think you can do 
it with ?? but then again guard is a valid solution for this specific use case.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] !? operator for ternary conditional unwrapping

[Maxim Veksler via swift-evolution]

Hello Adrian,

Please see reply inline.

On Wed, Feb 8, 2017 at 4:52 PM Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> You could always write something like this:
>
> func query(name: String?) -> String {
>
> let variables_name = String(format: name == nil ? "%@" : "\"%@\"", name 
> ?? "null")
> return "{ param: \(variables_name) }"
> }
>
> query(name: "Max") //=> "{ param: "Max" }"
> query(name: nil)   //=> "{ param: null }"
>
> As far as I’m concerned, string interpolation in Swift does not allow
> nested string literals (yet).
>

Thanks, that's another take on the specifics of String, but I think *?!*
extends beyond String.

For example, assume that we're dealing with a callback of some form.

let callback: CallbackProtocol? = StructExampleCallback()

You could write inside you handler function:

func handler() -> Result? {
  return callback ?! callback.result() : nil
}

Which would return either nil, or the callback result. I don't think you
can do it with ?? but then again guard is a valid solution for this
specific use case.



> --
>
> But a ternary operator that could potentially unwrap a list of optional
> values would be neat.
>
> Bikeshedding:
>
> (optional1, optional2, optional1) ? { tupleWithUnwrappedOptionals in return R 
> } : { R }
>
> // variadic generic parameter list
> ternary func ?: <…T, R>(list: (…T?), lhs: ((…T) -> R), rhs: () -> R) -> R {
>
> if let unwrappedList = // unwrap all optionals in `list` {
> return lhs(unwrappedList)
> } else {
> return rhs()
> }
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Februar 2017 um 15:04:44, Maxim Veksler via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hello,
>
> Let's assume I have an optional "name" parameter, based on the optional
> status of the parameters I would like to compose string with either the
> unwrapped value of name, or the string "null". The use case for is
> syntactic sugar to compose a GraphQL queries.
>
> A (sampled) illustration of the code that currently solves it looks as
> following:
>
> func query(name: String?) {
>   let variables_name = name != nil ? "\"\(name!)\"" : "null"
> return "{ param: \(variables_name) }"
> }
>
> Based on optional status the following output is expected
>
> let name = "Max"
> query(name: name)
> // { param: "Max" }
>
> let name: String? = nil
> query(name: name)
> // { param: null }
>
> I think it might be useful to have an conditional unwrap operator !? that
> would enable syntax sugar uch as the following built into the language:
>
> func query(name: String?) {
>   return "{ param: \(name !? "\"\(name)\"": "null") }"
> }
>
> This expression is expected to produce same output as the examples above.
> It means check the Optional state of name: String?, in case it has a
> value, unwrap it and make the unwrapped value accessible under the same
> name to the true condition part of the expression, otherwise return the
> false condition part of the expression.
>
> The effectively removes the need to have the "if != nil" and the forced
> unwrap syntactical code, and IMHO improves code readability and
> expressiveness.
>
> I'm wondering what the community thinks of the displayed use case, and
> proposed solution?
>
>
> -m
>
> ___
> 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] !? operator for ternary conditional unwrapping

[Anton Zhilin via swift-evolution]

With Runes , this looks like:

(name1 <^> { "\"\($0)\"" }) ?? "null"

Runes defines <^> to have lower precedence than ??. Sadly, they all can’t
be in the same precedence group due to right associativity of ??.

2017-02-08 18:11 GMT+03:00 Tony Allevato via swift-evolution <
swift-evolution@swift.org>:

What you're asking for is already possible (avoiding the optional unwrap)
> by combining map() on Optional with ??:
>
> ```
> let name1: String? = "name"
> print(name1.map { "\"\($0)\"" } ?? "null")  // prints "\"name\""
>
> let name2: String? = nil
> print(name2.map { "\"\($0)\"" } ?? "null")  // prints "null"
> ```
>
> So I guess the question is, does simplifying that rise to the level of
> wanting a custom operator? I personally don't think it does, but I could
> see an argument being made that an operator with defined semantics might be
> a small amount clearer than map + ??. But I think the benefits would have
> to be very strong, though.
>
> And as other folks have mentioned, having "!" in the operator name is
> somewhat misleading, since when I see that I expect a trap to occur in nil
> cases.
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0152: Package Manager Tools Version

[Boris Buegling via swift-evolution]

> On 8. Feb 2017, at 10:49, Will Field-Thompson via swift-evolution 
>  wrote:
> 
> The main package manager I use is CocoaPods and as far as I am aware 
> CocoaPods doesn't allow you to specify the tools version in the Podfile. This 
> did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I think 
> Podfile.lock records the version of CocoaPods, but I don't think that 
> actually helps in this regard.

This is correct. The Podfile.lock records the last used version, but does not 
enforce it in any way. The officially recommended approach is using Bundler’s 
Gemfile/Gemfile.lock to ensure consistency of used versions of the CP gem.

Cheers,
Boris

> 
>   *  How much effort did you put into your review?  A glance, a quick 
> reading, or an in-depth study?
>  
> I spent some time reading through the proposal, but I lost track of the 
> discussion pre-proposal.
> 
> - Will
> ___
> 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] SE-0152: Package Manager Tools Version

[Will Field-Thompson via swift-evolution]

> *  What is your evaluation of the proposal?
>

I fully support the goals of the proposal and have a question about the
implementation.

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

Yep. It provides a good way to evolve the API, and putting it in place for
Swift 3.1 gives us the freedom to evolve the API as (or if) needed for
Swift 4.

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

I agree that the placement of the tools version in a comment is
unfortunate, but I think that it's the best way to include it in
Package.swift.

I'm interested in other people's thoughts on a .swift-tools-version file.
I'm not sure I prefer it to the comment in Package.swift, but the reasons
included in the proposal don't convince me the .swift-tools-version shouldn't
be used either.

   - *Eliminates the possibility of including either Package.swift or
   .swift-tools-version*: Seems like exactly the kind of mistake you make
   once and then don't make again. I guess with a leading dot it's more likely
   to be forgotten than a non-dot-file, but not a major issue IMO.
   - *Users may like to see the version in the Package.swift*: Probably
   true, though I'm not sure how much of an issue it is.

Are these significant problems for other people? They don't seem that way
to me, but I may not represent the majority here as my work is in iOS dev
and the only time I get to use swiftpm is for side projects.

The .swift-tools-version has the advantage that it is extendable in a
prettier (i.e. easier to read and easier to diff for VCS purposes) way than
the semicolon-separated syntax from the proposal. How likely is it that
we'll ever have to extend it? I think that, for me, is the determining
factor for which format I prefer.

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

The main package manager I use is CocoaPods and as far as I am aware
CocoaPods doesn't allow you to specify the tools version in the Podfile.
This did cause some (albeit minimal) pain on transition to CocoaPods 1.0. I
think Podfile.lock records the version of CocoaPods, but I don't think that
actually helps in this regard.

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

I spent some time reading through the proposal, but I lost track of the
discussion pre-proposal.

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

Re: [swift-evolution] !? operator for ternary conditional unwrapping

[Maxim Veksler via swift-evolution]

Hi Martin, please see reply inline.

On Wed, Feb 8, 2017 at 4:47 PM Martin R  wrote:

> Isn't that exactly what the nil-coalescing operator ?? does?
>
> func query(name: String?) -> String {
> return "{ param: \(name ?? "null") }"
> }
>
>
No, because

func query(name: String?) -> String {

return "{ param: \(name ?? "null") }"

}


print(query(name: nil)) //=> { param: null }

print(query(name: "Max")) //=> { param: Max }

The output I'm expecting from the second call should be is { param: "Max" }


> If you use the JSONSerialization class from the Foundation library then
> `nil` is bridged to `NSNull` and translated to "null" automatically (see
> SE-0140).
>
>
 I agree that in this case JSONSerialization might be a fitting solution, I
also agree that any required output can be solved by a Utility class.

What I would like to argue is that there is a place for such syntactic
sugar because it simplifies readability, for ex. what if I've want to wrap
my non optional name parameter using %20%, and co.

JSONSerialization is specific solution, I think that there is a generic
case to have in the language some syntactic sugar for a 1 liner composition
of unwrap and ternary conditional operation.

Regards,
> Martin
>
> > Am 08.02.2017 um 15:04 schrieb Maxim Veksler via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Hello,
> >
> > Let's assume I have an optional "name" parameter, based on the optional
> status of the parameters I would like to compose string with either the
> unwrapped value of name, or the string "null". The use case for is
> syntactic sugar to compose a GraphQL queries.
> >
> > A (sampled) illustration of the code that currently solves it looks as
> following:
> >
> > func query(name: String?) {
> >   let variables_name = name != nil ? "\"\(name!)\"" : "null"
> >   return "{ param: \(variables_name) }"
> > }
> >
> > Based on optional status the following output is expected
> >
> > let name = "Max"
> > query(name: name)
> > // { param: "Max" }
> >
> > let name: String? = nil
> > query(name: name)
> > // { param: null }
> >
> > I think it might be useful to have an conditional unwrap operator !?
> that would enable syntax sugar uch as the following built into the language:
> >
> > func query(name: String?) {
> >   return "{ param: \(name !? "\"\(name)\"": "null") }"
> > }
> >
> > This expression is expected to produce same output as the examples
> above. It means check the Optional state of name: String?, in case it has a
> value, unwrap it and make the unwrapped value accessible under the same
> name to the true condition part of the expression, otherwise return the
> false condition part of the expression.
> >
> > The effectively removes the need to have the "if != nil" and the forced
> unwrap syntactical code, and IMHO improves code readability and
> expressiveness.
> >
> > I'm wondering what the community thinks of the displayed use case, and
> proposed solution?
> >
> >
> > -m
> > ___
> > 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] Compile-time generic specialization

[Joe Groff via swift-evolution]

> On Feb 6, 2017, at 10:06 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 5, 2017, at 5:36 PM, Abe Schneider via swift-evolution 
>> > wrote:
>> 
>> Hi Robert,
>> 
>> Exactly. The benefit being that you can figure out the correct function to 
>> dispatch entirely at compile time. My understanding is that Swift doesn’t do 
>> this because of the associated code bloat (and it’s usually not necessary). 
>> However, I think there is some important functionality by allowing 
>> specialization to control dispatch in a similar way to c++. There is also 
>> the design element — my (fairly) succinct Tensor class that used to be ~300 
>> lines is now already close to an additional 1000 lines of code and growing. 
>> While the type of library I’m writing might be outside of what is normally 
>> done with Swift, I suspect the design pattern I’m using crops up in other 
>> places, as well as the need for dispatch on specialization (e.g. 
>> http://stackoverflow.com/questions/41640321/extending-collection-with-a-recursive-property-method-that-depends-on-the-elemen
>>  
>> ).
> 
> You can’t figure out the correct function to dispatch entirely at compile 
> time because Swift supports retroactive modeling. Let’s make this a 
> super-simple example:
> 
>   // Module A
>   public protocol P { }
>   public func f(_:T) { print(“unspecialized”) }
>   public func f(_: T) { print(“specialized”) }
> 
>   public func g(_ x: T) { f(x) }
> 
>   // Module B
>   import A
>   func testG(x: Int) {
> g(x)  // the best we can statically do is print “unspecialized”; Int 
> doesn’t conform to A.P, but...
>   }
> 
>   // Module C
>   import A
>   public extension A: P { }   // dynamically, Int does conform to A.P!
> 
> Swift’s model is that the selection among ad hoc overloads is performed 
> statically based on local knowledge, and is consistent across all 
> “specializations” of a generic function. Protocol requirements and 
> overridable methods are the customization points.
> 
> Selecting ad hoc overloads at runtime is possible, but of course it has 
> downsides. You could run into run-time ambiguities, for example:
> 
>   // Module A
>   public protocol P { }
>   public protocol Q { }
>   public func f(_:T) { print(“unspecialized”) }
>   public func f(_: T) { print(“specialized for P”) }
>   public func f(_: T) { print(“specialized for Q”) }
> 
>   public func g(_ x: T) { f(x) }
> 
>   // Module B
>   import A
>   public extension Int: P { } 
> 
>   // Module C
>   import A
>   public extension Int: Q { } 
> 
>   // Module C
>   import A
>   func testG(x: Int) {
> g(x)   // run-time ambiguity: which specialized “f” do we get?
>   }
> 
> There are reasonable answers here if we know what the potential set of 
> overloads is at compile-time. It’s a problem I’ve been interested in for a 
> long time . That dynamic 
> dispatch can be implemented somewhat reasonably (the compiler can emit a 
> static decision tree so long as we’re willing to limit the set of overloads 
> to the ones that are visible from g(_:), and can be folded away by the 
> optimizer when we’re specializing the function and the visibility of the 
> types and/or protocols in question is limited.
> 
>> As far as changes to Swift, `@_specialize` already does exactly this (except 
>> it is treated as a hint). You would need to transform the function to 
>> something like _(…) and a table of 
>> transformed functions, but after that you can just treat the functions as 
>> normal functions (and ignore the fact they were defined as generic). So, 
>> yes, specializations should be forced at every level. While this will lead 
>> to some code bloat, since it only occurs for the functions marked by the 
>> user, I would imagine it’s: (a) limited to the extent it occurs; and (b) 
>> manageable by simply not using the attribute (and using protocol witness 
>> tables instead). But at least that way you give the user the choice to do 
>> what is best for the particular situation.
> 
> For reference, `@_specialize` is doing dynamic dispatch. That dynamic 
> dispatch gets optimized away when we specialize the generic function, the 
> same way I mentioned about.
> 
> There might be a reasonable solution to the problem you’re encountering. I 
> don’t think it’s “force specialization at compile time like C++”, but 
> something akin to grouping together multiple overloads where we want dynamic 
> dispatch of callers that invoke them, statically diagnosing when that set of 
> overloads can have ambiguities in it (see the paper I referenced above), and 
> teaching the 

Re: [swift-evolution] [swift-build-dev] SE-0152: Package Manager Tools Version

[Rick Ballard via swift-evolution]

> The review of SE-0152 "Package Manager Tools Version" begins now and runs 
> through February 13, 2017.  The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

Hi Martin,

Thanks again for your feedback.

Regarding your first point, about whether this is necessary:

We could indeed choose to make the Swift 3 tools always interpret the manifest 
as Swift 3 and the Swift 4 tools always interpret it as Swift 4, and hope that 
no language changes affect code in manifests, but that's a pretty big risk -- 
either that manifests won't build, or that subtle incompatibilities between the 
modes could have unexpected side effects. Simple manifests might not be 
affected by language changes (though we really don't know that yet), but more 
complex manifests might be, which would still be a a problem.

If this was the main point of this proposal, I might agree that it isn't worth 
it for this single need, despite the risk. But there are two other things that 
we need this proposal for; the most important being allowing packages to avoid 
breaking dependency resolution from older versions of the Swift tools when they 
adopt new PackageDescription API (or any other Swift features, which might not 
be reflected in the Swift language compatibility version, e.g. if it's a 
feature added in a minor release). Since we want a Swift tools version defined 
for that need, we can get proper control "for free" over the language version 
used to parse the manifest.

Unfortunately, we can't just wait and see how much of a problem this is in 
practice and add it later if we need it; this mechanism needs to be understood 
by both a new breaking version of Swift (Swift 4) and the version prior (Swift 
3.1) in order to have any effect, since the whole point is to keep the prior 
version from trying to use incompatible packages. Our window to get changes 
into 3.1 will close before too long, so it's now or never for this language 
transition.

Regarding your second point, about this being a comment:

That's a good point about the SGML DOCTYPE not actually being a comment; I can 
revise the proposal to fix that inaccuracy. I don't think that materially 
affects the tradeoffs between making this a comment vs. other approaches, 
though.

We discuss some alternatives to using a comment, and why we favor the comment, 
here:

https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md#store-the-swift-tools-version-in-a-separate-file
 

and here:

https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md#specify-the-swift-tools-version-with-a-more-swifty-syntax
 


There was a more detailed discussion of the tradeoffs in a version of the 
document we floated prior to formal review, before we had decided on the 
comment:

https://github.com/rballard/swift-evolution/blob/fd28010aaef077b9783d738eacd912915b55c67e/proposals/-package-manager-tools-version.md#how-the-swift-tools-version-is-specified
 


You suggest an alternative of grepping the Package.Swift for the string 
"swiftLanguageVersions". That approach seems like pretty unexpected, non-formal 
behavior for the tools. What happens if this string appears multiple times, 
which we expect will be the case once we have a proper build settings model and 
you can set swiftLanguageVersions on a per-module basis within the package? 
Would we parse (and be able to machine-edit) all syntaxes for setting the 
swiftLanguageVersions (initial initializer, mutating the property after 
Package() is initialized, expression to derive the RHS of the setter)? What 
would it mean if swiftLanguageVersions has multiple values, which is allowed? I 
don't see concrete benefits to this idea, and it adds new complexities and 
possibilities for error.

Note that the swiftLanguageVersions does _not_ actually have to be specified by 
the package otherwise. In the common case of a package whose language version 
is the same as its Swift tools version, no swiftLanguageVersions property need 
be specified -- and I expect that `swift package init` won't give you one by 
default.

We don't want to stipulate that the package manager needs to use the same mode 
for `Package.swift` as the rest of your sources, because we want you to be able 
to adopt new package manager API without having to simultaneously convert all 
your package's sources 

Re: [swift-evolution] [swift-build-dev] SE-0151: Package Manager Swift Language Compatibility Version

[Martin Waitz via swift-evolution]

Hello Rick,

thanks for the explanation!

Am 2017-02-08 17:55, schrieb Rick Ballard:

I believe that the reason this was desired is because we expect that
package authors may wish to conditionally adopt new Swift 4 language
features without breaking their ability to build with Swift 3, using
conditional compilation blocks, e.g.

 #if swift(>=4.0)
 // Swift 4 code goes here
 #endif

With this proposal, you can do this by specifying [3, 4], in which
case the Swift 4 compiler will compile it as Swift 4 code, and use the
code inside the conditional compilation block, while the Swift 3
compiler will also be able to compile it (as Swift 3 code), skipping
the conditional compilation block.


That makes sense.

+1 :-)

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

Re: [swift-evolution] [swift-build-dev] SE-0151: Package Manager Swift Language Compatibility Version

[Rick Ballard via swift-evolution]

> On Feb 7, 2017, at 11:19 PM, Martin Waitz via swift-build-dev 
>  wrote:
> 
>> The review of SE-0151 “Package Manager Swift Language Compatibility Version" 
>> begins now and runs through February 13, 2017.  The proposal is available 
>> here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md
>>  
>> 
Thanks for providing feedback, Martin.

When Swift's source compatibility plan defined 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029099.html
 
),
 it included the point:

> The Swift Package Manager will allow package authors to specify a list of 
> compatibility modes.

This proposal provides a mechanism to implement that point.

I believe that the reason this was desired is because we expect that package 
authors may wish to conditionally adopt new Swift 4 language features without 
breaking their ability to build with Swift 3, using conditional compilation 
blocks, e.g. 

#if swift(>=4.0)
// Swift 4 code goes here
#endif

With this proposal, you can do this by specifying [3, 4], in which case the 
Swift 4 compiler will compile it as Swift 4 code, and use the code inside the 
conditional compilation block, while the Swift 3 compiler will also be able to 
compile it (as Swift 3 code), skipping the conditional compilation block.

If you were only able to specify "3" instead, the Swift 4 compiler would pass 
`-swift-version 3` when compiling this code, and would skip the conditional 
compilation block. As such it would not be possible to use any Swift 4 language 
features unless you set your Swift language compatibility version to "4", at 
which point it could no longer be built by the Swift 3 compiler.

- Rick

> I’ve one question regarding this proposal:
> Why use the list `swiftLanguageVersions` instead of a simple 
> `swiftLanguageVersion: Int = 3`?
> What’s the advantage of being able to specify `[3,4]`?
> 
> If you already have a version 4 compiler, that one will be used anyway and if 
> the source really is compatible with both versions,
> it does not make any difference whether it will be run in version 3 or 
> version 4 mode.
> So just setting it to `3` has the same effect, right?
> 
> I think it’s enough to specify something like „this source is intended to be 
> compiled in swift version 3 mode“.
> Most of the time, that’s all you can specify anyway, because you don’t know 
> which future versions happen to be compatible.

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

Re: [swift-evolution] !? operator for ternary conditional unwrapping

[Adrian Zubarev via swift-evolution]

I forgot about map :D That solution is more swifty than mine with 
String(format::).



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Februar 2017 um 16:12:11, Tony Allevato via swift-evolution 
(swift-evolution@swift.org) schrieb:

What you're asking for is already possible (avoiding the optional unwrap) by 
combining map() on Optional with ??:

```
let name1: String? = "name"
print(name1.map { "\"\($0)\"" } ?? "null")  // prints "\"name\""

let name2: String? = nil
print(name2.map { "\"\($0)\"" } ?? "null")  // prints "null"
```

So I guess the question is, does simplifying that rise to the level of wanting 
a custom operator? I personally don't think it does, but I could see an 
argument being made that an operator with defined semantics might be a small 
amount clearer than map + ??. But I think the benefits would have to be very 
strong, though.

And as other folks have mentioned, having "!" in the operator name is somewhat 
misleading, since when I see that I expect a trap to occur in nil cases.



On Wed, Feb 8, 2017 at 6:04 AM Maxim Veksler via swift-evolution 
 wrote:
Hello, 

Let's assume I have an optional "name" parameter, based on the optional status 
of the parameters I would like to compose string with either the unwrapped 
value of name, or the string "null". The use case for is syntactic sugar to 
compose a GraphQL queries.

A (sampled) illustration of the code that currently solves it looks as 
following:

func query(name: String?) {
  let variables_name = name != nil ? "\"\(name!)\""
: "null"
return "{ param: \(variables_name) }"
}

Based on optional status the following output is expected

let name = "Max"
query(name: name) 
// { param: "Max" }

let name: String? = nil
query(name: name)
// { param: null }

I think it might be useful to have an conditional unwrap operator !? that would 
enable syntax sugar uch as the following built into the language:

func query(name: String?) {
  return "{ param: \(name !? "\"\(name)\"": "null")
}"
}

This expression is expected to produce same
output as the examples above. It means check the Optional state
of name: String?, in case it has a value, unwrap it and make the
unwrapped value accessible under the same name to the true
condition part of the expression, otherwise return
the false condition part of the expression.

The effectively removes the need to have the "if !=
nil" and the forced unwrap syntactical code, and IMHO improves code
readability and expressiveness.

I'm wondering what the community thinks of the displayed use case, and proposed 
solution?


-m
___
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] !? operator for ternary conditional unwrapping

[Tony Allevato via swift-evolution]

What you're asking for is already possible (avoiding the optional unwrap)
by combining map() on Optional with ??:

```
let name1: String? = "name"
print(name1.map { "\"\($0)\"" } ?? "null")  // prints "\"name\""

let name2: String? = nil
print(name2.map { "\"\($0)\"" } ?? "null")  // prints "null"
```

So I guess the question is, does simplifying that rise to the level of
wanting a custom operator? I personally don't think it does, but I could
see an argument being made that an operator with defined semantics might be
a small amount clearer than map + ??. But I think the benefits would have
to be very strong, though.

And as other folks have mentioned, having "!" in the operator name is
somewhat misleading, since when I see that I expect a trap to occur in nil
cases.



On Wed, Feb 8, 2017 at 6:04 AM Maxim Veksler via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello,
>
> Let's assume I have an optional "name" parameter, based on the optional
> status of the parameters I would like to compose string with either the
> unwrapped value of name, or the string "null". The use case for is
> syntactic sugar to compose a GraphQL queries.
>
> A (sampled) illustration of the code that currently solves it looks as
> following:
>
> func query(name: String?) {
>   let variables_name = name != nil ? "\"\(name!)\"" : "null"
> return "{ param: \(variables_name) }"
> }
>
> Based on optional status the following output is expected
>
> let name = "Max"
> query(name: name)
> // { param: "Max" }
>
> let name: String? = nil
> query(name: name)
> // { param: null }
>
> I think it might be useful to have an conditional unwrap operator !? that
> would enable syntax sugar uch as the following built into the language:
>
> func query(name: String?) {
>   return "{ param: \(name !? "\"\(name)\"": "null") }"
> }
>
> This expression is expected to produce same output as the examples above.
> It means check the Optional state of name: String?, in case it has a
> value, unwrap it and make the unwrapped value accessible under the same
> name to the true condition part of the expression, otherwise return the false
> condition part of the expression.
>
> The effectively removes the need to have the "if != nil" and the forced
> unwrap syntactical code, and IMHO improves code readability and
> expressiveness.
>
> I'm wondering what the community thinks of the displayed use case, and
> proposed solution?
>
>
> -m
> ___
> 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] !? operator for ternary conditional unwrapping

[Adrian Zubarev via swift-evolution]

If you need a infix operator that traps, here you have one ;)

infix operator ?! : NilCoalescingPrecedence

func ?! (optional: T?, noreturn: @autoclosure () -> Never) -> T {
   switch optional {
   case .some(let value):
  return value
   case .none:
  noreturn()
   }
}

let x: Int? = nil  

let y: Int = x ?! fatalError("Your message here")


-- 
Adrian Zubarev
Sent with Airmail

Am 8. Februar 2017 um 16:00:24, Haravikk via swift-evolution 
(swift-evolution@swift.org) schrieb:

I say it's a bit of an odd operator since it doesn't actually trap.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

[Martin Waitz via swift-evolution]

Hi,

Am 2017-02-08 08:54, schrieb Dimitri Racordon via swift-evolution:

I guess allowing a list of versions to be specified is interesting for
continuous integration.
That would allow people to test their code under all intended supported 
version.


That is a valid use-case, but should be specified somewhere else.
In your `.travis.yml` (or whatever), you could specify to compile your 
package (and all dependencies)

with different versions of the swift tools.
However, all these different tool versions would still use the 
per-package `swiftLanguageVersion` to select the right compiler mode for 
each package.
This way, you can test that everything really builds and links with 
different tool versions.


I see no reason to include a list of versions in the manifest.
That only creates ambiguities ("works for me" if you happen to have the 
right tool version).


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

Re: [swift-evolution] Warning when omitting default case for imported enums

[Tino Heth via swift-evolution]

> Allowing the omission of a default case in an exhaustive switch makes the 
> addition of a new case to the enum a breaking change. 
Depending on the context, even with a default the change might be breaking — 
but without giving notice to the framework client!
Additionally, it would feel very strange for me to have a default clause for 
bool-like enums* or other examples where there can't be any additional cases.

When there are two types of enums, the proposal makes sense for the 
"open"-ones; but I'm not sure if I like the concept of having two kinds of enum.

- Tino

* tiny anecdote: I actually have seen the equivalent of this

func reallyExhaustive(input: Bool) {
if input == true {
print("true")
} else if input != true {
print ("not true")
} else {
print("just to be save")
}
}

in the wild… but I don't remember the comment I wrote ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0152: Package Manager Tools Version

[Martin Waitz via swift-evolution]

Hi,

> The review of SE-0152 "Package Manager Tools Version" begins now and runs 
> through February 13, 2017.  The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

From the proposal:
> Not changing this API would still leave the problem of figuring out which 
> Swift language compatibility version to interpret the manifest in. It's 
> possible that Package.swift manifests won't be significantly affected by 
> Swift language changes in Swift 4, and could mostly work in either language 
> compatibility mode without changes. However, we don't know whether that will 
> be the case, and it would be a significant risk to assume that it will be.

I really assume that the simple `Package.swift` files will be able to be 
compiled in swift 3 and swift 4 modes.
Do we really need this proposal now?
If we really encounter problems, we can always add it later.
So what exactly is the risk?

When we want to introduce it already now, I’d like to revisit the way the tool 
version is specified.

Can we _please_ not use a comment?
Comments are comments and should have no influence on how to parse the file.

By the way, in XML/HTML, the DTD/Doctype is not specified in a comment, but in 
a processor instruction (`` vs. ``).
So the XML example would more closely resemble something like `#swift(3.0)` in 
Swift.

Maybe the package manager could just grep for the `swiftLanguageVersion` 
specification?
This has to be specified by the package anyway.
We could simply specify that the swift compiler always uses the same mode for 
`Package.swift` and the rest of the sources,
and that the package manager obtains this version from the manifest without 
using the full Swift compiler.
I.e. this line would be fixed to some special syntax 
(`^\s*swiftLanguageVersion\s*:\s*(\d+)\s*,\s*$` or something).

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