date:20170118

Re: [swift-evolution] Availability checking of libraries (weak linking?)

2017-01-18 Thread Slava Pestov via swift-evolution

Extending availability to support library versioning would be a great proposal.

You should also take a look at the library evolution proposal, where this 
functionality will be required to implement the resilience model: 
https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst

Slava

> On Jan 18, 2017, at 4:24 PM, Swizzlr via swift-evolution 
>  wrote:
> 
> Say I have an awesome type, and I provide some extensions that makes it work 
> really well with a few other packages.
> 
> I don't want to force those packages on my users, but if they have them, I 
> want to extend them with my awesome type/function/whatever convenience.
> 
> What can be done in code and package manager to weakly link (not literally, I 
> just mean have that behaviour) my awesome type with all these other libraries?
> 
> This is a prelude to a pitch, if there isn't a decent alternative.
> 
> Tom
> 
> Sent from my iPhone
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Swift Evolution Status Page Now Available

2017-01-18 Thread Kyle Murray via swift-evolution

Hi Slava,

I updated it just now. Anyone can update the status of a proposal with a pull 
request, or you can commit directly if you have access. 

Example here: 
https://github.com/apple/swift-evolution/commit/24aafe9aa0cbcec757ab495c32e8718d14d5f809

ultramiraculous's PR for updating SE-0080 
(https://github.com/apple/swift-evolution/pull/586) is spot on, except that as 
of today, the proposal metadata just lives in the proposal Markdown, rather 
than in both the Markdown and the metadata index. 

-Kyle

> On Jan 18, 2017, at 7:27 PM, Slava Pestov  wrote:
> 
> Actually it’s available in swift-3.1-branch also.
> 
> Kyle, do you mind updating this, or is there a way we can submit updates?
> 
> Slava
> 
>> On Jan 18, 2017, at 2:06 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> This looks great, thanks!
>> 
>> SE-0080 was recently implemented by a contributor and will be available in 
>> Swift 4:
>> 
>> https://github.com/apple/swift/pull/4314
>> 
>> Slava
>> 
>>> On Jan 18, 2017, at 2:04 PM, Kyle Murray via swift-evolution 
>>>  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> We've just launched a new status page for keeping track of Swift Evolution 
>>> proposals. See the announcement in a post on the swift.org blog. 
>>> 
>>> A few of the benefits to the new page are:
>>> Search for proposals by criteria such as the proposal's author or Swift 
>>> version number.
>>> See which proposals have implementations in progress via the associated 
>>> JIRA issues.
>>> The status of a proposal is read directly from its Markdown source. The 
>>> separate XML file is no longer needed.
>>> 
>>> The status page displays progress and information about proposals as they 
>>> go through the evolution process. As always, please follow the standard 
>>> proposal template to keep to process running efficiently. Formatting your 
>>> proposal correctly also ensures that it's picked up and displayed correctly 
>>> on the status page. 
>>> 
>>> If you're interested in contributing to the status page's implementation, 
>>> see the steps for doing so in CONTRIBUTING.md. 
>>> 
>>> We're looking forward to your feedback!
>>> 
>>> Thanks,
>>> Kyle
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift Evolution Status Page Now Available

2017-01-18 Thread Slava Pestov via swift-evolution

Actually it’s available in swift-3.1-branch also.

Kyle, do you mind updating this, or is there a way we can submit updates?

Slava

> On Jan 18, 2017, at 2:06 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> This looks great, thanks!
> 
> SE-0080 was recently implemented by a contributor and will be available in 
> Swift 4:
> 
> https://github.com/apple/swift/pull/4314 
> 
> 
> Slava
> 
>> On Jan 18, 2017, at 2:04 PM, Kyle Murray via swift-evolution 
>> > wrote:
>> 
>> Hi everyone,
>> 
>> We've just launched a new status page 
>>  for keeping track of Swift 
>> Evolution proposals. See the announcement in a post on the swift.org blog 
>> . 
>> 
>> A few of the benefits to the new page are:
>> Search for proposals by criteria such as the proposal's author or Swift 
>> version number.
>> See which proposals have implementations in progress via the associated JIRA 
>> issues.
>> The status of a proposal is read directly from its Markdown source. The 
>> separate XML file is no longer needed.
>> 
>> The status page displays progress and information about proposals as they go 
>> through the evolution process. As always, please follow the standard 
>> proposal template 
>>  to 
>> keep to process running efficiently. Formatting your proposal correctly also 
>> ensures that it's picked up and displayed correctly on the status page. 
>> 
>> If you're interested in contributing to the status page's implementation, 
>> see the steps for doing so in CONTRIBUTING.md 
>> . 
>> 
>> We're looking forward to your feedback!
>> 
>> Thanks,
>> Kyle
>> ___
>> 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] Availability checking of libraries (weak linking?)

2017-01-18 Thread Ben Rimmington via swift-evolution


> On 19 Jan 2017, at 00:24, Swizzlr wrote:
> 
> Say I have an awesome type, and I provide some extensions that makes it work 
> really well with a few other packages.
> 
> I don't want to force those packages on my users, but if they have them, I 
> want to extend them with my awesome type/function/whatever convenience.
> 
> What can be done in code and package manager to weakly link (not literally, I 
> just mean have that behaviour) my awesome type with all these other libraries?
> 
> This is a prelude to a pitch, if there isn't a decent alternative.
> 
> Tom



#if canImport(...) should be available in Swift 4, thanks to Robert Widmann.




-- Ben

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

[swift-evolution] Availability checking of libraries (weak linking?)

2017-01-18 Thread Swizzlr via swift-evolution

Say I have an awesome type, and I provide some extensions that makes it work 
really well with a few other packages.

I don't want to force those packages on my users, but if they have them, I want 
to extend them with my awesome type/function/whatever convenience.

What can be done in code and package manager to weakly link (not literally, I 
just mean have that behaviour) my awesome type with all these other libraries?

This is a prelude to a pitch, if there isn't a decent alternative.

Tom

Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift Evolution Status Page Now Available

2017-01-18 Thread Slava Pestov via swift-evolution

This looks great, thanks!

SE-0080 was recently implemented by a contributor and will be available in 
Swift 4:

https://github.com/apple/swift/pull/4314

Slava

> On Jan 18, 2017, at 2:04 PM, Kyle Murray via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> We've just launched a new status page 
>  for keeping track of Swift 
> Evolution proposals. See the announcement in a post on the swift.org blog 
> . 
> 
> A few of the benefits to the new page are:
> Search for proposals by criteria such as the proposal's author or Swift 
> version number.
> See which proposals have implementations in progress via the associated JIRA 
> issues.
> The status of a proposal is read directly from its Markdown source. The 
> separate XML file is no longer needed.
> 
> The status page displays progress and information about proposals as they go 
> through the evolution process. As always, please follow the standard proposal 
> template 
>  to 
> keep to process running efficiently. Formatting your proposal correctly also 
> ensures that it's picked up and displayed correctly on the status page. 
> 
> If you're interested in contributing to the status page's implementation, see 
> the steps for doing so in CONTRIBUTING.md 
> . 
> 
> We're looking forward to your feedback!
> 
> Thanks,
> Kyle
> ___
> 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] Swift Evolution Status Page Now Available

2017-01-18 Thread Kyle Murray via swift-evolution

Hi everyone,

We've just launched a new status page 
 for keeping track of Swift Evolution 
proposals. See the announcement in a post on the swift.org blog 
. 

A few of the benefits to the new page are:
Search for proposals by criteria such as the proposal's author or Swift version 
number.
See which proposals have implementations in progress via the associated JIRA 
issues.
The status of a proposal is read directly from its Markdown source. The 
separate XML file is no longer needed.

The status page displays progress and information about proposals as they go 
through the evolution process. As always, please follow the standard proposal 
template 
 to keep 
to process running efficiently. Formatting your proposal correctly also ensures 
that it's picked up and displayed correctly on the status page. 

If you're interested in contributing to the status page's implementation, see 
the steps for doing so in CONTRIBUTING.md 
. 

We're looking forward to your feedback!

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread Chris Lattner via swift-evolution

On Jan 18, 2017, at 10:45 AM, John McCall via swift-evolution 
 wrote:
>> 
>> That's certainly true of code that makes unaudited use of `unsafe` 
>> constructs that can violate safety without any checking. It's my hope that 
>> our normal safety checks are  thorough and fire early enough that your 
>> subprocess would crash before wide-system compromise happens. In an "actor" 
>> or similar model, even if we decide we don't want to pay for unwinding to 
>> fully clean up after the crashed actor, that crash could still at least be 
>> noted by a coordinator actor, which in your server situation could handle 
>> the problem by not accepting any new connections and letting its existing 
>> connections finish before restarting the process, or in an iOS-like mobile 
>> situation could  trigger serialization of the current user state so that the 
>> process can be transparently killed and restarted. In either situation, 
>> perhaps we'd want to "taint" actors that use unsafe constructs so that their 
>> failure can't be recovered at all.
> 
> This seems like basically the right approach to me.  It means we don't make 
> any effort to "clean up" the failing actor — essentially, it's treated as if 
> it were just deadlocked — which means we don't pay the pervasive code-size 
> costs of unwinding.  That's even fairly likely to leave the process in a 
> state that can still be usefully debugged (as opposed to unwinding stacks, 
> which completely destroys the execution context).  But there's still an 
> opportunity to react and try to wind up other tasks.
> 
> I'm not sure it makes any sense to call out actors that have used unsafe 
> constructs as somehow specially unrecoverable.  If the concern is that the 
> unsafe code may corrupt the other actors, well, that's true, but (1) that 
> implies that you have to forbid recovery if *any* actor has used unsafe 
> constructs, since low-level corruption can be passed between actors when they 
> communicate normally, and (2) that's equally true of all sorts of high-level 
> corruption that don't depend on unsafe constructs, and which the failing 
> assertion may be the first indication of.

I agree with John on both points.  To the second, keep in mind that lots of 
safe constructs are built in terms of unsafe constructs  (e.g. Array).

-Chris

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

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Tony Allevato via swift-evolution

On Wed, Jan 18, 2017 at 10:33 AM Guillaume Lessard via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> If stressing the type-checker is the only problem, then maybe we should
> improve the type-checker, instead of placing that burden on every user of
> the language.
> >
> > That's a nice sentiment, and there's certainly a lot of work we have yet
> to do on the type checker to make it generally better. Higher-order
> functions like `reduce` naturally chain into larger expressions, though,
> and having such a fundamental sequence operation drag down the type-checker
> every time you use it would be unfortunate if we can avoid overloading the
> name.
>
> Empathy for the compiler is nice, too, but users and developers are more
> important. Given that, it seems to me that the default option should be to
> overload the function, unless the alternative is actually clearer.
>

Empathy for users and developers is important, but if the solution adds too
much burden to the type checker and blows up your compile time or gives you
"expression too complex to be solved" errors, then users/developers don't
benefit at all from that either. I don't think it would have been brought
up if there weren't significant concerns about how such an overload would
affect build time or ability to complete. (One of my code bases really
pushes the type checker to its limits and I can sympathize with the
concern.)



> In the spirit of comparing burdens, how much more compilation time would
> be spent if `reduce` is overloaded? How much execution time would be saved
> by users thanks to developers having found the right option?
>
> This being said, it seems to me that the example that started this
> discussion (building a collection) is among the worst-performing cases for
> the functional-style `reduce`. What are other cases where the inout version
> is a big win? If this is specifically about building collections or
> sequences, could a more specific type signature help?
>
> Arguing both for and against,
> Guillaume Lessard
>
> ___
> 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] Property Behaviors and Swift 4.0 Stage 1.

2017-01-18 Thread Wallacy via swift-evolution

Is Property Behaviors considered for Stage 1?

https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md

Because the project roadmap says:

The high-priority features supporting Stage 1's source and ABI stability
goals are:
...
Resilience: resilience provides a way for public APIs to evolve over time,
while maintaining a stable ABI. For example, resilience eliminates the fragile
base class problem  that
occurs in some object-oriented languages (e.g., C++) by describing the
types of API changes that can be made without breaking ABI (e.g., "a new
stored property or method can be added to a class").
...

And i think this feature will help with that. Not a complete solution for
resilience problem, but "provides a way for public APIs to evolve over time
".

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

Re: [swift-evolution] Testing enum cases with associated values

2017-01-18 Thread Andy Chou via swift-evolution

I agree it’s overkill for what I’m really looking for, which is a simple way to 
get a Bool result from testing an enum against a specific case, without looking 
at the associated values.

Andy

> On Jan 18, 2017, at 10:15 AM, Tony Allevato  wrote:
> 
> FWIW, I'm not convinced that making enum values look like structs with 
> optional properties for the union of all their cases is a good idea. It's 
> certainly not something I would want added to all of my enums by default, and 
> it feels IMO like it's just an awkward hack around the fact that pattern 
> matching is a bit verbose in some scenarios because Swift doesn't provide a 
> case-expression to let you test/bind as part of a larger expression.
> 
> 
> On Wed, Jan 18, 2017 at 10:08 AM Andy Chou via swift-evolution 
> > wrote:
> That’s an interesting proposal. Here’s a link for reference:  
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html
>  
> 
> 
> The one thing is the proposed syntax doesn’t handle enum cases without 
> payloads. I think that could be handled by an optional Void, so this comment 
> in the original proposal:
> 
> > Only enum cases with a payload can be used with this syntax (it would make 
> > no sens for cases without a payload).
> 
> Would be changed to allow for empty payloads turning into Void?. For example:
> 
>> enum Result {
>> case success(Int)
>> case failure
>> }
>> 
>> let r: Result = foo()
>> 
>> let x: Int? = r.success
>> let y: Void? = r.failure
>> 
>> assert(r.success == Optional(42))
>> assert(r.failure == nil)
> I think it’s a reasonable compromise, though I still think it’s a bit awkward 
> for the common case. Looks like this is being postponed for now, so we’ll 
> have to live with the alternatives.
> 
> Andy
> 
> 
>> On Jan 18, 2017, at 12:20 AM, Anton Zhilin > > wrote:
>> 
>> AFAICS, Andy needs not default implementations of Equatable, but 
>> cases-as-optional-properties—this topic has also been discussed on the list.
>> 
>> enum Result {
>> case success(Int)
>> case failure(String)
>> }
>> 
>> let r: Result = foo()
>> 
>> let x: Int? = r.success
>> let y: String? = r.failure
>> 
>> assert(r.success == Optional(42))
>> assert(r.failure == nil)
> 
> ___
> 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] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread John McCall via swift-evolution

> On Jan 18, 2017, at 9:06 AM, Joe Groff via swift-evolution 
>  wrote:
>> On Jan 18, 2017, at 12:04 AM, Rien via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jan 17, 2017, at 7:13 PM, Dave Abrahams  wrote:
 
 
 on Tue Jan 17 2017, Jonathan Hull  wrote:
 
> Bringing it back towards the initial post, what if there was a
> separation from true needs-to-take-down-the-entire-system trapping and
> things like out-of-bounds and overflow errors which could stop at
> thread/actor bounds (or in some cases even be recovered)?
> 
> The latter were the ones I was targeting with my proposal.  They live
> in this grey area, because honestly, they should be throwing errors if
> not for the performance overhead and usability issues.  
 
 I fundamentally disagree with that statement.  There is value in
 declaring certain program behaviors illegal, and in general for things
 like out-of-bounds access and overflow no sensible recovery (where
 “recovery” means something that would allow the program to continue
 reliably) is possible.  
>>> 
>>> I think we do fundamentally disagree.  I know I come from a very different 
>>> background (Human-Computer Interaction & Human Factors) than most people 
>>> here, and I am kind of the odd man out, but I have never understood this 
>>> viewpoint for anything but the most severe cases where the system itself is 
>>> in danger of being compromised (certainly not for an index out of bounds).  
>>> In my mind “fail fast” is great for iterating in development builds, but 
>>> once you are deploying, the user’s needs should come ahead of the 
>>> programmer’s.
>>> 
>>> Shouldn’t a system be as robust as possible
>> 
>> Yes
>> 
>>> and try to minimize the fallout from any failure point?
>> 
>> That is in direct conflict with the robustness
>> Once an error is detected that is not handled by the immediate code, it must 
>> be assumed that a worst-case scenario happened. And further damage to the 
>> user can only be prevent by bringing down the app. Even if that means losing 
>> all work in progress.
>> 
>> A compromised system must be prevent from accessing any resources. Once a 
>> system is compromised the risk to the user is *much* higher than simply 
>> loosing work in progress. He might loose his job, career, etc.
> 
> That's certainly true of code that makes unaudited use of `unsafe` constructs 
> that can violate safety without any checking. It's my hope that our normal 
> safety checks are  thorough and fire early enough that your subprocess would 
> crash before wide-system compromise happens. In an "actor" or similar model, 
> even if we decide we don't want to pay for unwinding to fully clean up after 
> the crashed actor, that crash could still at least be noted by a coordinator 
> actor, which in your server situation could handle the problem by not 
> accepting any new connections and letting its existing connections finish 
> before restarting the process, or in an iOS-like mobile situation could  
> trigger serialization of the current user state so that the process can be 
> transparently killed and restarted. In either situation, perhaps we'd want to 
> "taint" actors that use unsafe constructs so that their failure can't be 
> recovered at all.

This seems like basically the right approach to me.  It means we don't make any 
effort to "clean up" the failing actor — essentially, it's treated as if it 
were just deadlocked — which means we don't pay the pervasive code-size costs 
of unwinding.  That's even fairly likely to leave the process in a state that 
can still be usefully debugged (as opposed to unwinding stacks, which 
completely destroys the execution context).  But there's still an opportunity 
to react and try to wind up other tasks.

I'm not sure it makes any sense to call out actors that have used unsafe 
constructs as somehow specially unrecoverable.  If the concern is that the 
unsafe code may corrupt the other actors, well, that's true, but (1) that 
implies that you have to forbid recovery if *any* actor has used unsafe 
constructs, since low-level corruption can be passed between actors when they 
communicate normally, and (2) that's equally true of all sorts of high-level 
corruption that don't depend on unsafe constructs, and which the failing 
assertion may be the first indication of.

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread Dave Abrahams via swift-evolution


on Tue Jan 17 2017, Jonathan Hull  wrote:

>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jan 17 2017, Jonathan Hull > > wrote:
>> 
>
>>> Bringing it back towards the initial post, what if there was a
>>> separation from true needs-to-take-down-the-entire-system trapping and
>>> things like out-of-bounds and overflow errors which could stop at
>>> thread/actor bounds (or in some cases even be recovered)?
>>> 
>>> The latter were the ones I was targeting with my proposal.  They live
>>> in this grey area, because honestly, they should be throwing errors if
>>> not for the performance overhead and usability issues.  
>> 
>> I fundamentally disagree with that statement.  There is value in
>> declaring certain program behaviors illegal, and in general for things
>> like out-of-bounds access and overflow no sensible recovery (where
>> “recovery” means something that would allow the program to continue
>> reliably) is possible.  
>
> I think we do fundamentally disagree.  I know I come from a very
> different background (Human-Computer Interaction & Human Factors) than
> most people here, and I am kind of the odd man out, but I have never
> understood this viewpoint for anything but the most severe cases where
> the system itself is in danger of being compromised (certainly not for
> an index out of bounds).  In my mind “fail fast” is great for
> iterating in development builds, but once you are deploying, the
> user’s needs should come ahead of the programmer’s.

The question is really whether continuing when the program no longer
understands its own state is in the user's best interest.  Bad
consequences are just as easy to imagine as benign ones.

>
>
> Shouldn’t a system be as robust as possible and try to minimize the
> fallout from any failure point?  I don’t consider crashing and losing
> all of the user’s data minimal.  

That's why we need emergency shutdown facilities.


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

Re: [swift-evolution] Testing enum cases with associated values

2017-01-18 Thread Tony Allevato via swift-evolution

FWIW, I'm not convinced that making enum values look like structs with
optional properties for the union of all their cases is a good idea. It's
certainly not something I would want added to all of my enums by default,
and it feels IMO like it's just an awkward hack around the fact that
pattern matching is a bit verbose in some scenarios because Swift doesn't
provide a case-expression to let you test/bind as part of a larger
expression.


On Wed, Jan 18, 2017 at 10:08 AM Andy Chou via swift-evolution <
swift-evolution@swift.org> wrote:

> That’s an interesting proposal. Here’s a link for reference:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html
>
> The one thing is the proposed syntax doesn’t handle enum cases without
> payloads. I think that could be handled by an optional Void, so this
> comment in the original proposal:
>
> > Only enum cases with a payload can be used with this syntax (it would
> make no sens for cases without a payload).
>
> Would be changed to allow for empty payloads turning into Void?. For
> example:
>
> enum Result {
> case success(Int)
> case failure
> }
>
> let r: Result = foo()
>
> let x: Int? = r.success
> let y: Void? = r.failure
>
> assert(r.success == Optional(42))
> assert(r.failure == nil)
>
> I think it’s a reasonable compromise, though I still think it’s a bit
> awkward for the common case. Looks like this is being postponed for now, so
> we’ll have to live with the alternatives.
>
> Andy
>
>
> On Jan 18, 2017, at 12:20 AM, Anton Zhilin  wrote:
>
> AFAICS, Andy needs not default implementations of Equatable, but
> cases-as-optional-properties—this topic has also been discussed on the list.
>
> enum Result {
> case success(Int)
> case failure(String)
> }
>
> let r: Result = foo()
>
> let x: Int? = r.success
> let y: String? = r.failure
>
> assert(r.success == Optional(42))
> assert(r.failure == nil)
>
> 
>
>
> ___
> 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] Testing enum cases with associated values

2017-01-18 Thread Andy Chou via swift-evolution

That’s an interesting proposal. Here’s a link for reference:  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027287.html
 


The one thing is the proposed syntax doesn’t handle enum cases without 
payloads. I think that could be handled by an optional Void, so this comment in 
the original proposal:

> Only enum cases with a payload can be used with this syntax (it would make no 
> sens for cases without a payload).

Would be changed to allow for empty payloads turning into Void?. For example:

> enum Result {
> case success(Int)
> case failure
> }
> 
> let r: Result = foo()
> 
> let x: Int? = r.success
> let y: Void? = r.failure
> 
> assert(r.success == Optional(42))
> assert(r.failure == nil)
I think it’s a reasonable compromise, though I still think it’s a bit awkward 
for the common case. Looks like this is being postponed for now, so we’ll have 
to live with the alternatives.

Andy


> On Jan 18, 2017, at 12:20 AM, Anton Zhilin  wrote:
> 
> AFAICS, Andy needs not default implementations of Equatable, but 
> cases-as-optional-properties—this topic has also been discussed on the list.
> 
> enum Result {
> case success(Int)
> case failure(String)
> }
> 
> let r: Result = foo()
> 
> let x: Int? = r.success
> let y: String? = r.failure
> 
> assert(r.success == Optional(42))
> assert(r.failure == nil)

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

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Guillaume Lessard via swift-evolution

> On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution 
>>  wrote:
>> 
>> If stressing the type-checker is the only problem, then maybe we should 
>> improve the type-checker, instead of placing that burden on every user of 
>> the language.
> 
> That's a nice sentiment, and there's certainly a lot of work we have yet to 
> do on the type checker to make it generally better. Higher-order functions 
> like `reduce` naturally chain into larger expressions, though, and having 
> such a fundamental sequence operation drag down the type-checker every time 
> you use it would be unfortunate if we can avoid overloading the name.

Empathy for the compiler is nice, too, but users and developers are more 
important. Given that, it seems to me that the default option should be to 
overload the function, unless the alternative is actually clearer.

In the spirit of comparing burdens, how much more compilation time would be 
spent if `reduce` is overloaded? How much execution time would be saved by 
users thanks to developers having found the right option?

This being said, it seems to me that the example that started this discussion 
(building a collection) is among the worst-performing cases for the 
functional-style `reduce`. What are other cases where the inout version is a 
big win? If this is specifically about building collections or sequences, could 
a more specific type signature help?

Arguing both for and against,
Guillaume Lessard

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Tony Allevato via swift-evolution

Ok, this actually does feel a bit strange. The behavior you're seeing seems
to be a consequence of [SE-0091](
https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md),
but it looks like you're seeing different behavior than what I described in
the "Class types and inheritance" section of that proposal.

If Sub has `==(Sub, Sub)` implemented as a *static* function, I just tried
it and it's *ignored* (`==(Super, Super)` gets called instead), even when
the two actual arguments are known to be statically of type Sub. I think
this is because of the way that proposal was implemented: when it sees that
`Sub` extends `Super`, which conforms to `Equatable`, it appears that it's
only looking for static overloads of `==` that are satisfied at the *point
of conformance*, which would be `==(Super, Super)` (because `Super`
conforms to `Equatable where Self == Super`). The wording of the proposal
makes this case: "Then, we say that we do not consider an operator function
if it implements a protocol requirement, because the requirement is a
generalization of all of the operator functions that satisfy that
requirement."

Contrarily, if you provide `==(Sub, Sub)` as a global function instead of a
static one, it *does* get called. I think in this case, the type checker
gets the whole set of candidate operators (which, unlike above, includes
the global `==(Sub, Sub)`), and it gets used because it's a more specific
match?

Can someone from the core team chime in and say whether this is intentional
behavior? It feels wrong that simply changing the location where the
operator is defined would change the behavior like this.

FWIW, to avoid these sharp edges, there's no need to implement `==` for
subtypes; since you have to use an overridable `equals` method anyway, just
have the base type implement `==` to delegate to it, and then have subtypes
override `equals` alone.

On Wed, Jan 18, 2017 at 9:36 AM Francisco Javier Fernández Toro <
f...@gokarumi.com> wrote:

> Yeah guys, you are right, my code is busted, I was trying to point
> something different out:
>
> The next code is showing the possible issue. In theory to make a class
> Equatable, you just have to mark it with the Equatable protocol and
> implement `==` as a static function or as a global one.
>
> If you don't override the equal method and you just invoke your super
> class equality method you'll get something like this:
>
> ```
> class Superclass : Equatable {
> let foo: Int
>
> init(foo: Int) { self.foo = foo }
>
> func equal(to: Superclass) -> Bool {
> return foo == to.foo
> }
>
> static func == (lhs: Superclass, rhs: Superclass) -> Bool {
> return lhs.equal(to: rhs)
> }
> }
>
> class Subclass: Superclass {
> let bar: Int
> init(foo: Int, bar: Int) {
> self.bar = bar
> super.init(foo: foo)
> }
>
> func equal(to: Subclass) -> Bool {
> return bar == to.bar && super.equal(to: to)
> }
>
> static func == (lhs: Subclass, rhs: Subclass) -> Bool {
> return lhs.equal(to: rhs)
> }
> }
>
> class SubclassWithDifferentOperator: Subclass {
> static func != (lhs: SubclassWithDifferentOperator, rhs:
> SubclassWithDifferentOperator) -> Bool {
> return !(lhs.equal(to: rhs))
> }
> }
>
> let a = Subclass(foo: 1, bar: 1)
> let b = Subclass(foo: 1, bar: 2)
>
> (a == b) != (a != b) // Prints: false, not expected
>
> let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
> let y = SubclassWithDifferentOperator(foo: 1, bar: 2)
>
> (x == y) != (x != y) // Prints: true, expected
> ```
>
> So, after adding a couple of `print` statement in those equal method what
> I can see is that for Subclass, when you are need to call `!=` what Swift
> is doing is using `func ==(Superclass, Superclass)` and apply `!` as Tony
> has pointed out.
>
> What I cannot understand is why is not using `func == (Subclass, Subclass)`
>
> I hope it makes more sense now.
>
> ---
> Fran Fernandez
>
> On Wed, Jan 18, 2017 at 6:13 PM, Tony Allevato 
> wrote:
>
> This seems to work for me:
>
> ```
> class Super: Equatable {
> let x: Int
> init(x: Int) {
> self.x = x
> }
> func equals(_ rhs: Super) -> Bool {
> return x == rhs.x
> }
> static func ==(lhs: Super, rhs: Super) -> Bool {
> return lhs.equals(rhs)
> }
> }
>
> class Sub: Super {
> let y: Int
> init(x: Int, y: Int) {
> self.y = y
> super.init(x: x)
> }
> override func equals(_ rhs: Super) -> Bool {
> if let rhs = rhs as? Sub {
> return y == rhs.y && super.equals(rhs)
> }
> return false
> }
> }
>
> let a = Sub(x: 1, y: 1)
> let b = Sub(x: 1, y: 2)
> let c = Sub(x: 1, y: 1)
>
> a == b  // false, expected
> a == c  // true, expected
> a != b  // true, expected
> a != c  // false, expected
> ```
>
> Additionally, when I made the change Joe suggested, your code also

Re: [swift-evolution] Testing enum cases with associated values

2017-01-18 Thread Andy Chou via swift-evolution

This is nice, but it doesn’t solve the issue at hand because there is only one 
enum value. I would like to have something like:

if value == .TWO { … }

I can’t use this == operator for this because I’d have to create:

if value == .TWO(str) { … }

But I don’t have a specific str, and I want the condition to be true no matter 
what the value of str is.

Andy


> On Jan 17, 2017, at 10:53 PM, Rien  wrote:
> 
> A guy named Matthias recently commented this on my blog:
> 
> func == (left: Enum3, right: Enum3) -> Bool {
> switch (left, right) {
> case (.ONE, .ONE):
> return true
> case (.TWO(let str1), .TWO(let str2)):
> return str1 == str2
> default:
> return false
> }
> }
> 
> http://swiftrien.blogspot.nl/2015/05/swift-enum-compare-design-pattern.html
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 18 Jan 2017, at 01:15, Andy Chou via swift-evolution 
>>  wrote:
>> 
>> Enums with associated values can be very useful in Swift, but once you add 
>> associated values you lose some properties, especially equality:
>> 
>> ```
>> enum AuthenticationResponse {
>>   case success
>>   case alert(Alert)
>>   case reauthenticate
>> }
>> ```
>> 
>> Testing for a specific case requires a switch statement or the if pattern 
>> match syntax:
>> 
>>  if case .success = response { … }
>> 
>> But while this works well for control flow, it doesn’t work well for cases 
>> where we want a Bool, such as assert(). There are also common situations 
>> with lists and libraries like RxSwift where a filtering function uses a Bool 
>> valued closure. In these situations the best we can do is write functions 
>> like:
>> 
>> ```
>> enum AuthenticationResponse {
>>   case success
>>   case alert(Alert)
>>   case reauthenticate
>> 
>>   var isSuccess: Bool {
>>   if case .success = self {
>>   return true
>>   } else {
>>   return false
>>   }
>>   }
>> 
>>   var isReauthenticate: Bool {
>>   if case .reauthenticate = self {
>>   return true
>>   } else {
>>   return false
>>   }
>>   }
>> 
>>   var isAlert: Bool {
>>   if case .alert(_) = self {
>>   return true
>>   } else {
>>   return false
>>   }
>>   }
>> }
>> ```
>> Any suggestions better than writing out each of these functions explicitly?
>> 
>> The conditional conformances proposal coming in Swift 4 solves some of this 
>> issue, but not completely. If Alert isn’t Equatable, it is still useful to 
>> test whether the result is .success.  For example:
>> 
>>  assert(response == .success)
>> 
>> This is perfectly intelligible and I would argue that equality should be 
>> defined for enums with associated values omitted:
>> 
>>  assert(response == .alert)
>> 
>> Here we are ignoring the associated values, and merely checking if the enum 
>> case is the same.
>> 
>> Andy
>> 
>> ___
>> 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] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Francisco Javier Fernández Toro via swift-evolution

Yeah guys, you are right, my code is busted, I was trying to point
something different out:

The next code is showing the possible issue. In theory to make a class
Equatable, you just have to mark it with the Equatable protocol and
implement `==` as a static function or as a global one.

If you don't override the equal method and you just invoke your super class
equality method you'll get something like this:

```
class Superclass : Equatable {
let foo: Int

init(foo: Int) { self.foo = foo }

func equal(to: Superclass) -> Bool {
return foo == to.foo
}

static func == (lhs: Superclass, rhs: Superclass) -> Bool {
return lhs.equal(to: rhs)
}
}

class Subclass: Superclass {
let bar: Int
init(foo: Int, bar: Int) {
self.bar = bar
super.init(foo: foo)
}

func equal(to: Subclass) -> Bool {
return bar == to.bar && super.equal(to: to)
}

static func == (lhs: Subclass, rhs: Subclass) -> Bool {
return lhs.equal(to: rhs)
}
}

class SubclassWithDifferentOperator: Subclass {
static func != (lhs: SubclassWithDifferentOperator, rhs:
SubclassWithDifferentOperator) -> Bool {
return !(lhs.equal(to: rhs))
}
}

let a = Subclass(foo: 1, bar: 1)
let b = Subclass(foo: 1, bar: 2)

(a == b) != (a != b) // Prints: false, not expected

let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
let y = SubclassWithDifferentOperator(foo: 1, bar: 2)

(x == y) != (x != y) // Prints: true, expected
```

So, after adding a couple of `print` statement in those equal method what I
can see is that for Subclass, when you are need to call `!=` what Swift is
doing is using `func ==(Superclass, Superclass)` and apply `!` as Tony has
pointed out.

What I cannot understand is why is not using `func == (Subclass, Subclass)`

I hope it makes more sense now.

---
Fran Fernandez

On Wed, Jan 18, 2017 at 6:13 PM, Tony Allevato 
wrote:

> This seems to work for me:
>
> ```
> class Super: Equatable {
> let x: Int
> init(x: Int) {
> self.x = x
> }
> func equals(_ rhs: Super) -> Bool {
> return x == rhs.x
> }
> static func ==(lhs: Super, rhs: Super) -> Bool {
> return lhs.equals(rhs)
> }
> }
>
> class Sub: Super {
> let y: Int
> init(x: Int, y: Int) {
> self.y = y
> super.init(x: x)
> }
> override func equals(_ rhs: Super) -> Bool {
> if let rhs = rhs as? Sub {
> return y == rhs.y && super.equals(rhs)
> }
> return false
> }
> }
>
> let a = Sub(x: 1, y: 1)
> let b = Sub(x: 1, y: 2)
> let c = Sub(x: 1, y: 1)
>
> a == b  // false, expected
> a == c  // true, expected
> a != b  // true, expected
> a != c  // false, expected
> ```
>
> Additionally, when I made the change Joe suggested, your code also worked,
> so maybe there was an error when you updated it?
>
> FWIW, the default implementation of != just invokes !(a == b) <
> https://github.com/apple/swift/blob/master/stdlib/
> public/core/Equatable.swift#L179-L181>, so I believe it's *impossible*
> (well, uh, barring busted RAM or processor I guess) for it to return the
> wrong value for the same arguments if you only implement ==.
>
>
>
> On Wed, Jan 18, 2017 at 8:52 AM Francisco Javier Fernández Toro via
> swift-evolution  wrote:
>
>> Thank you for your answer Joe,
>>
>> you are right the equal(to:) wasn't a valid override, but even after
>> using the one you've proposed, the behavior is not the expected one
>>
>>
>> let a = Subclass(foo: 1, bar: 1)
>> let b = Subclass(foo: 1, bar: 2)
>>
>> (a == b) != (a != b) // Prints true
>>
>> let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
>> let y = SubclassWithDifferentOperator(foo: 1, bar: 2)
>>
>> (x == y) != (x != y) // Prints false
>>
>> As you can see above if a subclass does not implement the global function
>> !=, the equal operation seems to be broken.
>>
>> ---
>>
>> Fran Fernandez
>>
>> On Wed, Jan 18, 2017 at 5:44 PM, Joe Groff  wrote:
>>
>>
>> > On Jan 18, 2017, at 2:59 AM, Francisco Javier Fernández Toro via
>> swift-evolution  wrote:
>> >
>> > Hi,
>> >
>> > I've found that when you have a class hierarchy which implements
>> Equatable, if you want to have the != operator working as expected, you
>> need to override it, it's not enough with ==.
>> >
>> > If you don't define you own subclass != operator, Swift compiler will
>> use the super class to resolve that operation.
>> >
>> > Is there any reason for that?
>>
>> The `equal(to:)` method inside `Subclass` is not a valid override of
>> `Superclass` because its argument only accepts `Subclass` instances, but
>> the parent method needs to work with all `Superclass` instances. If you
>> write it as an override, it should work:
>>
>> class Subclass: Superclass {
>> let bar: Int
>> init(foo: Int, bar: Int) {
>> self.bar = bar
>> super.init(foo: foo)
>>

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Joe Groff via swift-evolution

> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I don't think we should replace the current `reduce` with the `inout` 
> version, also because the current reduce can be really useful as well (e.g. 
> when the return type is an Int). 
> 
> One downside of having a different name is that it'll be harder to discover 
> this version. If stressing the type-checker is the only problem, then maybe 
> we should improve the type-checker, instead of placing that burden on every 
> user of the language.

That's a nice sentiment, and there's certainly a lot of work we have yet to do 
on the type checker to make it generally better. Higher-order functions like 
`reduce` naturally chain into larger expressions, though, and having such a 
fundamental sequence operation drag down the type-checker every time you use it 
would be unfortunate if we can avoid overloading the name.

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Tony Allevato via swift-evolution

This seems to work for me:

```
class Super: Equatable {
let x: Int
init(x: Int) {
self.x = x
}
func equals(_ rhs: Super) -> Bool {
return x == rhs.x
}
static func ==(lhs: Super, rhs: Super) -> Bool {
return lhs.equals(rhs)
}
}

class Sub: Super {
let y: Int
init(x: Int, y: Int) {
self.y = y
super.init(x: x)
}
override func equals(_ rhs: Super) -> Bool {
if let rhs = rhs as? Sub {
return y == rhs.y && super.equals(rhs)
}
return false
}
}

let a = Sub(x: 1, y: 1)
let b = Sub(x: 1, y: 2)
let c = Sub(x: 1, y: 1)

a == b  // false, expected
a == c  // true, expected
a != b  // true, expected
a != c  // false, expected
```

Additionally, when I made the change Joe suggested, your code also worked,
so maybe there was an error when you updated it?

FWIW, the default implementation of != just invokes !(a == b) <
https://github.com/apple/swift/blob/master/stdlib/public/core/Equatable.swift#L179-L181>,
so I believe it's *impossible* (well, uh, barring busted RAM or processor I
guess) for it to return the wrong value for the same arguments if you only
implement ==.



On Wed, Jan 18, 2017 at 8:52 AM Francisco Javier Fernández Toro via
swift-evolution  wrote:

> Thank you for your answer Joe,
>
> you are right the equal(to:) wasn't a valid override, but even after
> using the one you've proposed, the behavior is not the expected one
>
>
> let a = Subclass(foo: 1, bar: 1)
> let b = Subclass(foo: 1, bar: 2)
>
> (a == b) != (a != b) // Prints true
>
> let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
> let y = SubclassWithDifferentOperator(foo: 1, bar: 2)
>
> (x == y) != (x != y) // Prints false
>
> As you can see above if a subclass does not implement the global function
> !=, the equal operation seems to be broken.
>
> ---
>
> Fran Fernandez
>
> On Wed, Jan 18, 2017 at 5:44 PM, Joe Groff  wrote:
>
>
> > On Jan 18, 2017, at 2:59 AM, Francisco Javier Fernández Toro via
> swift-evolution  wrote:
> >
> > Hi,
> >
> > I've found that when you have a class hierarchy which implements
> Equatable, if you want to have the != operator working as expected, you
> need to override it, it's not enough with ==.
> >
> > If you don't define you own subclass != operator, Swift compiler will
> use the super class to resolve that operation.
> >
> > Is there any reason for that?
>
> The `equal(to:)` method inside `Subclass` is not a valid override of
> `Superclass` because its argument only accepts `Subclass` instances, but
> the parent method needs to work with all `Superclass` instances. If you
> write it as an override, it should work:
>
> class Subclass: Superclass {
> let bar: Int
> init(foo: Int, bar: Int) {
> self.bar = bar
> super.init(foo: foo)
> }
>
> override func equal(to: Superclass) -> Bool {
>   if let toSub = to as? Subclass {
> return bar == toSub.bar && super.equal(to: to)
>   }
>   return false
> }
> }
>
> We should probably raise an error, or at least a warning, instead of
> silently accepting your code as an overload. Would you be able to file a
> bug on bugs.swift.org about that?
>
> -Joe
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Matthew Johnson via swift-evolution


> On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jan 18, 2017, at 8:50 AM, Tony Allevato  wrote:
>> 
>> Good point—I hadn't considered the distinction.
>> 
>> Does that mean a future version of Swift might allow `let` in a protocol to 
>> indicate a value that must be immutable after initialization, such that a 
>> computed `var { get }` wouldn't satisfy it?
> 
> It's conceivable that even computed `let` properties could be supported, if 
> the getter implementation is a pure function of `self`.

How would that work when `self` is mutable?

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

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

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Adrian Zubarev via swift-evolution

Yeah I’m looking for that day too. :)

class ImmutableThing : AnyValue { … }


-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 18:03:59, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Jan 18, 2017, at 11:00 AM, Joe Groff  wrote:


On Jan 18, 2017, at 8:57 AM, Matthew Johnson  wrote:


On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution 
 wrote:


On Jan 18, 2017, at 8:50 AM, Tony Allevato  wrote:

Good point—I hadn't considered the distinction.

Does that mean a future version of Swift might allow `let` in a protocol to 
indicate a value that must be immutable after initialization, such that a 
computed `var { get }` wouldn't satisfy it?

It's conceivable that even computed `let` properties could be supported, if the 
getter implementation is a pure function of `self`.

How would that work when `self` is mutable?

The exact meaning of "pure" and "immutable" would have to be designed. To a 
first approximation, you could say a pure method would only be able to read 
immutable global or class data (which is itself `let` or `pure func`, not 
anything that's potentially mutable) in addition to its own arguments.

Got it.  That makes sense.  Looking forward to the expanded pure / immutable 
model someday!


-Joe

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread Joe Groff via swift-evolution


> On Jan 18, 2017, at 12:04 AM, Rien via swift-evolution 
>  wrote:
> 
>> 
>> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Tue Jan 17 2017, Jonathan Hull  wrote:
>>> 
 Bringing it back towards the initial post, what if there was a
 separation from true needs-to-take-down-the-entire-system trapping and
 things like out-of-bounds and overflow errors which could stop at
 thread/actor bounds (or in some cases even be recovered)?
 
 The latter were the ones I was targeting with my proposal.  They live
 in this grey area, because honestly, they should be throwing errors if
 not for the performance overhead and usability issues.  
>>> 
>>> I fundamentally disagree with that statement.  There is value in
>>> declaring certain program behaviors illegal, and in general for things
>>> like out-of-bounds access and overflow no sensible recovery (where
>>> “recovery” means something that would allow the program to continue
>>> reliably) is possible.  
>> 
>> I think we do fundamentally disagree.  I know I come from a very different 
>> background (Human-Computer Interaction & Human Factors) than most people 
>> here, and I am kind of the odd man out, but I have never understood this 
>> viewpoint for anything but the most severe cases where the system itself is 
>> in danger of being compromised (certainly not for an index out of bounds).  
>> In my mind “fail fast” is great for iterating in development builds, but 
>> once you are deploying, the user’s needs should come ahead of the 
>> programmer’s.
>> 
>> Shouldn’t a system be as robust as possible
> 
> Yes
> 
>> and try to minimize the fallout from any failure point?
> 
> That is in direct conflict with the robustness
> Once an error is detected that is not handled by the immediate code, it must 
> be assumed that a worst-case scenario happened. And further damage to the 
> user can only be prevent by bringing down the app. Even if that means losing 
> all work in progress.
> 
> A compromised system must be prevent from accessing any resources. Once a 
> system is compromised the risk to the user is *much* higher than simply 
> loosing work in progress. He might loose his job, career, etc.

That's certainly true of code that makes unaudited use of `unsafe` constructs 
that can violate safety without any checking. It's my hope that our normal 
safety checks are  thorough and fire early enough that your subprocess would 
crash before wide-system compromise happens. In an "actor" or similar model, 
even if we decide we don't want to pay for unwinding to fully clean up after 
the crashed actor, that crash could still at least be noted by a coordinator 
actor, which in your server situation could handle the problem by not accepting 
any new connections and letting its existing connections finish before 
restarting the process, or in an iOS-like mobile situation could  trigger 
serialization of the current user state so that the process can be 
transparently killed and restarted. In either situation, perhaps we'd want to 
"taint" actors that use unsafe constructs so that their failure can't be 
recovered at all.

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

Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Adrian Zubarev via swift-evolution

Here are a few thoughts on how I imagine these existentials to look like.

// We now write the `where` clause all the way at the end.
// SE-0142 does follow that route as well.
// I think there is no need for a leading dot in existentials, similar to the 
where clause from SE-0142.

typealias MyConstrainedView = Any where AssociatedType == 
SomeType

// Shorthand form
typealias MyConstrainedView = UIView & MyProtocol where AssociatedType == 
SomeType

// If there is a clash of two associated types with the same name, which both 
comes from a different protocol, we should be explicit there and prefix them 
with `ProtocolName.`

typealias A = Any where P1.AssociatedType == SomeType, 
P2.AssociatedType == SomeOtherType
Overlapping classes that share some subtype relationship should provide a 
fix-it warning and merge.

// Warning
Any

// Fixed
Any

// Simpler
UIView & SomeProtocol

-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:46:20, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

Hi there,

>From my current perspective, my draft is way to0 outdated and ugly. :D And I 
>myself will be very busy in the next two month, so please don’t count on me 
>for now.

But I will follow the topic and write some feedback as good as I only can.

-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:41:11, Austin Zheng (austinzh...@gmail.com) schrieb:

I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

On Jan 17, 2017, at 11:48 PM, David Hart  wrote:

Austin? Do you want/have time to split out the Superclass + Protocol proposal? 
If not, I can do it. Let me know.
David.

On 18 Jan 2017, at 00:27, Douglas Gregor  wrote:

On Jan 10, 2017, at 10:21 PM, David Hart  wrote:

What do you think I should do then? Start an official proposal for Superclass + 
Protocol because that’s all we can afford to have for Swift 4 or bug Austin to 
resubmit his full proposal?

I think it makes sense to split out the more-Swift-4-critical Superclass + 
Protocol bit, because it affects the import of Objective-C APIs in a manner 
that breaks source code. Reading the tea leaves, I can’t imagine having time to 
implement the full generalized-extensions proposal in Swift 4.

- Doug

David.

On 11 Jan 2017, at 00:09, Douglas Gregor  wrote:

On Jan 8, 2017, at 8:21 AM, David Hart  wrote:

On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 wrote:

Sent from my iPhone

On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:

On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 wrote:

Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

- Doug

By this are you referring to generalized existentials?

Yes. I actually prefer the term "generalized existentials".

If so I’ll say this is such a constant pain point and perverts so many API 
designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In my 
completely non-authoritative personal opinion we shouldn’t ship Swift 4 without 
it :)

To be absolutely clear, I think this is an extremely important feature. It's 
also a significant undertaking in both design and implementation. 

Hasn't most of the design work already been done by Austin and all those 
participating back then? What is missing? How much of the original proposal is 
possible to implement in the Swift 4 (on top of Superclass + Protocol)? Just 
want some hints on how to drive this so we can get as much of generalized 
existentials for Swift 4.

Yes, that’s fair: the proposal is in excellent shape, and I (personally) agree 
with most (maybe all) of the design decisions in it.

- Doug

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

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Matthew Johnson via swift-evolution


> On Jan 18, 2017, at 11:00 AM, Joe Groff  wrote:
> 
>> 
>> On Jan 18, 2017, at 8:57 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jan 18, 2017, at 8:50 AM, Tony Allevato  wrote:
 
 Good point—I hadn't considered the distinction.
 
 Does that mean a future version of Swift might allow `let` in a protocol 
 to indicate a value that must be immutable after initialization, such that 
 a computed `var { get }` wouldn't satisfy it?
>>> 
>>> It's conceivable that even computed `let` properties could be supported, if 
>>> the getter implementation is a pure function of `self`.
>> 
>> How would that work when `self` is mutable?
> 
> The exact meaning of "pure" and "immutable" would have to be designed. To a 
> first approximation, you could say a pure method would only be able to read 
> immutable global or class data (which is itself `let` or `pure func`, not 
> anything that's potentially mutable) in addition to its own arguments.

Got it.  That makes sense.  Looking forward to the expanded pure / immutable 
model someday!

> 
> -Joe

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

Re: [swift-evolution] Testing enum cases with associated values

2017-01-18 Thread Pierre Monod-Broca via swift-evolution

The last time I was in this situation, I resolved it by having a shadow enum 
with the same cases but without any associated value.

I also created shadow enums for error enums. The shadow enum wouldn't have any 
associated value, and Int as RawValue, and I would also use it as an error code 
when converting to NSError.

But it's not really fun to maintain.

Pierre

> Le 18 janv. 2017 à 05:51, Andy Chou via swift-evolution 
>  a écrit :
> 
> I see your point about conformances. In my example, AuthenticationResponse 
> isn't a generic type, so the conformances spec won't apply.
> 
> I'll go out on a limb and say that 80%+ of the use cases for equality will be 
> to distinguish enum cases, not the associated values.
> 
> I do like your proposal though. In the thread talking about it someone 
> mentioned a 'derived' keyword to specify conformance and derivation 
> simultaneously. I like the idea of being able to say:
> 
>   enum AuthenticationResponse: derived Equatable { ... }
> 
> Still, even with derived conformance, it can still be very useful to be able 
> to test against specific enum cases when the associated values aren't 
> Equatable. Maybe this example would make it clearer:
> 
> ```
> enum OpaqueResponse {
>   case success(OpaqueResult)
>   case failure
> }
> ```
> 
> If OpaqueResult is from a library module and its implementation uses private 
> variables, it may not be easy to make it conform to Equatable. Yet, it would 
> be nice to be able to say:
> 
> ```
> let result: OpaqueResponse = request()
> if request == .failure  { ... }
> ```
> 
> A more realistic example comes from the world of Rx, where the original issue 
> I have came from:
> 
> ```
> let result: Observable = request()
> 
> result.filter { $0 == .failure } ...
> result.filter { $0 == .success } ...
> 
> // The best we can do today looks more like:
> result.filter { if case .failure = $0 { return true} else { return false } }
> result.filter { $0.isFailure }// but we have to define isFailure ourselves
> 
> // There's a similar issue with assertions
> if case .failure = result { assert(false) }
> assert({ if case .failure = result { return true } else { return false } }())
> ```
> 
> I agree it's less of an issue with test cases. The issue arises when we want 
> a Bool valued expression...
> 
> Andy
> 
>> On Jan 17, 2017, at 6:38 PM, Tony Allevato  wrote:
>> 
>> Conditional conformances doesn't solve enum equality though, because there 
>> likely won't be a way to utter "enum Foo : Equatable where > all associated value payloads are Equatable>" with the generics syntax 
>> that's available, and conformance alone wouldn't be able to derive the 
>> implementation. It'll require some work on the compiler's part to generate 
>> the right implementation—I mentioned a draft proposal I wrote a while back 
>> for auto-equality of enums and structs where all the components are 
>> equatable 
>>  in 
>> another thread, but as Robert mentioned, the missing piece is how users opt 
>> in/out of it.
>> 
>> If you just want to check the case of an enum in a test, what about this?
>> 
>> enum Foo {
>>   case bar
>>   case baz(Int)
>> }
>> let foo = Foo.baz(5)
>> guard case .baz = foo else { XCTFail("expected baz"); return }
>> 
>> The "return" being required isn't ideal because XCTFail doesn't return 
>> Never, but other than that it's not *horrible*. You can do whatever pattern 
>> matching you need to use or ignore associated values as part of your 
>> comparison.
>> 
>> 
>>> On Tue, Jan 17, 2017 at 5:59 PM Andy Chou via swift-evolution 
>>>  wrote:
>>> Yes, here's a reference to the conditional conformance proposal which was 
>>> accepted:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md
>>> 
>>> But as I mention in my post, there are cases it doesn't handle. 
>>> Specifically, when the associated types for an enum aren't equatable 
>>> themselves, it's still possible to define equality on the enum cases 
>>> without associated values.
>>> 
>>> Andy
>>> 
 On Jan 17, 2017, at 5:45 PM, Robert Widmann  
 wrote:
 
 Automatic “equatability” of aggregates that contain equatable members has 
 been discussed on this list quite a few times.  (I think I had a branch at 
 one point that was exploring this kind of deriving mechanism… It seems to 
 be lost to the sands of time).  Everybody seems to agree that it’s a 
 worthwhile feature, but there needs to be thought put into how it is 
 exposed to the end user.  e.g. Should we continue with silently 
 implementing these protocols if we can, or should there be some kind of 
 annotation to tell the compiler to only synthesize what the user wants?
 
> On Jan 17, 2017, at 7:15 PM, Andy Chou via

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Joe Groff via swift-evolution


> On Jan 18, 2017, at 8:57 AM, Matthew Johnson  wrote:
> 
> 
>> On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jan 18, 2017, at 8:50 AM, Tony Allevato  wrote:
>>> 
>>> Good point—I hadn't considered the distinction.
>>> 
>>> Does that mean a future version of Swift might allow `let` in a protocol to 
>>> indicate a value that must be immutable after initialization, such that a 
>>> computed `var { get }` wouldn't satisfy it?
>> 
>> It's conceivable that even computed `let` properties could be supported, if 
>> the getter implementation is a pure function of `self`.
> 
> How would that work when `self` is mutable?

The exact meaning of "pure" and "immutable" would have to be designed. To a 
first approximation, you could say a pure method would only be able to read 
immutable global or class data (which is itself `let` or `pure func`, not 
anything that's potentially mutable) in addition to its own arguments.

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

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Tony Allevato via swift-evolution

Good point—I hadn't considered the distinction.

Does that mean a future version of Swift might allow `let` in a protocol to
indicate a value that must be immutable after initialization, such that a
computed `var { get }` wouldn't satisfy it?

On Wed, Jan 18, 2017 at 8:48 AM Joe Groff  wrote:

>
> > On Jan 18, 2017, at 8:41 AM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Personally, I don't feel that the problem is big enough to warrant a
> breaking change here.
> >
> > `var` is the general property declaration keyword in Swift for
> read-write stored properties and read-only/read-write computed properties.
> The fact that you can use `let` in place of `var` under one specific
> circumstance (a read-only property backed by a stored variable) doesn't
> necessarily make the entire keyword meaningless, IMO. `let` is just a
> shortcut for a read-only stored property, and I think dropping it or moving
> `{ get set }` elsewhere would be more confusing, since it would be
> syntactically inconsistent with how the property is implemented. (Protocol
> members look the same as class/struct members with the body removed.)
> >
> > In general, I'm skeptical of ideas that just aim to protect new or bad
> developers from themselves, especially at the expense of consistency.
>
> `let` more strongly guarantees **immutability**, not just "read-only". var
> { get } indicates that the protocol's interface only lets you read, but
> provides no guarantee that the implementation can't change the value you
> get. The language doesn't have the ability to reason about immutability for
> anything other than stored properties yet, but we want to leave syntactic
> space for that possibility without muddying the strong guarantee of `let`.
> For that reason, protocols only support `var { get }` requirements today.
> `let` properties naturally model the requirement since you can read them;
> their interface is a superset of the protocol requirement.
>
> -Joe
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Will existentials ever conform to their protocols?

2017-01-18 Thread Joe Groff via swift-evolution

> On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> There is also a caveat with static members:
> 
> protocol P {
> static func foo()
> }
> 
> struct S : P {
> static func foo() { }
> }
> 
> func bar(x: T) {
> T.foo()
> }
> 
> let p = S() as P
> bar(p)  // P.foo() does not exist

Right, part of the language design problem here is that not every protocol type 
is naturally a model of its protocol. In addition to static members, if you 
have any "Self" arguments in your method requirements, you wouldn't naturally 
be able to use those requirements, which expect a specific type modeling the 
protocol, on the type-erased protocol type. For many protocols, there's an 
obvious generalization—to compare two Equatables, first check that they're the 
same type, then call the == on the values of that type; for factory protocols 
with initializer requirements, there may be a reasonable default implementation 
type to provide if you ask to construct a P(). We'd want a way to provide that 
self-conformance if it doesn't fall out naturally from generalizing the 
protocol requirements.

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

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Joe Groff via swift-evolution


> On Jan 18, 2017, at 8:50 AM, Tony Allevato  wrote:
> 
> Good point—I hadn't considered the distinction.
> 
> Does that mean a future version of Swift might allow `let` in a protocol to 
> indicate a value that must be immutable after initialization, such that a 
> computed `var { get }` wouldn't satisfy it?

It's conceivable that even computed `let` properties could be supported, if the 
getter implementation is a pure function of `self`.

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Francisco Javier Fernández Toro via swift-evolution

Thank you for your answer Joe,

you are right the equal(to:) wasn't a valid override, but even after using
the one you've proposed, the behavior is not the expected one


let a = Subclass(foo: 1, bar: 1)
let b = Subclass(foo: 1, bar: 2)

(a == b) != (a != b) // Prints true

let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
let y = SubclassWithDifferentOperator(foo: 1, bar: 2)

(x == y) != (x != y) // Prints false

As you can see above if a subclass does not implement the global function !=,
the equal operation seems to be broken.

---

Fran Fernandez

On Wed, Jan 18, 2017 at 5:44 PM, Joe Groff  wrote:

>
> > On Jan 18, 2017, at 2:59 AM, Francisco Javier Fernández Toro via
> swift-evolution  wrote:
> >
> > Hi,
> >
> > I've found that when you have a class hierarchy which implements
> Equatable, if you want to have the != operator working as expected, you
> need to override it, it's not enough with ==.
> >
> > If you don't define you own subclass != operator, Swift compiler will
> use the super class to resolve that operation.
> >
> > Is there any reason for that?
>
> The `equal(to:)` method inside `Subclass` is not a valid override of
> `Superclass` because its argument only accepts `Subclass` instances, but
> the parent method needs to work with all `Superclass` instances. If you
> write it as an override, it should work:
>
> class Subclass: Superclass {
> let bar: Int
> init(foo: Int, bar: Int) {
> self.bar = bar
> super.init(foo: foo)
> }
>
> override func equal(to: Superclass) -> Bool {
>   if let toSub = to as? Subclass {
> return bar == toSub.bar && super.equal(to: to)
>   }
>   return false
> }
> }
>
> We should probably raise an error, or at least a warning, instead of
> silently accepting your code as an overload. Would you be able to file a
> bug on bugs.swift.org about that?
>
> -Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Joe Groff via swift-evolution

> On Jan 18, 2017, at 8:41 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Personally, I don't feel that the problem is big enough to warrant a breaking 
> change here.
> 
> `var` is the general property declaration keyword in Swift for read-write 
> stored properties and read-only/read-write computed properties. The fact that 
> you can use `let` in place of `var` under one specific circumstance (a 
> read-only property backed by a stored variable) doesn't necessarily make the 
> entire keyword meaningless, IMO. `let` is just a shortcut for a read-only 
> stored property, and I think dropping it or moving `{ get set }` elsewhere 
> would be more confusing, since it would be syntactically inconsistent with 
> how the property is implemented. (Protocol members look the same as 
> class/struct members with the body removed.)
> 
> In general, I'm skeptical of ideas that just aim to protect new or bad 
> developers from themselves, especially at the expense of consistency.

`let` more strongly guarantees **immutability**, not just "read-only". var { 
get } indicates that the protocol's interface only lets you read, but provides 
no guarantee that the implementation can't change the value you get. The 
language doesn't have the ability to reason about immutability for anything 
other than stored properties yet, but we want to leave syntactic space for that 
possibility without muddying the strong guarantee of `let`. For that reason, 
protocols only support `var { get }` requirements today. `let` properties 
naturally model the requirement since you can read them; their interface is a 
superset of the protocol requirement.

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

Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Adrian Zubarev via swift-evolution

Hi there,

>From my current perspective, my draft is way to0 outdated and ugly. :D And I 
>myself will be very busy in the next two month, so please don’t count on me 
>for now.

But I will follow the topic and write some feedback as good as I only can.

-- 
Adrian Zubarev
Sent with Airmail

Am 18. Januar 2017 um 17:41:11, Austin Zheng (austinzh...@gmail.com) schrieb:

I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

On Jan 17, 2017, at 11:48 PM, David Hart  wrote:

Austin? Do you want/have time to split out the Superclass + Protocol proposal? 
If not, I can do it. Let me know.
David.

On 18 Jan 2017, at 00:27, Douglas Gregor  wrote:

On Jan 10, 2017, at 10:21 PM, David Hart  wrote:

What do you think I should do then? Start an official proposal for Superclass + 
Protocol because that’s all we can afford to have for Swift 4 or bug Austin to 
resubmit his full proposal?

I think it makes sense to split out the more-Swift-4-critical Superclass + 
Protocol bit, because it affects the import of Objective-C APIs in a manner 
that breaks source code. Reading the tea leaves, I can’t imagine having time to 
implement the full generalized-extensions proposal in Swift 4.

- Doug

David.

On 11 Jan 2017, at 00:09, Douglas Gregor  wrote:

On Jan 8, 2017, at 8:21 AM, David Hart  wrote:

On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
 wrote:

Sent from my iPhone

On Jan 6, 2017, at 11:04 PM, Russ Bishop  wrote:

On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 wrote:

Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

- Doug

By this are you referring to generalized existentials?

Yes. I actually prefer the term "generalized existentials".

If so I’ll say this is such a constant pain point and perverts so many API 
designs… not to mention vomiting AnyXYZ type-erased wrappers everywhere… In my 
completely non-authoritative personal opinion we shouldn’t ship Swift 4 without 
it :)

To be absolutely clear, I think this is an extremely important feature. It's 
also a significant undertaking in both design and implementation. 

Hasn't most of the design work already been done by Austin and all those 
participating back then? What is missing? How much of the original proposal is 
possible to implement in the Swift 4 (on top of Superclass + Protocol)? Just 
want some hints on how to drive this so we can get as much of generalized 
existentials for Swift 4.

Yes, that’s fair: the proposal is in excellent shape, and I (personally) agree 
with most (maybe all) of the design decisions in it.

- Doug

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Joe Groff via swift-evolution

> On Jan 18, 2017, at 2:59 AM, Francisco Javier Fernández Toro via 
> swift-evolution  wrote:
> 
> Hi,
> 
> I've found that when you have a class hierarchy which implements Equatable, 
> if you want to have the != operator working as expected, you need to override 
> it, it's not enough with ==. 
> 
> If you don't define you own subclass != operator, Swift compiler will use the 
> super class to resolve that operation.
> 
> Is there any reason for that?

The `equal(to:)` method inside `Subclass` is not a valid override of 
`Superclass` because its argument only accepts `Subclass` instances, but the 
parent method needs to work with all `Superclass` instances. If you write it as 
an override, it should work:

class Subclass: Superclass {
let bar: Int
init(foo: Int, bar: Int) {
self.bar = bar
super.init(foo: foo)
}

override func equal(to: Superclass) -> Bool {
  if let toSub = to as? Subclass {
return bar == toSub.bar && super.equal(to: to)
  }
  return false
}
}

We should probably raise an error, or at least a warning, instead of silently 
accepting your code as an overload. Would you be able to file a bug on 
bugs.swift.org about that?

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

Re: [swift-evolution] Enhanced Existentials

2017-01-18 Thread Austin Zheng via swift-evolution

I probably won't have time, unfortunately. I think Adrian Zubarev (cc'ed) had a 
draft for this proposal at some point, so you might want to work with him.

Austin

> On Jan 17, 2017, at 11:48 PM, David Hart  wrote:
> 
> Austin? Do you want/have time to split out the Superclass + Protocol 
> proposal? If not, I can do it. Let me know.
> David.
> 
>> On 18 Jan 2017, at 00:27, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jan 10, 2017, at 10:21 PM, David Hart >> > wrote:
>>> 
>>> What do you think I should do then? Start an official proposal for 
>>> Superclass + Protocol because that’s all we can afford to have for Swift 4 
>>> or bug Austin to resubmit his full proposal?
>> 
>> I think it makes sense to split out the more-Swift-4-critical Superclass + 
>> Protocol bit, because it affects the import of Objective-C APIs in a manner 
>> that breaks source code. Reading the tea leaves, I can’t imagine having time 
>> to implement the full generalized-extensions proposal in Swift 4.
>> 
>>  - Doug
>> 
>>> 
>>> David.
>>> 
 On 11 Jan 2017, at 00:09, Douglas Gregor > wrote:
 
 
> On Jan 8, 2017, at 8:21 AM, David Hart  > wrote:
> 
>> 
>> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jan 6, 2017, at 11:04 PM, Russ Bishop >> > wrote:
>>> 
>>> 
 On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
 
> 
> Would love to see this come forward into discussion.
 
 Yeah. I'm less sure about the other enhancements to existentials 
 fitting into Swift 4, e.g., the creation of existentials for protocols 
 with associated types. Although important, it's a big feature that 
 will take a bunch of design and implementation time, and I'm leery of 
 accepting something that we might not actually be able to achieve. 
 
 - Doug
>>> 
>>> By this are you referring to generalized existentials?
>> 
>> Yes. I actually prefer the term "generalized existentials".
>> 
>>> If so I’ll say this is such a constant pain point and perverts so many 
>>> API designs… not to mention vomiting AnyXYZ type-erased wrappers 
>>> everywhere… In my completely non-authoritative personal opinion we 
>>> shouldn’t ship Swift 4 without it :)
>> 
>> To be absolutely clear, I think this is an extremely important feature. 
>> It's also a significant undertaking in both design and implementation. 
> 
> Hasn't most of the design work already been done by Austin and all those 
> participating back then? What is missing? How much of the original 
> proposal is possible to implement in the Swift 4 (on top of Superclass + 
> Protocol)? Just want some hints on how to drive this so we can get as 
> much of generalized existentials for Swift 4.
 
 
 Yes, that’s fair: the proposal is in excellent shape, and I (personally) 
 agree with most (maybe all) of the design decisions in it.
 
- Doug
 
>>> 
>> 
> 

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

[swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

2017-01-18 Thread Francisco Javier Fernández Toro via swift-evolution

Hi,

I've found that when you have a class hierarchy which implements Equatable,
if you want to have the != operator working as expected, you need to
override it, it's not enough with ==.

If you don't define you own subclass != operator, Swift compiler will use
the super class to resolve that operation.

Is there any reason for that?

Check the following code (
https://gist.github.com/fjfdeztoro/a5097f1b24379e127674eb1df8c97d96):


class Superclass : Equatable {
let foo: Int

init(foo: Int) { self.foo = foo }

func equal(to: Superclass) -> Bool {
return foo == to.foo
}
}

func == (lhs: Superclass, rhs: Superclass) -> Bool {
return lhs.equal(to: rhs)
}

class Subclass: Superclass {
let bar: Int
init(foo: Int, bar: Int) {
self.bar = bar
super.init(foo: foo)
}

func equal(to: Subclass) -> Bool {
return bar == to.bar && super.equal(to: to)
}
}

func == (lhs: Subclass, rhs: Subclass) -> Bool {
return lhs.equal(to: rhs)
}

class SubclassWithDifferentOperator: Subclass {}

func != (lhs: SubclassWithDifferentOperator, rhs:
SubclassWithDifferentOperator) -> Bool {
return !lhs.equal(to: rhs)
}

let a = Subclass(foo: 1, bar: 1)
let b = Subclass(foo: 1, bar: 2)

(a == b) != (a != b) // Prints: False

let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
let y = SubclassWithDifferentOperator(foo: 1, bar: 2)

(x == y) != (x != y) // Prints: True

---

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

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Chris Eidhof via swift-evolution

I think the nice thing about reduce is that you can use it to implement
something in a single line, and directly return it. Making the first
parameter inout would require you to write `var result = ` and `return
result` (and `result` will be mutable after the call to `reduce`).
Typically, the initial value is some kind of empty value, so copying isn't
a problem. In my usage, making the first parameter inout would make the
code more verbose, decrease readability and not win too much.

I think that making initialValue an inout is a cool idea, but I don't think
it's something for this proposal. (I'm open for good arguments, though).

On Wed, Jan 18, 2017 at 1:48 PM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> the former gives a hint about what someFunction (and the for-loop) is
> doing.
>
> -g.
>
> > On 18 Jan 2017, at 2:32 PM, Jeremy Pereira via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Thought: if the idea is performance and not drop-in replacement, why
> force the user to incur two copies? If the initial value were inout, this
> function would be more unambiguous even without a new name, and at _worst_
> the user has to declare a variable with var, a worthwhile trade-off to save
> two copies.
> >
> > That’s what I thought also until just now, but then why wouldn’t you
> just use a for …  in loop?
> >
> > i.e. instead of
> >
> >var foo = 0
> >let bar: [SomeType] = ...
> >
> >bar.reduce(mutating: , someFunction)
> >
> > You would write
> >
> >var foo = 0
> >let bar: [SomeType] = …
> >
> >for e in bar {
> >someFunction(, e)
> >}
> >
> > which is a bit more readable IMO
> > ___
> > 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
>

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

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Georgios Moschovitis via swift-evolution

the former gives a hint about what someFunction (and the for-loop) is doing.

-g.

> On 18 Jan 2017, at 2:32 PM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Thought: if the idea is performance and not drop-in replacement, why force 
>> the user to incur two copies? If the initial value were inout, this function 
>> would be more unambiguous even without a new name, and at _worst_ the user 
>> has to declare a variable with var, a worthwhile trade-off to save two 
>> copies.
> 
> That’s what I thought also until just now, but then why wouldn’t you just use 
> a for …  in loop?
> 
> i.e. instead of
> 
>var foo = 0
>let bar: [SomeType] = ...
> 
>bar.reduce(mutating: , someFunction) 
> 
> You would write
> 
>var foo = 0
>let bar: [SomeType] = …
> 
>for e in bar {
>someFunction(, e)
>}
> 
> which is a bit more readable IMO
> ___
> 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] Reduce with inout

2017-01-18 Thread Jeremy Pereira via swift-evolution


> On 18 Jan 2017, at 12:26, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Thought: if the idea is performance and not drop-in replacement, why force 
> the user to incur two copies? If the initial value were inout, this function 
> would be more unambiguous even without a new name, and at _worst_ the user 
> has to declare a variable with var, a worthwhile trade-off to save two copies.

That’s what I thought also until just now, but then why wouldn’t you just use a 
for …  in loop?

i.e. instead of

var foo = 0
let bar: [SomeType] = ...

bar.reduce(mutating: , someFunction) 

You would write

var foo = 0
let bar: [SomeType] = …

for e in bar {
someFunction(, e)
}

which is a bit more readable IMO
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Xiaodi Wu via swift-evolution

Thought: if the idea is performance and not drop-in replacement, why force
the user to incur two copies? If the initial value were inout, this
function would be more unambiguous even without a new name, and at _worst_
the user has to declare a variable with var, a worthwhile trade-off to save
two copies.

(Ack, Jeremy just beat me to it!)
On Wed, Jan 18, 2017 at 05:45 Chris Eidhof via swift-evolution <
swift-evolution@swift.org> wrote:

> I opened up a WIP PR on the SE repository (so many TLA's!).
> https://github.com/apple/swift-evolution/pull/587
>
> I think I'll wait a few days before removing `WIP` until the naming
> discussion either reaches consensus or settles down.
>
> So far, I would summarize the thread as: people are in favor, but there is
> disagreement on the naming. I suspect the core team will ultimately decide
> on the naming?
>
> On Wed, Jan 18, 2017 at 11:11 AM, Chris Eidhof  wrote:
>
> I don't think we should replace the current `reduce` with the `inout`
> version, also because the current reduce can be really useful as well (e.g.
> when the return type is an Int).
>
> One downside of having a different name is that it'll be harder to
> discover this version. If stressing the type-checker is the only problem,
> then maybe we should improve the type-checker, instead of placing that
> burden on every user of the language.
>
>
>
> On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While realizing that this name can cause confusion, I'd still prefer
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without
> mutation should retain its name.
>
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I suppose as a second-choice I’d go for accumulate(into: with:):
>
> [1, 2, 3].accumulate(into: 0, with: +=)
>
> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> --
> Chris Eidhof
>
>
>
>
> --
> Chris Eidhof
> ___
> 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] Reduce with inout

2017-01-18 Thread Jeremy Pereira via swift-evolution


> On 18 Jan 2017, at 02:17, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
> 
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is 
> incorrect since, as Charles pointed out to Dave, it's not `x` that's mutated 
> but rather a mutable copy of it, so it doesn't matter if `x` itself is 
> declared with `let` or `var`.

Why not also have that version?

var foo = 0
let bar: [SomeType] = ...

bar.reduce(mutating: , someFunction) 

// foo now contains the reduced bar


> 
> 
> ___
> 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] Reduce with inout

2017-01-18 Thread Chris Eidhof via swift-evolution

I opened up a WIP PR on the SE repository (so many TLA's!).
https://github.com/apple/swift-evolution/pull/587

I think I'll wait a few days before removing `WIP` until the naming
discussion either reaches consensus or settles down.

So far, I would summarize the thread as: people are in favor, but there is
disagreement on the naming. I suspect the core team will ultimately decide
on the naming?

On Wed, Jan 18, 2017 at 11:11 AM, Chris Eidhof  wrote:

> I don't think we should replace the current `reduce` with the `inout`
> version, also because the current reduce can be really useful as well (e.g.
> when the return type is an Int).
>
> One downside of having a different name is that it'll be harder to
> discover this version. If stressing the type-checker is the only problem,
> then maybe we should improve the type-checker, instead of placing that
> burden on every user of the language.
>
>
>
> On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> While realizing that this name can cause confusion, I'd still prefer
>> `reduce(mutating:_:)`, because it looks like the only readable option to me.
>> Whatever name will be picked, I agree that traditional reduce without
>> mutation should retain its name.
>>
>> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>>
>>> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>>>
>>> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
>>> incorrect since, as Charles pointed out to Dave, it's not `x` that's
>>> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
>>> is declared with `let` or `var`.
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> I suppose as a second-choice I’d go for accumulate(into: with:):
>>
>> [1, 2, 3].accumulate(into: 0, with: +=)
>>
>> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>>
>> - Karl
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Chris Eidhof
>



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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread Jeremy Pereira via swift-evolution

> On 17 Jan 2017, at 11:53, Alex Blewitt  wrote:
> 
>> 
>> On 17 Jan 2017, at 11:46, Jeremy Pereira  
>> wrote:
>> 
>>> 
>>> On 17 Jan 2017, at 11:28, Alex Blewitt  wrote:
>>> 
>>> 
 On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution 
  wrote:

> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution 
>  wrote:
> 
> I really hate to bring Java up, but I really do think it got at least one 
> thing right with its error system, namely that one subset of error 
> (namely `RuntimeException`), wouldn't be enforced by the compiler, but 
> could optionally be caught.

 I don’t entirely agree for two reasons:

 1. If a runtime error is thrown and caught, there is no way to guarantee 
 the logical consistency of the state of the running process because who 
 knows which stack frames were unwound without cleaning up properly. There 
 is no way to safely catch a run time exception and recover.
>>> 
>>> From a Java perspective, clearly that's not true. 
>> 
>> It absolutely is true. 
>> 
>> int someMethod()
>> {
>> aquireSomeLock();
>> doSomethingThatIsNotDeclaredToThrowAnException();
>> releaseSomeLock();
>> }
> 
> The general way to perform locking in Java is to use a synchronised block 
> around a particular resource, and those are cleaned up by the Java VM when 
> unwinding the stack, or to use a finally block to do the same. You can 
> certainly write incorrect code in Java; the correct code would look like:
> 
> int someMethod() {
>   try {
> acquireSomeLock();
> doSomethingThatIsNotDeclaredToThrowAnException();
>   } finally {
> releaseSomeLock();
>   }
> }
> 

Yes, which is why catching runtime errors is a problem. You need all the 
boilerplate of  try { … } finally { … } every time you have a resource like 
this just in case any of the methods you call while you have the resource throw 
a run time exception. If you have more than one such resource in a scope you 
start to need pyramids of try … finally structures. It gets quite onerous, so 
people don’t do it or they don’t do it properly.

And also people often make mistakes when writing their try finally blocks as 
you did. The correct way to code my example is

int someMethod() 
{
  acquireSomeLock();
  try 
  {
doSomethingThatIsNotDeclaredToThrowAnException();
  } 
  finally 
  {
releaseSomeLock();
  }
}

(you don’t want to call releaseSomeLock() if the exception is throw while 
acquiring it - assuming acquireSomeLock() was properly designed).

> It's more likely to be written as:
> 
> int someMethod() {
>   synchronized(lockObject) {
> doSomethingThatIsNotDeclaredToThrowAnException();
>   }
> }

Here you are assuming all resources that need to be acquired/released can be 
replaced with Java locks. You are also assuming that all cases where logical 
consistency is needed are locks or memory. What if you have a sequence of 
operations that must appear to be performed atomically in order to keep the 
model consistent?

synchronized int someMethodThatNeedsToBeAtomic()
{
doOperationOne();
doOperationTwo();
doOperationThree();
doOperationFour();
}

If I want to be able to recover from RunTimeExceptions, I need to catch them 
here and roll back any work already done. That means multiple try catch blocks 
or some other logic so I know how much I need to roll back. With Swift, if a 
method is not declared to throw, you know you don’t need write code to handle 
errors. The same applies to Java but only if you do not try to recover from 
RuntimeExceptions.

> 
>> 
> 
> True; file descriptors are one such example. Again, the language has the 
> ability to recover instead of blowing up when that occurs:
> 
> try(FileInputStream in = new FileInputStream("theFIle")) {
>   // do stuff with input stream
> } // input stream is closed

This is a recent feature with Java and it’s certainly a step in the right 
direction.

>> 
>> No it’s not a poor example. I’ve seen it happen with real software in real 
>> production scenarios.
> 
> And if we're talking anecdata, I've seen large production systems where a 
> particular message has been unable to be processed due to some incorrect data 
> formatting (in some cases, an invalid UTF-8 sequence of bytes being passed in 
> and treated as UTF-8). The general way is not to crash and return that and 
> let it be processed a subsequent time, but ignored, put into a manual resolve 
> queued, and keep going.

No, the correct way to handle errors in input data is validate it and/or throw 
a checked exception which can be handled and recovered safely in Java. In your 
case, you don’t want an exception in the log, you want a message saying what 
went wrong, where and how to fix it

> 
>> 
>>> 
 I like Swift’s error handling because programming

Re: [swift-evolution] Removing var keyword in protocol property reqirements

2017-01-18 Thread Jeremy Pereira via swift-evolution


> On 18 Jan 2017, at 05:38, Vinnie Hesener via swift-evolution 
>  wrote:
> 
> The var keyword in protocol property requirements is misleading. 
> 
> From the docs:
> *If a protocol requires a property to be gettable and settable, that property 
> requirement cannot be fulfilled by a constant stored property or a read-only 
> computed property. If the protocol only requires a property to be gettable, 
> the requirement can be satisfied by any kind of property, and it is valid for 
> the property to be also settable if this is useful for your own code.*
> 
> I feel this is slightly confusing. To conform, I can use let for { get }. I 
> can't use var for { get set } if it's computed. This leads me to believe that 
> the keyword var has no actual instructional meaning here. It seems misplaced 
> to represent "property".
> 
> I think it should be something else, or maybe removed entirely? Isn't { get 
> set } enough to describe what this protocol needs? Maybe we can put the { get 
> set } in front of the property name?

-1 from me

I’d rather keep the syntax for protocols as similar as possible to the syntax 
for classes and structs. 

There might be an argument for `let` in a protocol as well as `var` although 
that would really be allowing protocol designers to dictate implementation 
details to designers of structs and classes that implement the protocol.


> 
> I can think of a couple other small benefits of this, but I don't know if it 
> will distract from the main discussion. One of them being that it may 
> discourage using lets for those new to the language, as most people will just 
> lazily copy/paste the declaration. 
> ___
> 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] Reduce with inout

2017-01-18 Thread Chris Eidhof via swift-evolution

I don't think we should replace the current `reduce` with the `inout`
version, also because the current reduce can be really useful as well (e.g.
when the return type is an Int).

One downside of having a different name is that it'll be harder to discover
this version. If stressing the type-checker is the only problem, then maybe
we should improve the type-checker, instead of placing that burden on every
user of the language.



On Wed, Jan 18, 2017 at 9:36 AM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> While realizing that this name can cause confusion, I'd still prefer
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without
> mutation should retain its name.
>
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
>> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>>
>> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
>> incorrect since, as Charles pointed out to Dave, it's not `x` that's
>> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
>> is declared with `let` or `var`.
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> I suppose as a second-choice I’d go for accumulate(into: with:):
>
> [1, 2, 3].accumulate(into: 0, with: +=)
>
> even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.
>
> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-18 Thread Rien via swift-evolution


> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 
>> On Jan 17, 2017, at 7:13 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Tue Jan 17 2017, Jonathan Hull  wrote:
>> 
>>> Bringing it back towards the initial post, what if there was a
>>> separation from true needs-to-take-down-the-entire-system trapping and
>>> things like out-of-bounds and overflow errors which could stop at
>>> thread/actor bounds (or in some cases even be recovered)?
>>> 
>>> The latter were the ones I was targeting with my proposal.  They live
>>> in this grey area, because honestly, they should be throwing errors if
>>> not for the performance overhead and usability issues.  
>> 
>> I fundamentally disagree with that statement.  There is value in
>> declaring certain program behaviors illegal, and in general for things
>> like out-of-bounds access and overflow no sensible recovery (where
>> “recovery” means something that would allow the program to continue
>> reliably) is possible.  
> 
> I think we do fundamentally disagree.  I know I come from a very different 
> background (Human-Computer Interaction & Human Factors) than most people 
> here, and I am kind of the odd man out, but I have never understood this 
> viewpoint for anything but the most severe cases where the system itself is 
> in danger of being compromised (certainly not for an index out of bounds).  
> In my mind “fail fast” is great for iterating in development builds, but once 
> you are deploying, the user’s needs should come ahead of the programmer’s.
> 
> Shouldn’t a system be as robust as possible

Yes

> and try to minimize the fallout from any failure point?

That is in direct conflict with the robustness
Once an error is detected that is not handled by the immediate code, it must be 
assumed that a worst-case scenario happened. And further damage to the user can 
only be prevent by bringing down the app. Even if that means losing all work in 
progress.

A compromised system must be prevent from accessing any resources. Once a 
system is compromised the risk to the user is *much* higher than simply loosing 
work in progress. He might loose his job, career, etc.

Rien.


>  I don’t consider crashing and losing all of the user’s data minimal.  It 
> used to be that something like dividing by zero took down the entire machine. 
>  Now we mimic that by crashing the application, even though it isn’t strictly 
> necessary.  Wouldn’t it be even better if we only took down the current 
> operation, notified the user about what happened and continue on?
> 
> Swift does a great job of using forcing functions (like optionals) to make 
> some errors impossible, and this is literally the opposite of that. This 
> requires the programmer to remember to add a check that the number is within 
> certain bounds, but there is no reminder for them to do that.  The failure is 
> silent (i.e. there isn’t a ‘!’ or ’try' to mark that it is a possibility), at 
> runtime, under certain conditions and not others.  It is a recipe for bugs 
> which cause a crash for the user.
> 
> If we wanted fool-proof arrays, then the subscript would return an optional, 
> forcing the programmer to think about and deal with the possibility of 
> out-of-bounds failure (that is how we handle dictionary lookups after all).  
> If I remember correctly, we don’t do that because of performance. Instead we 
> ask the programmer to remember to check against the array count first, just 
> like we used to ask the programmer to remember to check for nil pointers in 
> C++.
> 
> The idea that a programmer can or should be perfect is a lovely fantasy…  My 
> CS teachers always talked about how it would encourage bad programming if 
> there wasn’t punishment for making these types of mistakes.
> 
> I don’t see the value in punishing the user for the programmer’s mistake, and 
> I have rarely seen a case where sensible recovery wouldn’t be possible (given 
> Swift’s error handling).  In most real-world applications, you would just end 
> up cancelling whatever operation was happening, reverting to the state before 
> it, and notifying the user of the problem.  The programming languages which 
> get into trouble are the ones which treat everything as valid, so they just 
> keep barreling on, overwriting data or something like that.  We don’t have 
> that problem though, since we have sensible error handling that can be used 
> to fail an operation and get things back to a previous state (or better yet, 
> avoiding overwriting the state until after the operation has succeeded).  We 
> should aim for robustness, and crashing isn’t robust.
> 
> Please note: I am not saying we allow memory access out of bounds. We are 
> still triggering an error state when these things happen (either returning 
> nil or throwing an error), we’re just not crashing the entire program because 
> of it.
> 
> 
> 
>> 
>>> My solution was to give the compiler a way to

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

2017-01-18 Thread Slava Pestov via swift-evolution

I left some review comments here:

https://github.com/apple/swift-evolution/commit/ff654e4

Slava

> On Jan 18, 2017, at 12:17 AM, Karl Wagner  wrote:
> 
> 
>> On 18 Jan 2017, at 01:07, Douglas Gregor > > wrote:
>> 
>> 
>>> On Nov 5, 2016, at 2:44 AM, Karl via swift-evolution 
>>> > wrote:
>>> 

 On 2 Nov 2016, at 20:54, Slava Pestov > wrote:

> 
> On Nov 2, 2016, at 8:32 AM, Paul Cantrell  > wrote:
> 
> 
>> On Oct 24, 2016, at 4:43 PM, Slava Pestov > > wrote:
>> 
>> 
>>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell >> > wrote:
>>> 
>>> 
 On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution 
 > wrote:

 However protocols nested inside types and types nested inside 
 protocols is still not supported, because protocols introduce a 
 separate series of issues involving associated types and the ’Self’ 
 type.

 The hard part of getting nested generics right is what to do if a 
 nested type ‘captures’ generic parameters of the outer type. For 
 non-protocol types, the behavior here is pretty straightforward.

 If we allow protocols to be nested inside other types, we have to 
 decide what to do if the protocol ‘closes over’ generic parameters of 
 the outer type. For example,

 struct A {
 protocol P {
 func requirement() -> T
 }
 }

 Presumably A.P and A.P are distinct types, and A.P has a 
 hidden associated type corresponding to the type parameter ’T’?

 The other case is problematic too — the nested type might refer to an 
 associated type of the outer protocol:

 protocol P {
 associatedtype A

 struct T {
 var value: A
 }
 }

 Now writing P.T does not make sense, for the same reason that we 
 cannot form an existential of type P.A. We could prohibit references 
 to outer associated types of this form, or we could figure out some 
 way to give it a meaning. If C is a concrete type conforming to P, 
 then certainly C.T makes sense, for instance. Internally, the nested 
 type A.T could have a hidden ‘Self’ generic type parameter, so that 
 writing C.T is really the same as P.T.

 Protocols nested inside protocols also have the same issue.
>>> 
>>> FWIW, in almost all the situations where I’ve wanted to nest types 
>>> inside protocols and generic types, it’s only as a namespacing 
>>> convenience. Most often, it’s an enum type that’s used only by a single 
>>> method, and having it at the top of the module namespace adds clutter.
>>> 
>>> Here’s a real life example pared down. I wish I could do this:
>>> 
>>> public struct ResponseContentTransformer>> OutputContentType>: ResponseTransformer {
>>> 
>>>   public init(onInputTypeMismatch mismatchAction: 
>>> InputTypeMismatchAction = .error) {
>>> ...
>>>   }
>>> 
>>>   public enum InputTypeMismatchAction {  // Does not depend on generic 
>>> types above
>>> case error
>>> case skip
>>> case skipIfOutputTypeMatches
>>>   }
>>> 
>>> }
>>> 
>>> InputTypeMismatchAction is tightly associated with 
>>> ResponseContentTransformer, and is confusing as a top-level type.
>>> 
>>> What do you think about providing a “no captures” modifier for nested 
>>> types — like static inner classes in Java? Then Swift could provide the 
>>> namespace nesting I wish for this without having to resolve the 
>>> trickier type capture questions yet.
>>> 
>>> Alternatively, what if (1) outer types aren’t capture unless they’re 
>>> referenced, and (2) nesting is only illegal if there’s a capture? Then 
>>> my code above would compile, as would this:
>>> 
>>> public struct S {
>>>   public enum Foo {
>>> case yin
>>> case yang
>>>   }
>>> }
>>> 
>>> …but this wouldn’t:
>>> 
>>> public struct S {
>>>   public enum Foo {
>>> case yin(thing: T)  // capture of T illegal (for now)
>>> case yang
>>>   }
>>> }
>>> 
>>> Either of these approaches would allow hygienic namespacing now while 
>>> leaving the door open to outer type capture in the future.
>> 
>> Yeah, this makes sense for a first cut at this

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Karl Wagner via swift-evolution


> On 18 Jan 2017, at 09:00, Anton Zhilin via swift-evolution 
>  wrote:
> 
> While realizing that this name can cause confusion, I'd still prefer 
> `reduce(mutating:_:)`, because it looks like the only readable option to me.
> Whatever name will be picked, I agree that traditional reduce without 
> mutation should retain its name.
> 
> 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution 
> >:
> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
> 
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is 
> incorrect since, as Charles pointed out to Dave, it's not `x` that's mutated 
> but rather a mutable copy of it, so it doesn't matter if `x` itself is 
> declared with `let` or `var`. 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I suppose as a second-choice I’d go for accumulate(into: with:):

[1, 2, 3].accumulate(into: 0, with: +=) 

even [1, 2, 3].accumulate(into: 0, with: -=) doesn’t look so bad IMO.

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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

2017-01-18 Thread Karl Wagner via swift-evolution


> On 18 Jan 2017, at 01:07, Douglas Gregor  wrote:
> 
> 
>> On Nov 5, 2016, at 2:44 AM, Karl via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On 2 Nov 2016, at 20:54, Slava Pestov >> > wrote:
>>> 
 
 On Nov 2, 2016, at 8:32 AM, Paul Cantrell > wrote:
 
 
> On Oct 24, 2016, at 4:43 PM, Slava Pestov  > wrote:
> 
> 
>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell > > wrote:
>> 
>> 
>>> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution 
>>> > wrote:
>>> 
>>> However protocols nested inside types and types nested inside protocols 
>>> is still not supported, because protocols introduce a separate series 
>>> of issues involving associated types and the ’Self’ type.
>>> 
>>> The hard part of getting nested generics right is what to do if a 
>>> nested type ‘captures’ generic parameters of the outer type. For 
>>> non-protocol types, the behavior here is pretty straightforward.
>>> 
>>> If we allow protocols to be nested inside other types, we have to 
>>> decide what to do if the protocol ‘closes over’ generic parameters of 
>>> the outer type. For example,
>>> 
>>> struct A {
>>> protocol P {
>>> func requirement() -> T
>>> }
>>> }
>>> 
>>> Presumably A.P and A.P are distinct types, and A.P has a 
>>> hidden associated type corresponding to the type parameter ’T’?
>>> 
>>> The other case is problematic too — the nested type might refer to an 
>>> associated type of the outer protocol:
>>> 
>>> protocol P {
>>> associatedtype A
>>> 
>>> struct T {
>>> var value: A
>>> }
>>> }
>>> 
>>> Now writing P.T does not make sense, for the same reason that we cannot 
>>> form an existential of type P.A. We could prohibit references to outer 
>>> associated types of this form, or we could figure out some way to give 
>>> it a meaning. If C is a concrete type conforming to P, then certainly 
>>> C.T makes sense, for instance. Internally, the nested type A.T could 
>>> have a hidden ‘Self’ generic type parameter, so that writing C.T is 
>>> really the same as P.T.
>>> 
>>> Protocols nested inside protocols also have the same issue.
>> 
>> FWIW, in almost all the situations where I’ve wanted to nest types 
>> inside protocols and generic types, it’s only as a namespacing 
>> convenience. Most often, it’s an enum type that’s used only by a single 
>> method, and having it at the top of the module namespace adds clutter.
>> 
>> Here’s a real life example pared down. I wish I could do this:
>> 
>> public struct ResponseContentTransformer> OutputContentType>: ResponseTransformer {
>> 
>>   public init(onInputTypeMismatch mismatchAction: 
>> InputTypeMismatchAction = .error) {
>> ...
>>   }
>> 
>>   public enum InputTypeMismatchAction {  // Does not depend on generic 
>> types above
>> case error
>> case skip
>> case skipIfOutputTypeMatches
>>   }
>> 
>> }
>> 
>> InputTypeMismatchAction is tightly associated with 
>> ResponseContentTransformer, and is confusing as a top-level type.
>> 
>> What do you think about providing a “no captures” modifier for nested 
>> types — like static inner classes in Java? Then Swift could provide the 
>> namespace nesting I wish for this without having to resolve the trickier 
>> type capture questions yet.
>> 
>> Alternatively, what if (1) outer types aren’t capture unless they’re 
>> referenced, and (2) nesting is only illegal if there’s a capture? Then 
>> my code above would compile, as would this:
>> 
>> public struct S {
>>   public enum Foo {
>> case yin
>> case yang
>>   }
>> }
>> 
>> …but this wouldn’t:
>> 
>> public struct S {
>>   public enum Foo {
>> case yin(thing: T)  // capture of T illegal (for now)
>> case yang
>>   }
>> }
>> 
>> Either of these approaches would allow hygienic namespacing now while 
>> leaving the door open to outer type capture in the future.
> 
> Yeah, this makes sense for a first cut at this feature.
> 
> Slava
 
 Should I take a crack at writing up a proposal for this? Now? After ABI 
 work is done? (Probably the latter “OK if no captures” approach?) Eager to 
 help; don’t want to be in the way.
>>> 
>>> Just speaking for myself and not the whole team — I think you can submit 
>>> the proposal at any

Re: [swift-evolution] Testing enum cases with associated values

2017-01-18 Thread Anton Zhilin via swift-evolution

AFAICS, Andy needs not default implementations of Equatable, but
cases-as-optional-properties—this topic has also been discussed on the list.

enum Result {
case success(Int)
case failure(String)
}

let r: Result = foo()

let x: Int? = r.success
let y: String? = r.failure

assert(r.success == Optional(42))
assert(r.failure == nil)


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

Re: [swift-evolution] Will existentials ever conform to their protocols?

2017-01-18 Thread Slava Pestov via swift-evolution

Yes, there’s already logic to detect and diagnose this case in fact (@objc 
protocols are self-conforming, except when they contain static members or 
initializers).

Slava

> On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> There is also a caveat with static members:
> 
> protocol P {
> static func foo()
> }
> 
> struct S : P {
> static func foo() { }
> }
> 
> func bar(x: T) {
> T.foo()
> }
> 
> let p = S() as P
> bar(p)  // P.foo() does not exist
> ___
> 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] Will existentials ever conform to their protocols?

2017-01-18 Thread Anton Zhilin via swift-evolution

There is also a caveat with static members:

protocol P {
static func foo()
}

struct S : P {
static func foo() { }
}

func bar(x: T) {
T.foo()
}

let p = S() as P
bar(p)  // P.foo() does not exist


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

Re: [swift-evolution] Reduce with inout

2017-01-18 Thread Anton Zhilin via swift-evolution

While realizing that this name can cause confusion, I'd still prefer
`reduce(mutating:_:)`, because it looks like the only readable option to me.
Whatever name will be picked, I agree that traditional reduce without
mutation should retain its name.

2017-01-18 5:17 GMT+03:00 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org>:

> A serious possibility would be: `reduce(mutableCopyOf: x) { ... }`.
>
> It's verbose, but the nicer-looking `reduce(mutating: x) { ... }` is
> incorrect since, as Charles pointed out to Dave, it's not `x` that's
> mutated but rather a mutable copy of it, so it doesn't matter if `x` itself
> is declared with `let` or `var`.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

54 matches

Mail list logo