Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

[Rien via swift-evolution]

> On 18 Feb 2017, at 04:26, John McCall via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0155: Normalize Enum Case Representation" begins now and 
> runs through next Friday, February 26th. The proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
>   Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
> 
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?

It simplifies the usage of swift, while also extending the expressive 
capabilities.

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

IMO everything that simplifies a language is well worth the effort.

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

Yes.

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

No

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

Quick reading.

> 

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl

> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> John McCall
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

[Xiaodi Wu via swift-evolution]

On Sat, Feb 18, 2017 at 1:07 AM, David Waite 
wrote:

>
> > On Feb 17, 2017, at 10:53 PM, Xiaodi Wu  wrote:
> >
> > This draft proposes something that's been discussed on this list several
> times over the past few years, but now with a different spelling. However,
> previous objections never centered around the spelling.
> >
> > As discussed in previous threads on this topic, any such required
> keyword breaks retroactive conformance. That is, if I want to conform
> someone else's type to my protocol, I must edit that person's code if your
> idea is accepted.
>
> I believe this proposal is different in that it only requires
> specification for clarity not for behavioral changes, and only requires the
> keyword to be specified for protocols known at the site of method/property
> declaration.
>

If indeed you frame your proposal in this way, a best effort to add clarity
of intention, my feedback is that there are ways to gain the same (or at
least, very similar) benefits without being source-breaking, and indeed
without introducing new keywords at all.

For example:
- Doc comments are parsed. We already have `- Parameter` in doc comments,
which improved tooling could double-check to ensure that the stuff we put
there matches the stuff in the function signature (hmm, that'd be a nice
additive proposal, right?).
- The same tool could be augmented to recognize a spelling such as `-
RequiredBy:`, and you could list the specific protocols that require the
method. Then, you would be warned at compiled time if your method is in
fact not required by a protocol. This design has the side benefit of
telling the reader of your code exactly what protocols require that method,
not just that it's required by some protocol.

>
> > In so doing, this idea rejects an important (essential, IMO) mental
> model of what protocol conformance entails. Specifically, I conform a type
> T to a protocol P when I discover, having already implemented T, that it
> fulfills the semantic and syntactic requirements of P. Unlike subclassing,
> I'm not setting out with the intention of making a type T that conforms to
> P; rather, I discover this fact to my great delight after implementation of
> T. The analogy to subclassing is therefore inaccurate. Notionally, one
> always inherits from a superclass first, then overrides.
> >
> > This is no mere theoretical notion. It is a Swift idiom to state
> conformance to protocols in an extension. Sometimes, the type will already
> implement some but not all of the protocol's requirements outside that
> extension because it is essential to the raison d'être of the type, and
> only the balance of the requirements would then be implemented in the
> extension that states conformance. It would be exceedingly unfortunate to
> forbid this pattern, which is both elegant and expressive, but OTOH it
> would be strange to have a method declare that it fulfills a requirement of
> a protocol to which, lexically, it had not yet been conformed.
>
> The declaration is only required on types for protocols which the type is
> known to implement at the file level. If some other code (even within the
> same module) extends a type to support a protocol, there is no requirement
> that previous methods had been documented as fulfilling that new protocol.
>
> In this sense, not every method which is mapped into a protocol may be
> marked as fulfilling a protocol, but the purpose isn’t to solve every
> corner case. If that were indeed the purpose, I could propose something
> much wordier where the extension has to declare that intent to expose
> existing methods as part of protocol conformance.
>
> > Lastly, it makes a very common task, that of conforming to a protocol,
> syntactically heavy. This is exacerbated when you consider that the scheme
> outlined here has the greatest benefit only when conformance to one
> protocol is concerned. When conforming to more than one protocol, a similar
> level of compiler help can only be obtained if you allow annotations as to
> which protocol's requirement is being fulfilled. To implement this
> additional syntax would be ludicrously heavy, but to ignore the issue would
> be failing to consider one major aspect of protocols: composability (as
> opposed to single inheritance). Again here, this is a critical difference
> from subclassing that makes adapting "override" (regardless of whether you
> choose a novel spelling) ineffectual.
>
> The purpose isn’t to map methods to protocols, but to clarify that a
> method exists to meet the requirements of a protocol. Without this, a
> simple typo (or redefinition of methods such as with the changes in Swift
> 3’s importer) causes what you thought was conforming to a protocol to
> either fail, or worse silently change behavior.


As I demonstrate above, there are other designs possible that do not
require source breakage, or even any new keywords, which recover
essentially all of the benefits 

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[David Waite via swift-evolution]

> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
>  
> 
> 
> What is your evaluation of the proposal?
Its an ugly problem. My preference would be to warn the developer to call copy 
manually for now, vs copy automatically. 

The reason I’m concerned about the automatic approach is that I do not know if 
property behaviors are something which may still appear in a future version of 
Swift. At that point, I would expect NSCopying to become a behavior, and not a 
special case for initializer code generation.

If property behaviors are not planned for any future version of swift, then I 
suppose I’m impartial to the solution.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
I think so; it won’t be clear to developers that initializers special-case 
property access, and silently going against their declared desired behavior is 
a bad idea.

> Does this proposal fit well with the feel and direction of Swift?
As stated above, I believe it depends on whether or not there is a future 
property behaviors spec that this would conflict with.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
In Ruby, the behavior is simpler - @foo will access the property value 
directly, while self.foo or some_reference.foo will use the ‘foo’ function. 
Dots are always used to invoke functions.

Objective C has a syntax for property access as well, in that you can refer to 
the synthesized property values directly via an underscore prefix. 

A syntax for direct property data access in swift would be a third way to solve 
the problem. In that case, it would be clearer to the developer what they 
needed to do.
 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A quick reading

-DW

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

Re: [swift-evolution] Dictionary Enhancements

[David Waite via swift-evolution]

> On Feb 16, 2017, at 5:26 PM, Ben Cohen via swift-evolution 
> > wrote:
> 
> Hi swift-evolution,
> 
> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
> a thread to discuss improvements to the Dictionary type.
> 
> Here is a list of commonly requested changes/enhancements to Dictionary, all 
> of which would probably be appropriate to put together into a single 
> evolution proposal:
> 

> Add a defaulting subscript get (e.g. counts[key, default: 0] += 1 or 
> grouped(key, default:[]].append(value)).
Interesting, most of my scenarios aren’t one line subscript mutations like 
this, so I have been happy with counts[key] ?? 0, grouped(key) ?? [], etc.

> Add capacity property and reserveCapacity() method.
would CoW copies also have the same reserved capacity? One way I could 
hypothetically copy around dictionaries that are using significantly more 
memory than I suspected, the other way algorithms would be quite confusing as 
an assignment to a variable might cause the capacity to revert.
 
In terms of additional features, I have needed to group by value before, e.g. 
turn from K->V to V -> [K], which isn’t a simple reduce statement.

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

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[David Hart via swift-evolution]

>> What is your evaluation of the proposal?

For the same reasons as Xiaodi, this proposal could be potentially misleading 
if it introduces custom compiler magic, warning or errors that was not 
replicated for future property behaviours. 

But at the same time, it's very easy for even a seasoned developer to always 
remember to do the right thing in initializers. Swift's safety goals should 
technically avoid such simple mistakes from being made.

So I'm torn, with a slight preference for accepting the proposal with the 
warning solution.

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

It's a safety concern that can avoid bugs in our code so I'd say it's 
significant enough.

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

Yes.

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

No.

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

Quick reading.

On 18 Feb 2017, at 02:05, Xiaodi Wu via swift-evolution 
 wrote:

>> What is your evaluation of the proposal?
> This document seems to propose two contradictory alternative solutions; I 
> assume the goal is that the core team will choose one of two. I'm not sure 
> that either is an improvement over the status quo, for reasons I outline 
> below.
>  
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> I agree that the current situation is problematic because of inconsistency, 
> but I think both proposed solutions are more problematic because of more 
> inconsistency.
>  
>> Does this proposal fit well with the feel and direction of Swift?
> On the one hand, I can agree that `@NSCopying` not being respected in 
> `init()` can be confusing. However, as was pointed out during the initial 
> pitch, this is consistent with other behaviors. For example, `didSet` is not 
> called from `init()` either, and there are good reasons for this. If the 
> proposal for custom behaviors were to come back into consideration, I would 
> assume that none of those behaviors could be triggered from `init()` either.
> 
> A person who is new to Swift would continue to be confused if `@NSCopying` 
> had magic but `didSet` and other behaviors did not. A person who has studied 
> Swift and internalized the reasoning behind this initially tricky situation 
> might rightly expect that _all_ behaviors, including `@NSCopying`, are 
> ignored during `init`.
> 
> The proposal seems to prioritize new users migrating from Obj-C, who are 
> unfamiliar with Swift idioms, over Swift users who are right to expect some 
> internal consistency in the language. While supporting both groups is 
> important, I'm not sure it's appropriate to increase inconsistency within 
> Swift itself to help with migration from Obj-C.
>  
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> N/A.
>  
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> A quick reading.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

[David Waite via swift-evolution]

> On Feb 17, 2017, at 10:53 PM, Xiaodi Wu  wrote:
> 
> This draft proposes something that's been discussed on this list several 
> times over the past few years, but now with a different spelling. However, 
> previous objections never centered around the spelling.
> 
> As discussed in previous threads on this topic, any such required keyword 
> breaks retroactive conformance. That is, if I want to conform someone else's 
> type to my protocol, I must edit that person's code if your idea is accepted.

I believe this proposal is different in that it only requires specification for 
clarity not for behavioral changes, and only requires the keyword to be 
specified for protocols known at the site of method/property declaration.
> 
> In so doing, this idea rejects an important (essential, IMO) mental model of 
> what protocol conformance entails. Specifically, I conform a type T to a 
> protocol P when I discover, having already implemented T, that it fulfills 
> the semantic and syntactic requirements of P. Unlike subclassing, I'm not 
> setting out with the intention of making a type T that conforms to P; rather, 
> I discover this fact to my great delight after implementation of T. The 
> analogy to subclassing is therefore inaccurate. Notionally, one always 
> inherits from a superclass first, then overrides.
> 
> This is no mere theoretical notion. It is a Swift idiom to state conformance 
> to protocols in an extension. Sometimes, the type will already implement some 
> but not all of the protocol's requirements outside that extension because it 
> is essential to the raison d'être of the type, and only the balance of the 
> requirements would then be implemented in the extension that states 
> conformance. It would be exceedingly unfortunate to forbid this pattern, 
> which is both elegant and expressive, but OTOH it would be strange to have a 
> method declare that it fulfills a requirement of a protocol to which, 
> lexically, it had not yet been conformed.

The declaration is only required on types for protocols which the type is known 
to implement at the file level. If some other code (even within the same 
module) extends a type to support a protocol, there is no requirement that 
previous methods had been documented as fulfilling that new protocol.

In this sense, not every method which is mapped into a protocol may be marked 
as fulfilling a protocol, but the purpose isn’t to solve every corner case. If 
that were indeed the purpose, I could propose something much wordier where the 
extension has to declare that intent to expose existing methods as part of 
protocol conformance.

> Lastly, it makes a very common task, that of conforming to a protocol, 
> syntactically heavy. This is exacerbated when you consider that the scheme 
> outlined here has the greatest benefit only when conformance to one protocol 
> is concerned. When conforming to more than one protocol, a similar level of 
> compiler help can only be obtained if you allow annotations as to which 
> protocol's requirement is being fulfilled. To implement this additional 
> syntax would be ludicrously heavy, but to ignore the issue would be failing 
> to consider one major aspect of protocols: composability (as opposed to 
> single inheritance). Again here, this is a critical difference from 
> subclassing that makes adapting "override" (regardless of whether you choose 
> a novel spelling) ineffectual.

The purpose isn’t to map methods to protocols, but to clarify that a method 
exists to meet the requirements of a protocol. Without this, a simple typo (or 
redefinition of methods such as with the changes in Swift 3’s importer) causes 
what you thought was conforming to a protocol to either fail, or worse silently 
change behavior.

> Previous discussions on this topic have agreed that the developer experience 
> of conforming a type to a protocol can be greatly improved, but the consensus 
> has been that requiring a keyword to indicate protocol requirements is not 
> the way to go about it. I too would love to see progress made on this issue, 
> but having been previously an advocate for a solution similar to yours, the 
> views of some very wise people have changed my thinking.

There are often cases for the compiler to guess a developer’s intent to 
simplify syntax, but in this case I believe people are being bit by the 
compiler guessing incorrectly. If protocols didn’t make implementation of its 
requirements optional (via optional methods in objective-c, and protocol 
extensions in Swift) then there wouldn’t be a need to annotate methods to 
clarify intent. Given those features, I have trouble imagining a system where a 
compiler would be able to understand the developer’s intent and prevent issues 
without tagging protocol implementations in some manner.

Unless I’m incorrect in my assumption that there compiler could only infer 
developer intent via some sort of method tagging, then it really is a 

Re: [swift-evolution] Dictionary Enhancements

[Nate Cook via swift-evolution]

Hi Jon,

Thank you for the feedback, this is really valuable! A couple questions below.

> On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Thoughts inline.
> 
>> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Hi swift-evolution,
>> 
>> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
>> a thread to discuss improvements to the Dictionary type.
>> 
>> Here is a list of commonly requested changes/enhancements to Dictionary, all 
>> of which would probably be appropriate to put together into a single 
>> evolution proposal:
>> 
>> init from/merge in a Sequence of Key/Value pairs (already raised as SE-100: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md
>>  
>> ).
> +1. I have wanted this since Swift 1.
> 
>> make the Values view collection a MutableCollection (as in this PR: 
>> https://github.com/apple/swift-evolution/pull/555 
>> ).
> I think Nate’s proposal covers this case well.
> 
>> Add a defaulting subscript get (e.g. counts[key, default: 0] += 1 or 
>> grouped(key, default:[]].append(value)).
> I am indifferent to this. I am happy using ??.  I guess it could be slightly 
> more efficient because it avoids wrapping and unwrapping the optional.
> 
>> Add a group by-like init to create a Dictionary from a sequence of V 
>> and a closure (V)->K.
> +1. I would use this.
> 
>> Add Dictionary.filter to return a Dictionary.
> +1.
> 
>> Add Dictionary.mapValues to return a Dictionary (can be more efficiently 
>> implemented than composition as the storage layout remains the same).
> +1000.  I have also been asking for this since the beginning.  I built my own 
> version (and use it frequently), but as you say, the standard library can do 
> it much more efficiently.
> 
> I would also like to see an in-place version as well.
> 
> One design detail. Even though it is only mapping the values, I would like it 
> to pass the key to the closure as well.  It occasionally figures in to the 
> mapping logic.

Do you have any examples you can share where you use the key in this type of 
map? I'm not contesting its usefulness; it would just be helpful to see some 
real-world usage.

>> Add capacity property and reserveCapacity() method.
> +0.5. I could see it being useful occasionally.
> 
>> Have Dictionary.removeAtIndex return the Index of the next entry.
> No opinion on this.
> 
>> (once we have conditional conformance) Make dictionaries with Equatable 
>> values Equatable.
> +1
> 
>> Please reply here with any comments or questions on the above list, or any 
>> additions you believe are important that are missing from it.
>> 
> I would also like to see a version of map which returns a dictionary and 
> handles key collisions:
> 
>   let newDict = myDict.map(collision: {k,v1,v2 in v2}) { (k,v) in ... }
> 
> The collision parameter would take a throwing closure and handle the case of 
> a key conflict (by returning the value to use, throwing, or trapping).  It 
> would have a default value so that it would only have to be specified if a 
> different behavior was desired.  
> 
> In advanced cases, the collision could be used to accumulate values together. 
>  Because of this, I would actually like to see this on *collection* (not just 
> dictionary).  The map closure is handed each element of the sequence (which 
> in the case of dictionary is a key/value tuple), and expects a return value 
> of a key/value tuple.  The collision block is called when a key is returned 
> which has already been used to figure out what value to use.  This might 
> choose a winner, or it could act like reduce, building a value from the 
> components.

I think the uses you're describing are handled by the merging initializer 
proposed in SE-100:

https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md
 


For example, you can use a combining closure to select specific elements when 
the keys collide:

let duplicates: DictionaryLiteral = ["a": 1, "b": 2, "a": 3, "b": 4]
// Using the first value only
Dictionary(merging: duplicates, combine: { (first, _) in first })// ["b": 
2, "a": 1]
// Using the maximum value
Dictionary(merging: duplicates, combine: max)  // ["b": 4, "a": 3]

or to calculate the frequencies of values in a sequence:

extension Sequence where Iterator.Element: Hashable {
func frequencies() -> [Iterator.Element: Int] {
return Dictionary(merging: self.lazy.map { v in (v, 1) }, combine: +)
}

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

[Xiaodi Wu via swift-evolution]

This draft proposes something that's been discussed on this list several
times over the past few years, but now with a different spelling. However,
previous objections never centered around the spelling.

As discussed in previous threads on this topic, any such required keyword
breaks retroactive conformance. That is, if I want to conform someone
else's type to my protocol, I must edit that person's code if your idea is
accepted.

In so doing, this idea rejects an important (essential, IMO) mental model
of what protocol conformance entails. Specifically, I conform a type T to a
protocol P when I discover, having already implemented T, that it fulfills
the semantic and syntactic requirements of P. Unlike subclassing, I'm not
setting out with the intention of making a type T that conforms to P;
rather, I discover this fact to my great delight after implementation of T.
The analogy to subclassing is therefore inaccurate. Notionally, one always
inherits from a superclass first, then overrides.

This is no mere theoretical notion. It is a Swift idiom to state
conformance to protocols in an extension. Sometimes, the type will already
implement some but not all of the protocol's requirements outside that
extension because it is essential to the raison d'être of the type, and
only the balance of the requirements would then be implemented in the
extension that states conformance. It would be exceedingly unfortunate to
forbid this pattern, which is both elegant and expressive, but OTOH it
would be strange to have a method declare that it fulfills a requirement of
a protocol to which, lexically, it had not yet been conformed.

Lastly, it makes a very common task, that of conforming to a protocol,
syntactically heavy. This is exacerbated when you consider that the scheme
outlined here has the greatest benefit only when conformance to one
protocol is concerned. When conforming to more than one protocol, a similar
level of compiler help can only be obtained if you allow annotations as to
which protocol's requirement is being fulfilled. To implement this
additional syntax would be ludicrously heavy, but to ignore the issue would
be failing to consider one major aspect of protocols: composability (as
opposed to single inheritance). Again here, this is a critical difference
from subclassing that makes adapting "override" (regardless of whether you
choose a novel spelling) ineffectual.

Previous discussions on this topic have agreed that the developer
experience of conforming a type to a protocol can be greatly improved, but
the consensus has been that requiring a keyword to indicate protocol
requirements is not the way to go about it. I too would love to see
progress made on this issue, but having been previously an advocate for a
solution similar to yours, the views of some very wise people have changed
my thinking.
On Fri, Feb 17, 2017 at 21:29 David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> I wrote up the following draft proposal around attempting to clarify
> protocol implementation and protocol extensions, via annotating methods and
> properties meant to satisfy protocol requirements with additional keywords:
>
> "Types implementing protocols with optional features (either through
> default implementations on extensions, or optional methods on objective-C
> protocols) do not have a way to detect either local typos or later upstream
> changes to the protocol  method signatures will result in behavioral
> changes. This proposal attempts to rectify that in a manner similar
> to override on subclassed types."
>
> I’d appreciate feedback from the list! This is very much a first draft,
> likely filled with tyops.
>
> https://gist.github.com/dwaite/5a10e759a0efd0d9d16e066db4291552
>
> -DW
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Feb 17, 2017, at 17:45, Joe Groff  wrote:
> 
>• What is your evaluation of the proposal?
Overall, a big +1

I'll 2nd not deprecating the BitwiseOperations protocol, though.

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

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

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

>• How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?
I followed the thread pretty closely.

- Dave Sweeris 

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

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Hugo Hennies via swift-evolution]

> • What is your evaluation of the proposal?

Very good. It's a much needed improvement to the language's integer protocols 
and type hierarchy.

I would argue against the deprecation of the BitwiseOperations protocol though. 
I believe a bitset type would be a good candidate for conformance to this 
protocol while at the same time not being an integer at all. 

I do not propose to a standard library implementation of a bitset type, but I 
think the standard protocols should let themselves to be easily extended and 
implemented by user types. Assuming only integers will ever have bitwise 
operations might limit users and force them to write duplicate code.

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

Yes, the previous protocols were confusing and didn't let themselves very well 
to generic programming over the various integer types of the language.

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

Yes, this proposal very much captures the feel of the language and it's 
standard library.

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

I haven't used a language before that I could compare effectively with the 
features proposed here.

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

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Jonathan Hull via swift-evolution]

My ideal scenario:

1) Go back to Swift 2 meaning of private

2) Add the ‘hidden’ axis I talked about in another thread.  

This will provide the capabilities of protected + friend (and allow extensions 
organized across files) using a consistent file-based approach that is easy to 
reason about.  It also neatly avoids the issues mentioned in the blog post.

Thanks,
Jon

> On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> https://developer.apple.com/swift/blog/?id=11 
> 
> 
> 
> 
> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution 
> > wrote:
> 
>> How about removing fileprivate, getting Swift 2 meaning of private (as most 
>> people here now suggest) and add additional @protected annotation for those 
>> who want a more fine-grained solution:
>> 
>> @protected private - members accessable only from the class/struct/enum/... 
>> and their extensions within the file
>> 
>> @protected internal - again, but you can access it even from extensions and 
>> subclasses outside of the file within the entire module.
>> 
>> @protected public/open - the same as above, but outside the modules.
>> 
>> To me, this way most people here will be happy:
>> 
>> - those wishing the access control gets simplified - it in fact does, you 
>> don't need to use @protected, if you don't want to/need to.
>> - those who need a fine-grained solution, here it is.
>> 
>> 
>> 
>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution 
 > wrote:
 
 
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution 
> > wrote:
> 
> While we’re bikeshedding, I’m going to add my two cents. Hold on to your 
> hat because this might be controversial here.
> 
> I think both ‘private’ and ‘fileprivate’ are unnecessary complications 
> that only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public only. No 
> private, no fileprivate, no lineprivate, no protected. It’s all silly.
 
 Eh, I've used `private` to keep myself honest in terms of going through 
 some book-keeping functions instead of directly accessing a property.
>>> 
>>> This is exactly the kind of thing I like it for and why I hope we might be 
>>> able to keep scoped access even if it gets a new name that ends up as 
>>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning).
>>> 
 
 - Dave Sweeris
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Proposal Draft] nil Values for Objective-C Primitives

[Jeff Kelley via swift-evolution]

Hello all!

Following our previous discussion 

 about importing primitives from Objective-C as optionals, I’ve written a draft 
proposal for your consideration. All feedback is greatly appreciated!

https://gist.github.com/SlaunchaMan/612107f434be9764bc39e4ce149b4e21 


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  | 
jeffkelley.org 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

[David Waite via swift-evolution]

I wrote up the following draft proposal around attempting to clarify protocol 
implementation and protocol extensions, via annotating methods and properties 
meant to satisfy protocol requirements with additional keywords:

"Types implementing protocols with optional features (either through default 
implementations on extensions, or optional methods on objective-C protocols) do 
not have a way to detect either local typos or later upstream changes to the 
protocol  method signatures will result in behavioral changes. This proposal 
attempts to rectify that in a manner similar to override on subclassed types."

I’d appreciate feedback from the list! This is very much a first draft, likely 
filled with tyops.

https://gist.github.com/dwaite/5a10e759a0efd0d9d16e066db4291552 


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

[swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

[John McCall via swift-evolution]

Hello Swift community,

The review of "SE-0155: Normalize Enum Case Representation" begins now and runs 
through next Friday, February 26th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
 


Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
 


Reply text

Other replies

What goes into a review?

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

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

More information about the Swift evolution process is available at 
https://github.com/apple/swift-evolution/blob/master/process.md 


Thank you,

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

Re: [swift-evolution] Dictionary Enhancements

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Thoughts inline.
> 
>> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hi swift-evolution,
>> 
>> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
>> a thread to discuss improvements to the Dictionary type.
>> 
>> Here is a list of commonly requested changes/enhancements to Dictionary, all 
>> of which would probably be appropriate to put together into a single 
>> evolution proposal:
>> 
>> init from/merge in a Sequence of Key/Value pairs (already raised as SE-100: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md).
> +1. I have wanted this since Swift 1.
> 
>> make the Values view collection a MutableCollection (as in this PR: 
>> https://github.com/apple/swift-evolution/pull/555).
> I think Nate’s proposal covers this case well.
> 
>> Add a defaulting subscript get (e.g. counts[key, default: 0] += 1 or 
>> grouped(key, default:[]].append(value)).
> I am indifferent to this. I am happy using ??.  I guess it could be slightly 
> more efficient because it avoids wrapping and unwrapping the optional.
> 
>> Add a group by-like init to create a Dictionary from a sequence of V 
>> and a closure (V)->K.
> +1. I would use this.
> 
>> Add Dictionary.filter to return a Dictionary.
> +1.
> 
>> Add Dictionary.mapValues to return a Dictionary (can be more efficiently 
>> implemented than composition as the storage layout remains the same).
> +1000.  I have also been asking for this since the beginning.  I built my own 
> version (and use it frequently), but as you say, the standard library can do 
> it much more efficiently.

Agree this is a big one.  Hopefully if we ever get higher-kinded types we might 
also have a way to map this method (pun intended) to a Dictionary 
implementation of Functor.

> 
> I would also like to see an in-place version as well.

This would be useful for transformations mapping values to the same type.

> 
> One design detail. Even though it is only mapping the values, I would like it 
> to pass the key to the closure as well.  It occasionally figures in to the 
> mapping logic.

I can see how this could be useful but it should be an additional overload.  I 
want to be able to give mapValues any function that just takes the value type 
as input.

> 
> 
>> Add capacity property and reserveCapacity() method.
> +0.5. I could see it being useful occasionally.
> 
>> Have Dictionary.removeAtIndex return the Index of the next entry.
> No opinion on this.
> 
>> (once we have conditional conformance) Make dictionaries with Equatable 
>> values Equatable.
> +1
> 
>> Please reply here with any comments or questions on the above list, or any 
>> additions you believe are important that are missing from it.
>> 
> I would also like to see a version of map which returns a dictionary and 
> handles key collisions:
> 
>   let newDict = myDict.map(collision: {k,v1,v2 in v2}) { (k,v) in ... }
> 
> The collision parameter would take a throwing closure and handle the case of 
> a key conflict (by returning the value to use, throwing, or trapping).  It 
> would have a default value so that it would only have to be specified if a 
> different behavior was desired.  
> 
> In advanced cases, the collision could be used to accumulate values together. 
>  Because of this, I would actually like to see this on *collection* (not just 
> dictionary).  The map closure is handed each element of the sequence (which 
> in the case of dictionary is a key/value tuple), and expects a return value 
> of a key/value tuple.  The collision block is called when a key is returned 
> which has already been used to figure out what value to use.  This might 
> choose a winner, or it could act like reduce, building a value from the 
> components.
> 
> As a concrete example of what this allows, I could take in an array of 
> words/strings [“apple”, “aardvark”, …] and then do the following to get a 
> count of how many words start with each letter:
>   
>   let letterFrequency = words.map(collision:{$1+$2}) { 
> (String($0.characters.first ?? “”) ,1)}
>   
>   print(letterFrequency[“a”]) //number of words starting with “a"
> 
> I am ok using a term other than ‘map' if that is easier on the compiler, but 
> I would like this functionality.  At the simple end, it allows map 
> functionality for both keys and values.  At the advanced end, it acts as a 
> categorizing reduce over a sequence/collection.

This is a very interesting idea.

> 
> You can even trivially implement the proposed groupBy with it (this is on 
> Collection, but you could do an init on dict the same way):
> 
>   func grouped(by categorizer: (Element)->K ) -> [K:Element] {
>   return self.map(collision:{$1+$2}) {(categorizer($0), [$0])}
>   }

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 17, 2017, at 6:10 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez  > wrote:
> 
>> 
>> From Ted.
>>> Relative to Swift 3, the bar for such changes is significantly higher:
>>> 
>>> The existing syntax/API being changed must be actively harmful.
>>> The new syntax/API must clearly be better and not conflict with existing 
>>> Swift syntax.
>>> There must be a reasonably automatable migration path for existing code.
>> 
>> 
>> I don’t think there is evidence that scope private in Swift3 is "actively 
>> harmful”. 
>> Reverting to Swift2 file-private as private is not clearly better. 
>> The community has not converged on a clear winner. 
>> 
>> The only positive thing here is that if we get rid of scope private then it 
>> will be easy to make private alias to file-private so no code will break, 
>> but we would be removing a feature so I would think this is a breaking 
>> change. 
>> 
>> Would removing private and fileprivate by making them alias to internal also 
>> be a breaking change? Even if the code will still compile?
> 
> Thanks for posting this Jose.  I think the point that has near unanimous 
> agreement is that assigning `private` the meaning of scoped access was a 
> mistake.  `fileprivate` is too awkward given how frequently it is necessary 
> in common idioms of Swift code organization.  
> 
> Whether scoped access itself is a valuable feature and whether it should 
> remain is the question that is turning out to be very controversial.  The 
> mistake we made with the keywords in Swift 3 certainly didn't help make the 
> case for it.  
> 
> That's why I would like to see us try to fix that mistake.  I think everyone 
> can be reasonably happy if we can all use `private` the way we did in Swift 2 
> and `scoped` can become a style issue.  Some teams can have a linter reject 
> it and those of us who like it can continue using it.  As a bonus, we would 
> eliminate an awkward keyword.

I appreciate the enthusiasm about this but the same argument can be used the 
other way. 

What about renaming `fileprivate` to `privy`. Shorter than private, typing 
`pri` would auto complete to it,  more swifty. Win Win. :) 

Its going to be hard finding names for either scope private or file private 
that the community will agree with. 

Its going to be a hard sale given the other more important features being 
worked on.

> 
>> 
>> This is a linter problem. If people don’t want other people in their team to 
>> use scope private then make it part of the coding style. 
>> 
>> If people do not want fileprivate because it looks ugly, then force 
>> everybody to use scope private using a linter like swiftlint. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
> > wrote:
> 
> Personally I feel enforced encapsulation of implementation detail to the 
> latter group is less important than the former, and can be handled by 
> convention. Whereas other users of your module definitely benefit from 
> access control and being able to consume a clearly-defined interface.
 
 I think failing to provide some sort of below-`internal` privacy would be 
 missing *really* low-hanging fruit for no good reason. The languages I can 
 think of which don't include some sort of sub-library-wide privacy 
 level—Objective-C, Javascript, Perl, Python—usually have very simple 
 object designs with a flat namespace. (Well, there's Rust, but Rust lets 
 you wrap anything you'd like in a module.) Even Objective-C in practice 
 includes a `fileprivate` equivalent in the form of methods declared only 
 in the .m file.
 
 I also think it's often helpful to be able to change a member's access 
 level without having to change all references to it. Publishing or 
 privatizing an interface is not an uncommon refactoring.
 
 Not everybody likes our current semantics, but that's no reason to throw 
 the feature out entirely.
>>> 
>>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>>> we can reconsider using `scoped` as the keyword for scoped access rather 
>>> than abandoning it.  Does anyone remember why this was considered a bad 
>>> idea?
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 

Re: [swift-evolution] Dictionary Enhancements

[Jonathan Hull via swift-evolution]

Thoughts inline.

> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi swift-evolution,
> 
> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
> a thread to discuss improvements to the Dictionary type.
> 
> Here is a list of commonly requested changes/enhancements to Dictionary, all 
> of which would probably be appropriate to put together into a single 
> evolution proposal:
> 
> init from/merge in a Sequence of Key/Value pairs (already raised as SE-100: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md
>  
> ).
+1. I have wanted this since Swift 1.

> make the Values view collection a MutableCollection (as in this PR: 
> https://github.com/apple/swift-evolution/pull/555 
> ).
I think Nate’s proposal covers this case well.

> Add a defaulting subscript get (e.g. counts[key, default: 0] += 1 or 
> grouped(key, default:[]].append(value)).
I am indifferent to this. I am happy using ??.  I guess it could be slightly 
more efficient because it avoids wrapping and unwrapping the optional.

> Add a group by-like init to create a Dictionary from a sequence of V 
> and a closure (V)->K.
+1. I would use this.

> Add Dictionary.filter to return a Dictionary.
+1.

> Add Dictionary.mapValues to return a Dictionary (can be more efficiently 
> implemented than composition as the storage layout remains the same).
+1000.  I have also been asking for this since the beginning.  I built my own 
version (and use it frequently), but as you say, the standard library can do it 
much more efficiently.

I would also like to see an in-place version as well.

One design detail. Even though it is only mapping the values, I would like it 
to pass the key to the closure as well.  It occasionally figures in to the 
mapping logic.


> Add capacity property and reserveCapacity() method.
+0.5. I could see it being useful occasionally.

> Have Dictionary.removeAtIndex return the Index of the next entry.
No opinion on this.

> (once we have conditional conformance) Make dictionaries with Equatable 
> values Equatable.
+1

> Please reply here with any comments or questions on the above list, or any 
> additions you believe are important that are missing from it.
> 
I would also like to see a version of map which returns a dictionary and 
handles key collisions:

let newDict = myDict.map(collision: {k,v1,v2 in v2}) { (k,v) in ... }

The collision parameter would take a throwing closure and handle the case of a 
key conflict (by returning the value to use, throwing, or trapping).  It would 
have a default value so that it would only have to be specified if a different 
behavior was desired.  

In advanced cases, the collision could be used to accumulate values together.  
Because of this, I would actually like to see this on *collection* (not just 
dictionary).  The map closure is handed each element of the sequence (which in 
the case of dictionary is a key/value tuple), and expects a return value of a 
key/value tuple.  The collision block is called when a key is returned which 
has already been used to figure out what value to use.  This might choose a 
winner, or it could act like reduce, building a value from the components.

As a concrete example of what this allows, I could take in an array of 
words/strings [“apple”, “aardvark”, …] and then do the following to get a count 
of how many words start with each letter:

let letterFrequency = words.map(collision:{$1+$2}) { 
(String($0.characters.first ?? “”) ,1)}

print(letterFrequency[“a”]) //number of words starting with “a"

I am ok using a term other than ‘map' if that is easier on the compiler, but I 
would like this functionality.  At the simple end, it allows map functionality 
for both keys and values.  At the advanced end, it acts as a categorizing 
reduce over a sequence/collection.

You can even trivially implement the proposed groupBy with it (this is on 
Collection, but you could do an init on dict the same way):

func grouped(by categorizer: (Element)->K ) -> [K:Element] {
return self.map(collision:{$1+$2}) {(categorizer($0), [$0])}
}


Thanks,
Jon


> All methods added to the standard library increase complexity, so need a 
> strong justification to reduce the risk of API sprawl. When requesting 
> additions/modifications, please keep the following questions in mind:
> 
> Is the suggested addition a common operation that many would find useful? Can 
> it be flexible enough to cover different needs?
> Will it encourage good practice? Might it be misused or encourage 
> anti-patterns?
> Can the operation be composed simply from existing std lib features? Is that 
> composition 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 17, 2017, at 4:51 PM, Xiaodi Wu  wrote:
> 
> Although there was willingness to depart from conventions in other C-style 
> languages, I believe it was decided that having a counterpart to other 
> languages' "private" that isn't named private *and* also a "private" that 
> isn't a counterpart to other languages' "private" was too idiosyncratic and 
> actively confusing.

Ahh, yes.  I remember this being discussed.  I think that we have learned a lot 
since this discussion took place.  I think it puts too much weight on what 
other languages do and not enough on what is right for Swift where extensions 
are used pervasively to organize code.  

The worst case scenario for someone coming from a C-style language who doesn't 
understand the nuances of Swift yet is that they use `private` and the entity 
has broader visibility than expected, but still within the same file.  Given 
the volume of support for the argument that access control within the same file 
isn't important I think it's safe to say that the consequences of this 
misunderstanding are not that big a deal.  If the developer cares about such 
things they will learn about `scoped` soon enough.

> 
> If I recall, the proposal as submitted for core team review actually proposed 
> something like you suggest, and it was the core team that decided to change 
> it on review.

Yes, it didn't touch `private` and used `local` for scoped access which was a 
bad name for many reasons.  The conversation had always called it "scoped 
access" informally.  I think `scoped` would make a good name for it and find it 
pretty unfortunate that it wasn't spelled that way in the initial proposal. 

> 
> 
>> On Fri, Feb 17, 2017 at 16:36 Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> > On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
>> >  wrote:
>> >
>> >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
>> >>  wrote:
>> >>
>> >> Personally I feel enforced encapsulation of implementation detail to the 
>> >> latter group is less important than the former, and can be handled by 
>> >> convention. Whereas other users of your module definitely benefit from 
>> >> access control and being able to consume a clearly-defined interface.
>> >
>> > I think failing to provide some sort of below-`internal` privacy would be 
>> > missing *really* low-hanging fruit for no good reason. The languages I can 
>> > think of which don't include some sort of sub-library-wide privacy 
>> > level—Objective-C, Javascript, Perl, Python—usually have very simple 
>> > object designs with a flat namespace. (Well, there's Rust, but Rust lets 
>> > you wrap anything you'd like in a module.) Even Objective-C in practice 
>> > includes a `fileprivate` equivalent in the form of methods declared only 
>> > in the .m file.
>> >
>> > I also think it's often helpful to be able to change a member's access 
>> > level without having to change all references to it. Publishing or 
>> > privatizing an interface is not an uncommon refactoring.
>> >
>> > Not everybody likes our current semantics, but that's no reason to throw 
>> > the feature out entirely.
>> 
>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>> we can reconsider using `scoped` as the keyword for scoped access rather 
>> than abandoning it.  Does anyone remember why this was considered a bad idea?
>> 
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez  wrote:
> 
> From Ted.
>> Relative to Swift 3, the bar for such changes is significantly higher:
>> 
>> The existing syntax/API being changed must be actively harmful.
>> The new syntax/API must clearly be better and not conflict with existing 
>> Swift syntax.
>> There must be a reasonably automatable migration path for existing code.
> 
> 
> I don’t think there is evidence that scope private in Swift3 is "actively 
> harmful”. 
> Reverting to Swift2 file-private as private is not clearly better. 
> The community has not converged on a clear winner. 
> 
> The only positive thing here is that if we get rid of scope private then it 
> will be easy to make private alias to file-private so no code will break, but 
> we would be removing a feature so I would think this is a breaking change. 
> 
> Would removing private and fileprivate by making them alias to internal also 
> be a breaking change? Even if the code will still compile?

Thanks for posting this Jose.  I think the point that has near unanimous 
agreement is that assigning `private` the meaning of scoped access was a 
mistake.  `fileprivate` is too awkward given how frequently it is necessary in 
common idioms of Swift code organization.  

Whether scoped access itself is a valuable feature and whether it should remain 
is the question that is turning out to be very controversial.  The mistake we 
made with the keywords in Swift 3 certainly didn't help make the case for it.  

That's why I would like to see us try to fix that mistake.  I think everyone 
can be reasonably happy if we can all use `private` the way we did in Swift 2 
and `scoped` can become a style issue.  Some teams can have a linter reject it 
and those of us who like it can continue using it.  As a bonus, we would 
eliminate an awkward keyword.

> 
> This is a linter problem. If people don’t want other people in their team to 
> use scope private then make it part of the coding style. 
> 
> If people do not want fileprivate because it looks ugly, then force everybody 
> to use scope private using a linter like swiftlint. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
  wrote:
 
 Personally I feel enforced encapsulation of implementation detail to the 
 latter group is less important than the former, and can be handled by 
 convention. Whereas other users of your module definitely benefit from 
 access control and being able to consume a clearly-defined interface.
>>> 
>>> I think failing to provide some sort of below-`internal` privacy would be 
>>> missing *really* low-hanging fruit for no good reason. The languages I can 
>>> think of which don't include some sort of sub-library-wide privacy 
>>> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
>>> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
>>> anything you'd like in a module.) Even Objective-C in practice includes a 
>>> `fileprivate` equivalent in the form of methods declared only in the .m 
>>> file.
>>> 
>>> I also think it's often helpful to be able to change a member's access 
>>> level without having to change all references to it. Publishing or 
>>> privatizing an interface is not an uncommon refactoring.
>>> 
>>> Not everybody likes our current semantics, but that's no reason to throw 
>>> the feature out entirely.
>> 
>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
>> we can reconsider using `scoped` as the keyword for scoped access rather 
>> than abandoning it.  Does anyone remember why this was considered a bad idea?
>> 
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution 
>>  wrote:
>>> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> Here, a function call is an _intentional_ act. Writing a function not meant 
>>> to be called is an _intentional_ act. It is strange that you would demand 
>>> the compiler to stand between two of your own intentional acts.
>> 
>> Yesterday I stated one intention. Today I (or a coworker) act with a 
>> contradictory intention.
>> 
>> One of these intentions, or some underlying assumption, must be in error.
> 
> Must it? Contradiction != error. I can simultaneously not want to expose a 
> member as the vendor of the API *and* want to invoke the same member as the 
> consumer of the API. Why must I be in error?
>  
>> Why would I want to rely on a human to notice the error, if I can make the 
>> compiler do it?
>> 
>> It is normal to want the compiler to catch my errors. It is strange to 
>> prefer finding errors manually.
> 
> I can agree that compilers should catch errors. I want to persuade you that 
> what we are talking about here does not fall into the category of error.

I don't view it so much as an error as I do a great tool to communicate 
compiler verified intent across time (to future readers and to your future 
self).  As with many things in programming, the value of this is subjective (or 
at least subject of plentiful debate).  I personally find it quite useful and 
it's clear that I am not alone.  On the other hand, it's clear that many people 
don't find it terribly useful.

> 
>> You might persuade me that the cost (in language complexity) of having the 
>> compiler detect the contradiction outweighs the benefit.
>> 
>> But I doubt you can persuade me that the detection has no benefit.
>> 
>> 
>> ___
>> 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] [Re-Review] SE-0104: Protocol-oriented integers

[Xiaodi Wu via swift-evolution]

> • What is your evaluation of the proposal?
>

Excellent, even better than the first take. Still not sure about the
`FullWidth` design, but it'll do.

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

Yes, the previous protocols were confusing and ultimately not very useful.

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

Yes, after overhauling floating point protocols, the rest of the numeric
types are overdue for this change.

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

I've struggled with the Swift 2/3 integer protocols, does that count? This
proposal is a huge improvement.

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

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

[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

[Joe Groff via swift-evolution]

Hello Swift community,

The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
through February 25, 2017. This proposal was accepted for Swift 3, but was not 
implemented in time for the release. The revised proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

Reply text

Other replies

What goes into a review?

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

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

More information about the Swift evolution process is available at

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

Thank you,

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

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Xiaodi Wu via swift-evolution]

>
>
>- What is your evaluation of the proposal?
>
> This document seems to propose two contradictory alternative solutions; I
assume the goal is that the core team will choose one of two. I'm not sure
that either is an improvement over the status quo, for reasons I outline
below.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> I agree that the current situation is problematic because of
inconsistency, but I think both proposed solutions are more problematic
because of more inconsistency.


>
>- Does this proposal fit well with the feel and direction of Swift?
>
> On the one hand, I can agree that `@NSCopying` not being respected in
`init()` can be confusing. However, as was pointed out during the initial
pitch, this is consistent with other behaviors. For example, `didSet` is
not called from `init()` either, and there are good reasons for this. If
the proposal for custom behaviors were to come back into consideration, I
would assume that none of those behaviors could be triggered from `init()`
either.

A person who is new to Swift would continue to be confused if `@NSCopying`
had magic but `didSet` and other behaviors did not. A person who has
studied Swift and internalized the reasoning behind this initially tricky
situation might rightly expect that _all_ behaviors, including
`@NSCopying`, are ignored during `init`.

The proposal seems to prioritize new users migrating from Obj-C, who are
unfamiliar with Swift idioms, over Swift users who are right to expect some
internal consistency in the language. While supporting both groups is
important, I'm not sure it's appropriate to increase inconsistency within
Swift itself to help with migration from Obj-C.


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


>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> A quick reading.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez via swift-evolution]

From Ted.
> Relative to Swift 3, the bar for such changes is significantly higher:
> 
> The existing syntax/API being changed must be actively harmful.
> The new syntax/API must clearly be better and not conflict with existing 
> Swift syntax.
> There must be a reasonably automatable migration path for existing code.


I don’t think there is evidence that scope private in Swift3 is "actively 
harmful”. 
Reverting to Swift2 file-private as private is not clearly better. 
The community has not converged on a clear winner. 

The only positive thing here is that if we get rid of scope private then it 
will be easy to make private alias to file-private so no code will break, but 
we would be removing a feature so I would think this is a breaking change. 

Would removing private and fileprivate by making them alias to internal also be 
a breaking change? Even if the code will still compile?

This is a linter problem. If people don’t want other people in their team to 
use scope private then make it part of the coding style. 

If people do not want fileprivate because it looks ugly, then force everybody 
to use scope private using a linter like swiftlint. 



















> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Personally I feel enforced encapsulation of implementation detail to the 
>>> latter group is less important than the former, and can be handled by 
>>> convention. Whereas other users of your module definitely benefit from 
>>> access control and being able to consume a clearly-defined interface.
>> 
>> I think failing to provide some sort of below-`internal` privacy would be 
>> missing *really* low-hanging fruit for no good reason. The languages I can 
>> think of which don't include some sort of sub-library-wide privacy 
>> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
>> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
>> anything you'd like in a module.) Even Objective-C in practice includes a 
>> `fileprivate` equivalent in the form of methods declared only in the .m file.
>> 
>> I also think it's often helpful to be able to change a member's access level 
>> without having to change all references to it. Publishing or privatizing an 
>> interface is not an uncommon refactoring.
>> 
>> Not everybody likes our current semantics, but that's no reason to throw the 
>> feature out entirely.
> 
> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully 
> we can reconsider using `scoped` as the keyword for scoped access rather than 
> abandoning it.  Does anyone remember why this was considered a bad idea?
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution <
swift-evolution@swift.org> wrote:

> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Here, a function call is an _intentional_ act. Writing a function not
>> meant to be called is an _intentional_ act. It is strange that you would
>> demand the compiler to stand between two of your own intentional acts.
>
>
> Yesterday I stated one intention. Today I (or a coworker) act with a
> contradictory intention.
>
> One of these intentions, or some underlying assumption, must be in error.
>

Must it? Contradiction != error. I can simultaneously not want to expose a
member as the vendor of the API *and* want to invoke the same member as the
consumer of the API. Why must I be in error?


> Why would I want to rely on a human to notice the error, if I can make the
> compiler do it?
>
> It is normal to want the compiler to catch my errors. It is strange to
> prefer finding errors manually.
>

I can agree that compilers should catch errors. I want to persuade you that
what we are talking about here does not fall into the category of error.

You might persuade me that the cost (in language complexity) of having the
> compiler detect the contradiction outweighs the benefit.
>
> But I doubt you can persuade me that the detection has no benefit.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

[Adrian Zubarev via swift-evolution]

What is your evaluation of the proposal?

This is welcome improvement.

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

Definitely.

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

It does indeed.

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

I can’t think of an example to compare with.

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

Carefully read the whole proposal and took part in discussions involving the 
proposed solution.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0154 "Provide Custom Collections for Dictionary Keys and 
Values" begins now and runs through February 22, 2017. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md
Reply text

Other replies
 What 
goes into a review?

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

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

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

Thank you,

-Doug Gregor

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Rob Mayoff via swift-evolution]

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Here, a function call is an _intentional_ act. Writing a function not
> meant to be called is an _intentional_ act. It is strange that you would
> demand the compiler to stand between two of your own intentional acts.


Yesterday I stated one intention. Today I (or a coworker) act with a
contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Why would I want to rely on a human to notice the error, if I can make the
compiler do it?

It is normal to want the compiler to catch my errors. It is strange to
prefer finding errors manually.

You might persuade me that the cost (in language complexity) of having the
compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0153 "Compensate for the inconsistency of @NSCopying's 
behaviour" begins now and runs through February 22, 2017. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
Reply text

Other replies
 What 
goes into a review?

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

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

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

Thank you,

-Doug Gregor

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

Re: [swift-evolution] Sequence/Collection Enhancements

[David Waite via swift-evolution]

> On Feb 16, 2017, at 5:39 PM, Ben Cohen via swift-evolution 
> > wrote:
> 
> Hi swift-evolution,
> 
> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
> a thread to discuss additive algorithms for Sequence and Collection.
> 
> Here is a list of commonly requested algorithms to operate on Sequence or 
> Collection:
> 
> In-place transformations:
> transform elements in a MutableCollection using a closure i.e. in-place map
I assume this would be an (Element)->Element transform?

> Check if all elements in a Sequence match a predicate (i.e. 
> !contains(!predicate))
I created this one to clean up some Sequence code earlier this week

> Is writing the equivalent by hand hard to make efficient? Are there common 
> performance traps that this addition would help avoid?
I suspect this is where remove(where:) and remove(indices:) for example would 
really shine as additions.

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Abe Schneider via swift-evolution]

I might(?) agree with others that  `constexpr` might overlap but be
ultimately different from `pure`. However, to me `constexpr` is more
interesting because it would provide a potential macro language.

As for syntax, while I think that matters less, I suspect trying to
find why code isn't working and having to find a "->" vs. "=>" might
be difficult.

As for the pure aspect, couldn't that compiler just look at the
arguments and determine that the function has no side effects? The
only complication comes when its a method to a class. However,
something like the c++ notation of:

int bar() const { ... }

could be used. However, it might be more Swiftly to do something like:

   const func bar() -> int { ... }

as others have suggested. This would make many non-member functions
automatically get made into purely-functional forms (with potential
optimizations). You should be able to do the same thing with type
methods (static/class).

On Fri, Feb 17, 2017 at 11:18 AM, Anton Zhilin  wrote:
> I didn’t mean to emphasize any specific syntax. I’m fine with either @const,
> @constexpr, @pure or =>.
> Anyway, I see no reason why generic functions shouldn’t be supported in any
> of the suggested models.
>
> 2017-02-17 19:08 GMT+03:00 Abe Schneider :
>>
>> +1. I think this is a great idea. As I was following this thread, I
>> was wondering if someone might suggest the C++ constexpr syntax.
>>
>> Would this support generics? E.g. could you do:
>>
>> @constepxr
>> func foo(a:S, b:S) {
>>return a+b
>> }
>>
>> and have that be done at compile time? While this could potentially
>> add a huge amount of complication on the backend, I could this as
>> being useful (also related to my previous postings as to having a way
>> of determining generic types at compile time).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 4, stage 2 starts now

[Douglas Gregor via swift-evolution]

> On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Stage 2
> 
> With ABI stability well-understood and many of the stage 1 goals underway, it 
> is time to open up Swift 4 stage 2 to expand the scope of proposals to be 
> considered.
> 
> Timeline
> 
> Stage 2 starts right now.  All design work and discussion for stage 2 extends 
> to April 1, 2017. The intent is to timebox discussion to provide adequate 
> time for the actual implementation of accepted proposals.
> 
> Scope
> 
> Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2 
> proposals may include some additive changes and changes to existing features 
> that don't affect the ABI. There are a few focus areas for Swift 4 stage 2:
> 
> Stage 1 proposals: Any proposal that would have been eligible for stage 1 is 
> a priority for stage 2.
> 
> Source-breaking changes: The Swift 4 compiler will provide a 
> source-compatibility mode to allow existing Swift 3 sources to compile, but 
> source-breaking changes can manifest in "Swift 4" mode. That said, changes to 
> fundamental parts of Swift's syntax or standard library APIs that breaks 
> source code are better front-loaded into Swift 4 than delayed until later 
> releases. Relative to Swift 3, the bar for such changes is significantly 
> higher:
> 
> The existing syntax/API being changed must be actively harmful.
> The new syntax/API must clearly be better and not conflict with existing 
> Swift syntax.
> There must be a reasonably automatable migration path for existing code.
> Improvements to existing Standard Library facilities: Additive changes that 
> improve existing standard library facilities can be considered. With standard 
> library additions in particular, proposals that provide corresponding 
> implementations are preferred. Potential focus areas for improvement include 
> collections (e.g., new collection algorithms) and improvements to the 
> ergonomics of Dictionary.
> 
> Foundation improvements: We anticipate proposing some targeted improvements 
> to Foundation API to continue the goal of making the Cocoa SDK work 
> seamlessly in Swift. Details on the specific goals will be provided as we get 
> started on Swift 4 stage 2.
> 

Because of the narrow scope and tight schedule, the core team will be looking 
at the various proposals coming in and actively deferring/closing those that 
are out of scope. A member of the core team will reply to the thread here on 
swift-evolution and/or annotate the pull request with our rationale when we do 
this.

- Doug

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

Re: [swift-evolution] [Pitch] Typed throws

[Colin Barrett via swift-evolution]

On Fri, Feb 17, 2017 at 4:46 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suggest we need to find a way to shorten the list of the possible error
> types with a the help of typeallias
>
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
>
> typealias MyErrors = MyError1 | MyError2 | MyError3
>
> func foo() throws(MyErrors) -> MyResult
> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
>
> Do you actually need that? Experience in other languages like Rust and
> Haskell that use Result-based error propagation suggests that a single
> error type is adequate, and beneficial in many ways. If nothing else, you
> could `Either` your way to multiple errors if you really needed to.
>
> IMO, if we accept a single error type per function, there could be a
> simpler model for this. We could say that the `throws` type is a generic
> parameter of all function types, and it defaults to the uninhabited `Never`
> type for functions that don't throw.
>
> () -> () == () throws Never -> ()
> () throws -> () == () throws Error -> ()
>
> In this model, you'd get many benefits:
>
> - `rethrows` could become first-class, reducing down to just polymorphic
> `throws`:
>
> func foo(_: () throws -> ()) rethrows // Swift 3
> func foo(_: () throws T -> ()) throws T // Swift X
> func foo(_: () throws T -> ()) throws Either
>
> - Protocols could abstract over error handling; for instance, we could
> support throwing sequences:
>
> protocol IteratorProtocol {
>   associatedtype Element
>   associatedtype Error: Swift.Error = Never
>
>   mutating func next() throws Error -> Element?
> }
>
>
I really dig this proposal, Joe. Matches my experience from other languages
as well.

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Daniel Leping via swift-evolution]

Second is better, but still looks ugly (no offense). I personally am
totally ok with auto determination for most cases. Explicit case doesn't
sound to me so widely used. I agree an explicit form might be of use in
some rare scenarios and as long there is a possibility to define the purity
(even in a long form) I'm ok with it.


On Sat, 18 Feb 2017 at 0:30 Matthew Johnson  wrote:

> On Feb 17, 2017, at 4:17 PM, Daniel Leping 
> wrote:
>
> I don't think I can (fully) agree with you, because a closure purity is
> not something you "define". It's rather what you use inside. Though I
> totally understand your concern and a wish to have localized errors.
>
> However, I think it's totally consistent if you use a full form in a way:
>
> { (a) => B in
> return a.toB()
> }
>
> What I mean is that short form can auto determine. If you want to be
> explicit... use the long form.
>
> Would this work for you, @Matthew?
>
>
> What I am saying is that I don’t think I should have to use the entire
> long form just to specify it’s a pure closure.  Something like the
> following would be acceptable:
>
> {= $0.some.pure.expression() }
> or
> {=> $0.some.pure.expression() }
>
> But I don’t want to be required to write out a name for the arguments and
> a return type for single expression closures like this.
>
>
> On Sat, 18 Feb 2017 at 0:09 Matthew Johnson 
> wrote:
>
> On Feb 17, 2017, at 4:05 PM, Daniel Leping 
> wrote:
>
> I personally like a lot => syntax for several reasons:
> 1. Consistent
> 2. Enforced return type
>
> As for the closures, I don't think we need an indication here. If it calls
> any impure function or captures a variable from outside - it's impure by
> definition. The compiler should decide if a closure can be treated pure.
> Same as with throwing.
>
>
> I’m not sure about this.  I would like the ability to syntactically state
> the intent that a closure is pure, and ideally do so in a way that doesn’t
> lose the conciseness of the closure (i.e. we shouldn’t have to give up any
> of the syntactic sugar available for simple closures).  A big benefit of
> allowing us to state intent like this is that it localizes error messages.
>
>
> As for the situation with currying (and other compositions), the situation
> is a lot more complicated than with rethrows. However, it's still
> deductible in compile time with the same mechanism as described above for
> closures.
>
> I tend to agree we could use ~> (looks good to me... volatile :)) for the
> function type definitions as an "unknown purity". The return type purity
> dependence graph can be built automatically at compile time. With this
> graph compiler can determine the returned function purity in every place
> function is used.
>
> The use of ~> should of course be limited to argument and return types of
> pure functions only. I think there might be a possibility of use in
> typealias, but need to think more about it.
>
> On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Out of curiosity, what are the benefits to being able to define that a
> closure must be pure as a parameter/type definition, as opposed to defining
> a particular closure to being pure while being passed?  What guarantees
> does it give you as the caller of the closure?
>
>
> If you only accept pure closures and otherwise meet the criteria of a pure
> function then you are pure.  If you have a function like that and want to
> accept both pure and impure closures and receive the purity of the closure
> provided then we need syntax indicating something similar to `rethrows`,
> but for purity.
>
>
> Thanks,
> Jon
>
>
> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan  wrote:
>
> I am ok with a keyword but `pure` in front of func doesn't work well with
> inline closures.
>
> A few people talked through many of these issues starting with this tweet.
> https://twitter.com/griotspeak/status/832247545325842432
>
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  wrote:
>
> +1 for the idea of pure functions in swift.  Seems like it would enable a
> lot of good optimizations (in some cases even just evaluating the function
> at compile time).
>
> -1 on the specific notation.  I would much rather just put the word ‘pure’
> in front of ‘func’, the same way we put ‘mutating' in front of mutating
> functions… it seems to me like these are part of the same family.
>
> I agree we should allow inout.
>
> Thanks,
> Jon
>
> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> # Pure Functions
>
> * Proposal: [SE-](
> https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
> * Status: 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> Personally I feel enforced encapsulation of implementation detail to the 
>> latter group is less important than the former, and can be handled by 
>> convention. Whereas other users of your module definitely benefit from 
>> access control and being able to consume a clearly-defined interface.
> 
> I think failing to provide some sort of below-`internal` privacy would be 
> missing *really* low-hanging fruit for no good reason. The languages I can 
> think of which don't include some sort of sub-library-wide privacy 
> level—Objective-C, Javascript, Perl, Python—usually have very simple object 
> designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
> anything you'd like in a module.) Even Objective-C in practice includes a 
> `fileprivate` equivalent in the form of methods declared only in the .m file.
> 
> I also think it's often helpful to be able to change a member's access level 
> without having to change all references to it. Publishing or privatizing an 
> interface is not an uncommon refactoring.
> 
> Not everybody likes our current semantics, but that's no reason to throw the 
> feature out entirely.

+1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully we 
can reconsider using `scoped` as the keyword for scoped access rather than 
abandoning it.  Does anyone remember why this was considered a bad idea?

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

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 4:17 PM, Daniel Leping  wrote:
> 
> I don't think I can (fully) agree with you, because a closure purity is not 
> something you "define". It's rather what you use inside. Though I totally 
> understand your concern and a wish to have localized errors.
> 
> However, I think it's totally consistent if you use a full form in a way:
> 
> { (a) => B in
> return a.toB()
> }
> 
> What I mean is that short form can auto determine. If you want to be 
> explicit... use the long form.
> 
> Would this work for you, @Matthew?

What I am saying is that I don’t think I should have to use the entire long 
form just to specify it’s a pure closure.  Something like the following would 
be acceptable:

{= $0.some.pure.expression() }
or
{=> $0.some.pure.expression() }

But I don’t want to be required to write out a name for the arguments and a 
return type for single expression closures like this.

> 
> On Sat, 18 Feb 2017 at 0:09 Matthew Johnson  > wrote:
>> On Feb 17, 2017, at 4:05 PM, Daniel Leping > > wrote:
>> 
>> I personally like a lot => syntax for several reasons:
>> 1. Consistent
>> 2. Enforced return type
>> 
>> As for the closures, I don't think we need an indication here. If it calls 
>> any impure function or captures a variable from outside - it's impure by 
>> definition. The compiler should decide if a closure can be treated pure. 
>> Same as with throwing.
> 
> I’m not sure about this.  I would like the ability to syntactically state the 
> intent that a closure is pure, and ideally do so in a way that doesn’t lose 
> the conciseness of the closure (i.e. we shouldn’t have to give up any of the 
> syntactic sugar available for simple closures).  A big benefit of allowing us 
> to state intent like this is that it localizes error messages.
> 
>> 
>> As for the situation with currying (and other compositions), the situation 
>> is a lot more complicated than with rethrows. However, it's still deductible 
>> in compile time with the same mechanism as described above for closures.
>> 
>> I tend to agree we could use ~> (looks good to me... volatile :)) for the 
>> function type definitions as an "unknown purity". The return type purity 
>> dependence graph can be built automatically at compile time. With this graph 
>> compiler can determine the returned function purity in every place function 
>> is used.
>> 
>> The use of ~> should of course be limited to argument and return types of 
>> pure functions only. I think there might be a possibility of use in 
>> typealias, but need to think more about it.
>> 
>> On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> 
>>> Out of curiosity, what are the benefits to being able to define that a 
>>> closure must be pure as a parameter/type definition, as opposed to defining 
>>> a particular closure to being pure while being passed?  What guarantees 
>>> does it give you as the caller of the closure?
>> 
>> If you only accept pure closures and otherwise meet the criteria of a pure 
>> function then you are pure.  If you have a function like that and want to 
>> accept both pure and impure closures and receive the purity of the closure 
>> provided then we need syntax indicating something similar to `rethrows`, but 
>> for purity.
>> 
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Feb 16, 2017, at 1:18 PM, T.J. Usiyan > wrote:
 
 I am ok with a keyword but `pure` in front of func doesn't work well with 
 inline closures.
 
 A few people talked through many of these issues starting with this tweet. 
 https://twitter.com/griotspeak/status/832247545325842432 
 
 
 On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull > wrote:
 +1 for the idea of pure functions in swift.  Seems like it would enable a 
 lot of good optimizations (in some cases even just evaluating the function 
 at compile time).
 
 -1 on the specific notation.  I would much rather just put the word ‘pure’ 
 in front of ‘func’, the same way we put ‘mutating' in front of mutating 
 functions… it seems to me like these are part of the same family.
 
 I agree we should allow inout.
 
 Thanks,
 Jon
 
> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
> > wrote:
> 
> # Pure Functions
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Brent Royal-Gordon via swift-evolution]

> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Personally I feel enforced encapsulation of implementation detail to the 
> latter group is less important than the former, and can be handled by 
> convention. Whereas other users of your module definitely benefit from access 
> control and being able to consume a clearly-defined interface.

I think failing to provide some sort of below-`internal` privacy would be 
missing *really* low-hanging fruit for no good reason. The languages I can 
think of which don't include some sort of sub-library-wide privacy 
level—Objective-C, Javascript, Perl, Python—usually have very simple object 
designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap 
anything you'd like in a module.) Even Objective-C in practice includes a 
`fileprivate` equivalent in the form of methods declared only in the .m file.

I also think it's often helpful to be able to change a member's access level 
without having to change all references to it. Publishing or privatizing an 
interface is not an uncommon refactoring.

Not everybody likes our current semantics, but that's no reason to throw the 
feature out entirely.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Daniel Leping via swift-evolution]

I don't think I can (fully) agree with you, because a closure purity is not
something you "define". It's rather what you use inside. Though I totally
understand your concern and a wish to have localized errors.

However, I think it's totally consistent if you use a full form in a way:

{ (a) => B in
return a.toB()
}

What I mean is that short form can auto determine. If you want to be
explicit... use the long form.

Would this work for you, @Matthew?

On Sat, 18 Feb 2017 at 0:09 Matthew Johnson  wrote:

> On Feb 17, 2017, at 4:05 PM, Daniel Leping 
> wrote:
>
> I personally like a lot => syntax for several reasons:
> 1. Consistent
> 2. Enforced return type
>
> As for the closures, I don't think we need an indication here. If it calls
> any impure function or captures a variable from outside - it's impure by
> definition. The compiler should decide if a closure can be treated pure.
> Same as with throwing.
>
>
> I’m not sure about this.  I would like the ability to syntactically state
> the intent that a closure is pure, and ideally do so in a way that doesn’t
> lose the conciseness of the closure (i.e. we shouldn’t have to give up any
> of the syntactic sugar available for simple closures).  A big benefit of
> allowing us to state intent like this is that it localizes error messages.
>
>
> As for the situation with currying (and other compositions), the situation
> is a lot more complicated than with rethrows. However, it's still
> deductible in compile time with the same mechanism as described above for
> closures.
>
> I tend to agree we could use ~> (looks good to me... volatile :)) for the
> function type definitions as an "unknown purity". The return type purity
> dependence graph can be built automatically at compile time. With this
> graph compiler can determine the returned function purity in every place
> function is used.
>
> The use of ~> should of course be limited to argument and return types of
> pure functions only. I think there might be a possibility of use in
> typealias, but need to think more about it.
>
> On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Out of curiosity, what are the benefits to being able to define that a
> closure must be pure as a parameter/type definition, as opposed to defining
> a particular closure to being pure while being passed?  What guarantees
> does it give you as the caller of the closure?
>
>
> If you only accept pure closures and otherwise meet the criteria of a pure
> function then you are pure.  If you have a function like that and want to
> accept both pure and impure closures and receive the purity of the closure
> provided then we need syntax indicating something similar to `rethrows`,
> but for purity.
>
>
> Thanks,
> Jon
>
>
> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan  wrote:
>
> I am ok with a keyword but `pure` in front of func doesn't work well with
> inline closures.
>
> A few people talked through many of these issues starting with this tweet.
> https://twitter.com/griotspeak/status/832247545325842432
>
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  wrote:
>
> +1 for the idea of pure functions in swift.  Seems like it would enable a
> lot of good optimizations (in some cases even just evaluating the function
> at compile time).
>
> -1 on the specific notation.  I would much rather just put the word ‘pure’
> in front of ‘func’, the same way we put ‘mutating' in front of mutating
> functions… it seems to me like these are part of the same family.
>
> I agree we should allow inout.
>
> Thanks,
> Jon
>
> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> # Pure Functions
>
> * Proposal: [SE-](
> https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
> * Status: **Awaiting review**
> * Review manager: TBD
>
> ## Introduction
>
> Some functions are, essentially, only meant to be transformations of their
> input and–as such–do not and should not reference any variables other than
> those passed in. These same functions are not meant to have any effects
> other than the aforementioned transformation of input. Currently, Swift
> cannot assist the developer and confirm that any given function is one of
> these 'pure' functions. To facilitate this, this proposal adds syntax to
> signal that a function is 'pure'.
>
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
>
> ## Motivation
>
> Consider the following example where `_computeNullability(of:)` is meant
> to create its output solely based on the provided recognizer.
>

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Joanna Carter via swift-evolution]

> No, sorry, I don't agree with you.
> Current situation forces us to generate huge source files or write each 
> type in its own submodule/file. IMO it is very naturally to have a need to 
> protect access to some details *even* in the same file(please find David 
> Sweeris's answer in previous email in this thread. with current 'private' 
> he can *guarantee* that no code touches internal props even in the same 
> file), also many of us need a way to share some details only for 
> extensions/subtypes in other files in the same module/submodule even just 
> to organize code as *one* need/want and to express intention about who 
> should "touch" this code and get help from compiler when accidentally try 
> to use protected method/prop.
> 
> Someone, who want just internal/public can use only them in own code, no 
> problems. But many feels that they need a more detailed access levels to 
> structure their code, they find current situation not comfortable.

But I agree with you that there really is a need for better, what I would call, 
entity-based visibility.

In several other OO languages, this is not considered a problem and I fail to 
see why Swift should be any different, apart from the desire on some sides to 
make it different just for the sake of difference.

In a class hierarchy, I can declare stuff as private, knowing full well that 
nobody, but nobody, can "see" or touch that stuff outside of the declaring 
class. That is of paramount importance and central to the concept of 
information hiding.

In a class hierarchy, there is stuff that I want to hide from everybody and 
everything, except those classes that belong to the same hierarchy, which are 
allowed to have privileged access.

There are also times when I want to declare a base class that I am expecting 
users to derive from, especially an abstract class. I want a means of declaring 
that certain stuff can only be overridden by subclasses but, most definitely, 
not callable from any code outside of that hierarchy. For that, I express that 
intent by declaring such stuff as protected, thus preventing "unauthorised" use 
from outside the intended hierarchy.

And, it is in this respect, with the predominance of protocols and structs in 
Swift, that I want to express the same limitations of access to within any type 
(class, struct, enum) that implements a given protocol, or to within any 
extension to any type.

We are allowed to declare base functionality in an extension to a protocol, in 
much the same way as we would in an abstract class.

The difference between Swift protocols and abstract classes is that, with Swift 
protocols, I cannot, presently, limit access to "base" behaviour in the same 
way that I can in an abstract class. On the other hand, I cannot allow 
implementing types or extensions to access those base behaviours unless I put 
them in the same code file as the declaring protocol.

I am perfectly comfortable with the idea of module scope but fail to see the 
point of fileprivate scope, part from as a workaround to the lack of protected 
scope.

As you say, the purpose of scope/visibility is to inform and direct others of 
how your code is intended to be used. There are situations when internal scope 
is simply too great and private scope is too restricted ; as is fileprivate 
even (unless you don't mind bloated, monolithic files).

I believe that what you and I are not arguing for, is the introduction of what 
used to be called protected scope, as found only in classes ; in these days of 
protocols and structs, that would be too limiting and, by implication, more 
relevant to classes only.

Instead, for the wider gamut of types and increased focus on protocols instead 
of abstract classes, what is needed is the same kind of scope that will work 
with both class hierarchies and protocols and their extensions or 
implementations.

Thus, I would confirm that I would prefer to see a simple range of scopes :

1. private - only visible within the declaring type, including nested types.

2. extensible (formerly protected for classes) - visible within the declaring 
type plus : 
  a. for classes, visible in subclasses or extensions
  b. for protocols, structs and enums, visible in extensions to the declaring 
type

3. internal - visible within the declaring module

4. public - does what it says on the tin ; visible anywhere, both inside and 
outside the declaring module

5. removal of fileprivate as an excuse for not having extensible

I would also remind readers of the current peculiar situation with classes in 
Swift, where we have both final classes that totally prohibit derivation, but 
also a mishmash of scope and inheritance restriction with open and public.

Why is it that classes have both entity-based and module-based restriction on 
their derivation? What is wrong with just using final for those classes that we 
do not want to be derived from? I would rather see the extensible scope for 
"derivation" both inside and 

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 4:05 PM, Daniel Leping  wrote:
> 
> I personally like a lot => syntax for several reasons:
> 1. Consistent
> 2. Enforced return type
> 
> As for the closures, I don't think we need an indication here. If it calls 
> any impure function or captures a variable from outside - it's impure by 
> definition. The compiler should decide if a closure can be treated pure. Same 
> as with throwing.

I’m not sure about this.  I would like the ability to syntactically state the 
intent that a closure is pure, and ideally do so in a way that doesn’t lose the 
conciseness of the closure (i.e. we shouldn’t have to give up any of the 
syntactic sugar available for simple closures).  A big benefit of allowing us 
to state intent like this is that it localizes error messages.

> 
> As for the situation with currying (and other compositions), the situation is 
> a lot more complicated than with rethrows. However, it's still deductible in 
> compile time with the same mechanism as described above for closures.
> 
> I tend to agree we could use ~> (looks good to me... volatile :)) for the 
> function type definitions as an "unknown purity". The return type purity 
> dependence graph can be built automatically at compile time. With this graph 
> compiler can determine the returned function purity in every place function 
> is used.
> 
> The use of ~> should of course be limited to argument and return types of 
> pure functions only. I think there might be a possibility of use in 
> typealias, but need to think more about it.
> 
> On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution 
> > wrote:
>> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> Out of curiosity, what are the benefits to being able to define that a 
>> closure must be pure as a parameter/type definition, as opposed to defining 
>> a particular closure to being pure while being passed?  What guarantees does 
>> it give you as the caller of the closure?
> 
> If you only accept pure closures and otherwise meet the criteria of a pure 
> function then you are pure.  If you have a function like that and want to 
> accept both pure and impure closures and receive the purity of the closure 
> provided then we need syntax indicating something similar to `rethrows`, but 
> for purity.
> 
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan >> > wrote:
>>> 
>>> I am ok with a keyword but `pure` in front of func doesn't work well with 
>>> inline closures.
>>> 
>>> A few people talked through many of these issues starting with this tweet. 
>>> https://twitter.com/griotspeak/status/832247545325842432 
>>> 
>>> 
>>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull >> > wrote:
>>> +1 for the idea of pure functions in swift.  Seems like it would enable a 
>>> lot of good optimizations (in some cases even just evaluating the function 
>>> at compile time).
>>> 
>>> -1 on the specific notation.  I would much rather just put the word ‘pure’ 
>>> in front of ‘func’, the same way we put ‘mutating' in front of mutating 
>>> functions… it seems to me like these are part of the same family.
>>> 
>>> I agree we should allow inout.
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
 > wrote:
 
 # Pure Functions
 
 * Proposal: 
 [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
  
 )
 * Author(s): [TJ Usiyan](https://github.com/griotspeak 
 )
 * Status: **Awaiting review**
 * Review manager: TBD
 
 ## Introduction
 
 Some functions are, essentially, only meant to be transformations of their 
 input and–as such–do not and should not reference any variables other than 
 those passed in. These same functions are not meant to have any effects 
 other than the aforementioned transformation of input. Currently, Swift 
 cannot assist the developer and confirm that any given function is one of 
 these 'pure' functions. To facilitate this, this proposal adds syntax to 
 signal that a function is 'pure'.
 
 'pure', in this context, means:
 1. The function must have a return value
 1. This function can only call other pure functions
 1. This function cannot access/modify global or static variables.
 
 ## Motivation
 
 Consider the following example where `_computeNullability(of:)` is meant 
 to create its output solely based on the provided 

Re: [swift-evolution] [Pitch] Typed throws

[Daniel Leping via swift-evolution]

Here we go again... -1

On Fri, 17 Feb 2017 at 23:52 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 17, 2017, at 3:45 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I suggest we need to find a way to shorten the list of the possible error
> types with a the help of typeallias
>
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
>
> typealias MyErrors = MyError1 | MyError2 | MyError3
>
> func foo() throws(MyErrors) -> MyResult
> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
>
> Do you actually need that? Experience in other languages like Rust and
> Haskell that use Result-based error propagation suggests that a single
> error type is adequate, and beneficial in many ways. If nothing else, you
> could `Either` your way to multiple errors if you really needed to.
>
> IMO, if we accept a single error type per function, there could be a
> simpler model for this. We could say that the `throws` type is a generic
> parameter of all function types, and it defaults to the uninhabited `Never`
> type for functions that don't throw.
>
> () -> () == () throws Never -> ()
> () throws -> () == () throws Error -> ()
>
> In this model, you'd get many benefits:
>
> - `rethrows` could become first-class, reducing down to just polymorphic
> `throws`:
>
> func foo(_: () throws -> ()) rethrows // Swift 3
> func foo(_: () throws T -> ()) throws T // Swift X
> func foo(_: () throws T -> ()) throws Either
>
> - Protocols could abstract over error handling; for instance, we could
> support throwing sequences:
>
> protocol IteratorProtocol {
>   associatedtype Element
>   associatedtype Error: Swift.Error = Never
>
>   mutating func next() throws Error -> Element?
> }
>
> Separate of the type system model, the type *checking* model also deserves
> thorough consideration. Propagating the effects of possibly multiple error
> types propagating within a `do` block is much trickier than doing so as a
> single "throws" or not bit, especially if you want to be able to use type
> context in `catch` patterns or to implicitly propagate a narrower `throws`
> type out of the enclosing function.
>
>
> I agree with all of this. The correct way to handle functions that throw
> multiple error types is with a discriminated union (enum) or an
> existential.
>
> If we make enums easier to work with (see my manifesto on generalized
> enums and value subtyping), we also make it easier to address the use case
> of functions that need to throw several different error types.  That is the
> more general and useful way to address this use case.
>
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Daniel Leping via swift-evolution]

I personally like a lot => syntax for several reasons:
1. Consistent
2. Enforced return type

As for the closures, I don't think we need an indication here. If it calls
any impure function or captures a variable from outside - it's impure by
definition. The compiler should decide if a closure can be treated pure.
Same as with throwing.

As for the situation with currying (and other compositions), the situation
is a lot more complicated than with rethrows. However, it's still
deductible in compile time with the same mechanism as described above for
closures.

I tend to agree we could use ~> (looks good to me... volatile :)) for the
function type definitions as an "unknown purity". The return type purity
dependence graph can be built automatically at compile time. With this
graph compiler can determine the returned function purity in every place
function is used.

The use of ~> should of course be limited to argument and return types of
pure functions only. I think there might be a possibility of use in
typealias, but need to think more about it.

On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Out of curiosity, what are the benefits to being able to define that a
> closure must be pure as a parameter/type definition, as opposed to defining
> a particular closure to being pure while being passed?  What guarantees
> does it give you as the caller of the closure?
>
>
> If you only accept pure closures and otherwise meet the criteria of a pure
> function then you are pure.  If you have a function like that and want to
> accept both pure and impure closures and receive the purity of the closure
> provided then we need syntax indicating something similar to `rethrows`,
> but for purity.
>
>
> Thanks,
> Jon
>
>
> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan  wrote:
>
> I am ok with a keyword but `pure` in front of func doesn't work well with
> inline closures.
>
> A few people talked through many of these issues starting with this tweet.
> https://twitter.com/griotspeak/status/832247545325842432
>
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  wrote:
>
> +1 for the idea of pure functions in swift.  Seems like it would enable a
> lot of good optimizations (in some cases even just evaluating the function
> at compile time).
>
> -1 on the specific notation.  I would much rather just put the word ‘pure’
> in front of ‘func’, the same way we put ‘mutating' in front of mutating
> functions… it seems to me like these are part of the same family.
>
> I agree we should allow inout.
>
> Thanks,
> Jon
>
> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> # Pure Functions
>
> * Proposal: [SE-](
> https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
> * Status: **Awaiting review**
> * Review manager: TBD
>
> ## Introduction
>
> Some functions are, essentially, only meant to be transformations of their
> input and–as such–do not and should not reference any variables other than
> those passed in. These same functions are not meant to have any effects
> other than the aforementioned transformation of input. Currently, Swift
> cannot assist the developer and confirm that any given function is one of
> these 'pure' functions. To facilitate this, this proposal adds syntax to
> signal that a function is 'pure'.
>
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
>
> ## Motivation
>
> Consider the following example where `_computeNullability(of:)` is meant
> to create its output solely based on the provided recognizer.
>
> ```
> class Recognizer {
> var nullabilityMemo: Bool?
> var isNullable: Bool {
> func _computeNullability(of recognizer: Recognizer) -> Bool {…}
> if let back = nullabilityMemo {
> return back
> } else {
> let back =  _computeNullability(of: self)
> nullabilityMemo = back
> return back
> }
> }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real
> potential to accidentally reference `self` in its body and the mistake,
> depending on circumstance, can be terribly subtle. Converting
> `_computeNullability(of:)` to a `static` function is an option but
> obfuscates the fact that it is *only* to be called within `isNullable`.
>
>
> ## Proposed solution
>
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure'
> function, the developer gains assurance from the tooling that it doesn't
> reference anything or cause any side effects.
>
>
> ```
> class Recognizer {
> var nullabilityMemo: Bool?
> var isNullable: Bool {
> pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
> if let 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe 
wrote:

>
> On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu  wrote:
>
>> On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S  wrote:
>>
>>> On 17.02.2017 20:48, Xiaodi Wu wrote:
>>>
 What you are really asking for is a way of flexibly designating a "unit
 of
 code" within a module, for which the general solution is submodules. The
 objection is that, instead of tackling that issue, these are
 suggestions to
 invent ad-hoc units of code (scope + extensions only in the same file,
 scope + extensions only in the same module, class + extensions only in
 the
 same file + subclasses only in the same module), and it is possible to
 invent arbitrary many of these.

>>>
>>> No, sorry, I don't agree with you.
>>> Current situation forces us to generate huge source files or write each
>>> type in its own submodule/file. IMO it is very naturally to have a need to
>>> protect access to some details *even* in the same file(please find David
>>> Sweeris's answer in previous email in this thread. with current 'private'
>>> he can *guarantee* that no code touches internal props even in the same
>>> file), also many of us need a way to share some details only for
>>> extensions/subtypes in other files in the same module/submodule even just
>>> to organize code as *one* need/want and to express intention about who
>>> should "touch" this code and get help from compiler when accidentally try
>>> to use protected method/prop.
>>>
>>
>> I reject the premise that it is a goal of the Swift compiler to protect
>> you from yourself.
>>
>
> I should clarify, it should certainly protect you from unintentional
> accidents that you make, where those are foreseeable, etc. But here we're
> talking about _you_ invoking functions that _you_ wrote, which is a pretty
> darn clear demonstration of intentionality. And so what I mean to say is
> that the Swift compiler, IMO, has no real business trying to protect your
> intentions from your other intentions.
>
>
> With all due respect (and I do respect you as a person with quite an
> insight), why does Swift then (by default) check for (U)Int overflows,
> against nil values, etc, etc. These are all things that are quite
> protecting you from yourself. In a perfect world, you code your stuff in a
> way where you don't need these checks as you'd write code that would handle
> these scenarios. Oh wait, that's Objective-C...
>

Overflow, nil values, etc., all go to Swift's promising of memory safety by
default. They also reflect errors of omission: we unintentionally forget to
handle these cases. Here, a function call is an _intentional_ act. Writing
a function not meant to be called is an _intentional_ act. It is strange
that you would demand the compiler to stand between two of your own
intentional acts.


> In a similar sense, I believe the compiler/language should prevent you
> from accidently accessing members that are not designed to be accessed from
> out of certain scope.
>
> It's not just to protect _you_ from invoking something not being meant to
> invoke, but others as well.
>

Others that are part of the collective "you" working on the project, the
group of people who have permissions to touch the source code.


> Documentation is perfect only in a perfect world. I can't count how many
> times I've come to a project without a single line of comment, not to
> mention a comment indicating whether the member is meant to be called
> outside of the file, or if it's marked as internal due to current
> limitations in access control and it's simply because you needed to split
> the class amongst several files logic-wise to prevent a bloated single file.
>
> Documentation is not the answer.
>

If documentation is not the answer, then by that line of reasoning, neither
is access control. An author who can't be bothered to document that
something shouldn't be used won't be bothered to determine what an
appropriate access modifier would be, either. My point is that additional
access modifiers don't help you express yourself any more than
documentation does. Put another way, the access modifiers you advocate for
are simply an alternative spelling for a comment.


You can *guarantee* that nothing in the same file touches what it shouldn't
>> touch *by your own eyes*; `private` makes it "easier" but it is by no means
>> necessary. Indeed I argue that reading code should be the go-to way reason
>> about the behavior of code, and that compiler help is justified only when
>> such a method of reasoning is unusually hard or error-prone.
>>
>> Likewise, you can express intention by documentation. Indeed I argue that
>> reading the documentation should be the go-to way for a reader to learn how
>> to use unfamiliar code. Since a user will consult the documentation 

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 3:45 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>> I suggest we need to find a way to shorten the list of the possible error 
>> types with a the help of typeallias
>> 
>> extension MyError1: Error { ... }
>> extension MyError2: Error { ... }
>> extension MyError3: Error { ... }
>> 
>> typealias MyErrors = MyError1 | MyError2 | MyError3  
>> 
>> func foo() throws(MyErrors) -> MyResult
>> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> 
>> MyResult
> Do you actually need that? Experience in other languages like Rust and 
> Haskell that use Result-based error propagation suggests that a single error 
> type is adequate, and beneficial in many ways. If nothing else, you could 
> `Either` your way to multiple errors if you really needed to.
> 
> IMO, if we accept a single error type per function, there could be a simpler 
> model for this. We could say that the `throws` type is a generic parameter of 
> all function types, and it defaults to the uninhabited `Never` type for 
> functions that don't throw.
> 
> () -> () == () throws Never -> ()
> () throws -> () == () throws Error -> ()
> 
> In this model, you'd get many benefits:
> 
> - `rethrows` could become first-class, reducing down to just polymorphic 
> `throws`:
> 
> func foo(_: () throws -> ()) rethrows // Swift 3
> func foo(_: () throws T -> ()) throws T // Swift X
> func foo(_: () throws T -> ()) throws Either
> 
> - Protocols could abstract over error handling; for instance, we could 
> support throwing sequences:
> 
> protocol IteratorProtocol {
>   associatedtype Element
>   associatedtype Error: Swift.Error = Never
> 
>   mutating func next() throws Error -> Element?
> }
> 
> Separate of the type system model, the type *checking* model also deserves 
> thorough consideration. Propagating the effects of possibly multiple error 
> types propagating within a `do` block is much trickier than doing so as a 
> single "throws" or not bit, especially if you want to be able to use type 
> context in `catch` patterns or to implicitly propagate a narrower `throws` 
> type out of the enclosing function.

I agree with all of this. The correct way to handle functions that throw 
multiple error types is with a discriminated union (enum) or an existential.  

If we make enums easier to work with (see my manifesto on generalized enums and 
value subtyping), we also make it easier to address the use case of functions 
that need to throw several different error types.  That is the more general and 
useful way to address this use case.

> 
> -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] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

I meant to say “… more than one throwing error type …”



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 22:48:35, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

No actually not, it was made up by the assumption that the proposed syntax 
would have more than one throwing that which was clarified by others to be 
incorrect. ;)

Thanks again for clarification.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 22:45:35, Joe Groff (jgr...@apple.com) schrieb:


On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
 wrote:

I suggest we need to find a way to shorten the list of the possible error types 
with a the help of typeallias

extension MyError1: Error { ... }
extension MyError2: Error { ... }
extension MyError3: Error { ... }

typealias MyErrors = MyError1 | MyError2 | MyError3

func foo() throws(MyErrors) -> MyResult
func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
Do you actually need that? Experience in other languages like Rust and Haskell 
that use Result-based error propagation suggests that a single error type is 
adequate, and beneficial in many ways. If nothing else, you could `Either` your 
way to multiple errors if you really needed to.

IMO, if we accept a single error type per function, there could be a simpler 
model for this. We could say that the `throws` type is a generic parameter of 
all function types, and it defaults to the uninhabited `Never` type for 
functions that don't throw.

() -> () == () throws Never -> ()
() throws -> () == () throws Error -> ()

In this model, you'd get many benefits:

- `rethrows` could become first-class, reducing down to just polymorphic 
`throws`:

func foo(_: () throws -> ()) rethrows // Swift 3
func foo(_: () throws T -> ()) throws T // Swift X
func foo(_: () throws T -> ()) throws Either

- Protocols could abstract over error handling; for instance, we could support 
throwing sequences:

protocol IteratorProtocol {
  associatedtype Element
  associatedtype Error: Swift.Error = Never

  mutating func next() throws Error -> Element?
}

Separate of the type system model, the type *checking* model also deserves 
thorough consideration. Propagating the effects of possibly multiple error 
types propagating within a `do` block is much trickier than doing so as a 
single "throws" or not bit, especially if you want to be able to use type 
context in `catch` patterns or to implicitly propagate a narrower `throws` type 
out of the enclosing function.

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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

No actually not, it was made up by the assumption that the proposed syntax 
would have more than one throwing that which was clarified by others to be 
incorrect. ;)

Thanks again for clarification.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 22:45:35, Joe Groff (jgr...@apple.com) schrieb:


On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
 wrote:

I suggest we need to find a way to shorten the list of the possible error types 
with a the help of typeallias

extension MyError1: Error { ... }
extension MyError2: Error { ... }
extension MyError3: Error { ... }

typealias MyErrors = MyError1 | MyError2 | MyError3   

func foo() throws(MyErrors) -> MyResult
func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
Do you actually need that? Experience in other languages like Rust and Haskell 
that use Result-based error propagation suggests that a single error type is 
adequate, and beneficial in many ways. If nothing else, you could `Either` your 
way to multiple errors if you really needed to.

IMO, if we accept a single error type per function, there could be a simpler 
model for this. We could say that the `throws` type is a generic parameter of 
all function types, and it defaults to the uninhabited `Never` type for 
functions that don't throw.

() -> () == () throws Never -> ()
() throws -> () == () throws Error -> ()

In this model, you'd get many benefits:

- `rethrows` could become first-class, reducing down to just polymorphic 
`throws`:

func foo(_: () throws -> ()) rethrows // Swift 3
func foo(_: () throws T -> ()) throws T // Swift X
func foo(_: () throws T -> ()) throws Either

- Protocols could abstract over error handling; for instance, we could support 
throwing sequences:

protocol IteratorProtocol {
  associatedtype Element
  associatedtype Error: Swift.Error = Never

  mutating func next() throws Error -> Element?
}

Separate of the type system model, the type *checking* model also deserves 
thorough consideration. Propagating the effects of possibly multiple error 
types propagating within a `do` block is much trickier than doing so as a 
single "throws" or not bit, especially if you want to be able to use type 
context in `catch` patterns or to implicitly propagate a narrower `throws` type 
out of the enclosing function.

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

Re: [swift-evolution] [Pitch] Typed throws

[Joe Groff via swift-evolution]

> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I suggest we need to find a way to shorten the list of the possible error 
> types with a the help of typeallias
> 
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
> 
> typealias MyErrors = MyError1 | MyError2 | MyError3  
> 
> func foo() throws(MyErrors) -> MyResult
> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
Do you actually need that? Experience in other languages like Rust and Haskell 
that use Result-based error propagation suggests that a single error type is 
adequate, and beneficial in many ways. If nothing else, you could `Either` your 
way to multiple errors if you really needed to.

IMO, if we accept a single error type per function, there could be a simpler 
model for this. We could say that the `throws` type is a generic parameter of 
all function types, and it defaults to the uninhabited `Never` type for 
functions that don't throw.

() -> () == () throws Never -> ()
() throws -> () == () throws Error -> ()

In this model, you'd get many benefits:

- `rethrows` could become first-class, reducing down to just polymorphic 
`throws`:

func foo(_: () throws -> ()) rethrows // Swift 3
func foo(_: () throws T -> ()) throws T // Swift X
func foo(_: () throws T -> ()) throws Either

- Protocols could abstract over error handling; for instance, we could support 
throwing sequences:

protocol IteratorProtocol {
  associatedtype Element
  associatedtype Error: Swift.Error = Never

  mutating func next() throws Error -> Element?
}

Separate of the type system model, the type *checking* model also deserves 
thorough consideration. Propagating the effects of possibly multiple error 
types propagating within a `do` block is much trickier than doing so as a 
single "throws" or not bit, especially if you want to be able to use type 
context in `catch` patterns or to implicitly propagate a narrower `throws` type 
out of the enclosing function.

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

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

[Karl Wagner via swift-evolution]

  
Anybody from core-team able to weigh in: do we want to keep this rule of not 
allowing parametrised protocols (in which case nesting is "trivial" - capturing 
is not allowed, only one protocol exists, so it's just namespacing), or is this 
something which should be deferred?
  
  
  

  
If possible I would like to include protocols inside of generic types. I kind 
of like the non-parameterised version. It's elegant and allows you to write 
generic conformers to the protocol.
  
  

  
  
>   
> On Feb 7, 2017 at 4:10 pm,  mailto:matt...@anandabits.com)> 
>  wrote:
>   
>   
>   
>   
>   
> >   
> > On Feb 6, 2017, at 11:12 PM, Karl Wagner via swift-evolution  
> >   wrote:
> >   
> >   
> > 
> >
> >   
> >   
> > >   
> > > On 7 Feb 2017, at 06:05, Slava Pestov   > > (mailto:spes...@apple.com)>  wrote:
> > >   
> > >   
> > >   
> > > >   
> > > >
> > > >  On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution  
> > > >   wrote:  
> > > >  
> > > >   
> > > >   
> > > >  - Nested protocols in generic types are not parameterised by the 
> > > > parent's generic parameters.  
> > > >
> > > >   
> > > >   
> > >   
> > > So if I write GenericType.SomeProto and 
> > > GenericType.SomeProto, is it the same protocol? What about 
> > > GenericType.SomeProto, is that allowed?
> > >   
> > >
> > >   
> > > Slava
> > >   
> > >   
> >   
> >   
> >   
> > GenericType.SomeProto (without parameters) is the only spelling that is 
> > allowed. There is no GenericType.SomeProto.
> >   
> >
> >   
> > That way we avoid every bound-generic type creating a new protocol.   
> >   
> >   
> >   
>   
>
>   
> I have only had a chance to scan the proposal so I will probably have more 
> comments after I take a closer look, but I want to respond to this topic 
> right away.
>   
>
>   
> I understand the reason why you want it to work this way, but think it will 
> be a significant source of confusion.Protocols will behave differently 
> than any other entity nested in a generic type.This means the protocols 
> nested in generic types will likely be counterintuitive for most people.
>   
>
>   
> I know this was the case for me while I was scanning the proposal.I had 
> to think carefully to understand how you want this to work and why you want 
> this behavior.That is despite it being a relatively direct consequence of 
> the Swift’s design for protocols, which uses associated types and 
> intentionally does not allow generic protocols.
>   
>
>   
> It may be that there isn’t a good way to avoid that and we need to try to 
> address it through documentation and education.But I think this should 
> receive careful consideration before we commit to this direction.
>   
>
>   
> Overall the proposal looks really great!I’m really looking forward to 
> this feature.
>   
>   
> >   
> >   
> >   
> > I think it works really nicely when you consider what it would like like 
> > with existential-based capturing. Notice that there is only one 
> > ‘MyCollectionView.Source’, and compatibility is determined based on 
> > existential constraints.
> >   
> >
> >   
> > - Karl
> >   
> >
> >   
> >
> >   
> >   
> >   class   MyCollectionView  :  UICollectionView  {  protocol   
> > Source  {  //  [implicit] associatedtype MediaItem func   item(at:  
> > Int)  ->  MediaItem  var  numberOfItems:   Int  {  get  } }  var  source:   
> > Any   //  Not 
> > possible today.   }  class   BookSource:  MyCollectionView.Source  {  
> > typealias   MediaItem   =  Book  func   item(at:  Int)  ->  Book {  /*  ... 
> >  */  }  var  numberOfItems:   Int  {  /*  ...  */  } }  class   
> > DummySource:  MyCollectionView.Source  where  MediaItem:   
> > DummyConstructable  {  //  associatedtype 'MediaItem' bound to generic 
> > parameter. func   item(at:  Int)  ->  MediaItem {  /*  ...  */  }  var  
> > numberOfItems:   Int  {  /*  ...  */  } } MyCollectionView().source   
> > =   BookSource() MyCollectionView().source   =  DummySource() 
> > MyCollectionView().source   =   DummySource()  //  type is: 
> > DummySource   MyCollectionView().source   =   DummySource()  
> > //  type is: DummySource   
> >   
> >
> > 
> >
> >   
> >
> >___
> >  swift-evolution mailing list
> >   swift-evolution@swift.org (mailto:swift-evolution@swift.org)
> >  https://lists.swift.org/mailman/listinfo  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Out of curiosity, what are the benefits to being able to define that a 
> closure must be pure as a parameter/type definition, as opposed to defining a 
> particular closure to being pure while being passed?  What guarantees does it 
> give you as the caller of the closure?

If you only accept pure closures and otherwise meet the criteria of a pure 
function then you are pure.  If you have a function like that and want to 
accept both pure and impure closures and receive the purity of the closure 
provided then we need syntax indicating something similar to `rethrows`, but 
for purity.

> 
> Thanks,
> Jon
> 
> 
>> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan > > wrote:
>> 
>> I am ok with a keyword but `pure` in front of func doesn't work well with 
>> inline closures.
>> 
>> A few people talked through many of these issues starting with this tweet. 
>> https://twitter.com/griotspeak/status/832247545325842432 
>> 
>> 
>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull > > wrote:
>> +1 for the idea of pure functions in swift.  Seems like it would enable a 
>> lot of good optimizations (in some cases even just evaluating the function 
>> at compile time).
>> 
>> -1 on the specific notation.  I would much rather just put the word ‘pure’ 
>> in front of ‘func’, the same way we put ‘mutating' in front of mutating 
>> functions… it seems to me like these are part of the same family.
>> 
>> I agree we should allow inout.
>> 
>> Thanks,
>> Jon
>> 
>>> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
>>> > wrote:
>>> 
>>> # Pure Functions
>>> 
>>> * Proposal: 
>>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>>>  
>>> )
>>> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
>>> )
>>> * Status: **Awaiting review**
>>> * Review manager: TBD
>>> 
>>> ## Introduction
>>> 
>>> Some functions are, essentially, only meant to be transformations of their 
>>> input and–as such–do not and should not reference any variables other than 
>>> those passed in. These same functions are not meant to have any effects 
>>> other than the aforementioned transformation of input. Currently, Swift 
>>> cannot assist the developer and confirm that any given function is one of 
>>> these 'pure' functions. To facilitate this, this proposal adds syntax to 
>>> signal that a function is 'pure'.
>>> 
>>> 'pure', in this context, means:
>>> 1. The function must have a return value
>>> 1. This function can only call other pure functions
>>> 1. This function cannot access/modify global or static variables.
>>> 
>>> ## Motivation
>>> 
>>> Consider the following example where `_computeNullability(of:)` is meant to 
>>> create its output solely based on the provided recognizer.
>>> 
>>> ```
>>> class Recognizer {
>>> var nullabilityMemo: Bool?
>>> var isNullable: Bool {
>>> func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>> if let back = nullabilityMemo {
>>> return back 
>>> } else {
>>> let back =  _computeNullability(of: self)
>>> nullabilityMemo = back
>>> return back
>>> }
>>> }
>>> }
>>> ```
>>> if `_computeNullability(of:)` is recursive at all, there exists a real 
>>> potential to accidentally reference `self` in its body and the mistake, 
>>> depending on circumstance, can be terribly subtle. Converting 
>>> `_computeNullability(of:)` to a `static` function is an option but 
>>> obfuscates the fact that it is *only* to be called within `isNullable`.
>>> 
>>> 
>>> ## Proposed solution
>>> 
>>> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
>>> function, the developer gains assurance from the tooling that it doesn't 
>>> reference anything or cause any side effects.
>>> 
>>> 
>>> ```
>>> class Recognizer {
>>> var nullabilityMemo: Bool?
>>> var isNullable: Bool {
>>> pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>> if let back = nullabilityMemo {
>>> return back 
>>> } else {
>>> let back =  _computeNullability(of: self)
>>> nullabilityMemo = back
>>> return back
>>> }
>>> }
>>> }
>>> ```
>>> 
>>> ## Detailed design
>>> 
>>> This proposal introduces a new annotation `=>`, which is to be accepted 
>>> everywhere `->` currently is. Members created using this kewyord must 
>>> follow the rules listed in the 

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Jonathan Hull via swift-evolution]

Out of curiosity, what are the benefits to being able to define that a closure 
must be pure as a parameter/type definition, as opposed to defining a 
particular closure to being pure while being passed?  What guarantees does it 
give you as the caller of the closure?

Thanks,
Jon


> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan  wrote:
> 
> I am ok with a keyword but `pure` in front of func doesn't work well with 
> inline closures.
> 
> A few people talked through many of these issues starting with this tweet. 
> https://twitter.com/griotspeak/status/832247545325842432 
> 
> 
> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  > wrote:
> +1 for the idea of pure functions in swift.  Seems like it would enable a lot 
> of good optimizations (in some cases even just evaluating the function at 
> compile time).
> 
> -1 on the specific notation.  I would much rather just put the word ‘pure’ in 
> front of ‘func’, the same way we put ‘mutating' in front of mutating 
> functions… it seems to me like these are part of the same family.
> 
> I agree we should allow inout.
> 
> Thanks,
> Jon
> 
>> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> # Pure Functions
>> 
>> * Proposal: 
>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>>  
>> )
>> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
>> )
>> * Status: **Awaiting review**
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> Some functions are, essentially, only meant to be transformations of their 
>> input and–as such–do not and should not reference any variables other than 
>> those passed in. These same functions are not meant to have any effects 
>> other than the aforementioned transformation of input. Currently, Swift 
>> cannot assist the developer and confirm that any given function is one of 
>> these 'pure' functions. To facilitate this, this proposal adds syntax to 
>> signal that a function is 'pure'.
>> 
>> 'pure', in this context, means:
>> 1. The function must have a return value
>> 1. This function can only call other pure functions
>> 1. This function cannot access/modify global or static variables.
>> 
>> ## Motivation
>> 
>> Consider the following example where `_computeNullability(of:)` is meant to 
>> create its output solely based on the provided recognizer.
>> 
>> ```
>> class Recognizer {
>>  var nullabilityMemo: Bool?
>>  var isNullable: Bool {
>>  func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>  if let back = nullabilityMemo {
>>  return back 
>>  } else {
>>  let back =  _computeNullability(of: self)
>>  nullabilityMemo = back
>>  return back
>>  }
>>  }
>> }
>> ```
>> if `_computeNullability(of:)` is recursive at all, there exists a real 
>> potential to accidentally reference `self` in its body and the mistake, 
>> depending on circumstance, can be terribly subtle. Converting 
>> `_computeNullability(of:)` to a `static` function is an option but 
>> obfuscates the fact that it is *only* to be called within `isNullable`.
>> 
>> 
>> ## Proposed solution
>> 
>> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
>> function, the developer gains assurance from the tooling that it doesn't 
>> reference anything or cause any side effects.
>> 
>> 
>> ```
>> class Recognizer {
>>  var nullabilityMemo: Bool?
>>  var isNullable: Bool {
>>  pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>  if let back = nullabilityMemo {
>>  return back 
>>  } else {
>>  let back =  _computeNullability(of: self)
>>  nullabilityMemo = back
>>  return back
>>  }
>>  }
>> }
>> ```
>> 
>> ## Detailed design
>> 
>> This proposal introduces a new annotation `=>`, which is to be accepted 
>> everywhere `->` currently is. Members created using this kewyord must follow 
>> the rules listed in the introduction.
>> 
>> ## Impact on existing code
>> 
>> This is an additive feature unless alternative 2 is chosen and, as such, 
>> should not require an effect on existing code. It could be used to annotate 
>> closures accepted by methods in the standard library such as `map`, 
>> `filter`, and `reduce`. While this would fit well with their typical use, 
>> such a change is not necessarily part of this proposal.
>> 
>> ## Alternatives considered
>> 
>> It should be noted that neither of these alternatives can remain consistent 
>> for inline closures.
>> 

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

[Jose Cheyo Jimenez via swift-evolution]

Hi Ted, 

Today I learned about https://esdiscuss.org/  which is 
like an archiver viewer for disc...@mozilla.org pipermail mailing list 

All their code is at  https://github.com/esdiscuss 


This still preserves pipermail as the one source of truth but it allows better 
searching and visibility.

There is even a reply button which opens up a mail client presumably the 
correct headers. 

Thanks!


> On Feb 9, 2017, at 5:18 PM, Ted Kremenek via swift-users 
>  wrote:
> 
>> 
>> On Feb 9, 2017, at 4:09 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Feb 9, 2017, at 6:04 PM, Ted Kremenek >> > wrote:
>>> 
>>> 
 On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
 > wrote:
 
> I’ve been mostly silent in this conversation largely because I didn’t 
> realize it was leading up to a formal decision.  I wish it would have 
> followed the proposal process so it was clear to everyone that a decision 
> was being considered and this was our chance to offer input.  
 
 FWIW, I am not ignoring this thread.  At some point there was diminishing 
 signal on the thread, and it felt like the category of opinions that had 
 been voiced had been vocalized on the thread.  Looping in swift-users into 
 that thread would have been a good thing to do in hindsight so more people 
 felt like they had a chance to participate.  Based on what I am seeing in 
 reaction to this decision, however, I’m not seeing much new signal.
>>> 
>>> Just to add to this point — new insights on this topic are welcome, and 
>>> will be paid attention to.  The decision to change to a forum is because 
>>> that was evaluated as being the best thing for the community, based on the 
>>> range of opinions provided and the tradeoffs made.  If there is something 
>>> important that was missed, obviously that is not going to be ignored.  We 
>>> want to do the right thing.  So far I still feel that moving to a forum 
>>> software is the right choice, but I’d like to do that in a way that allows 
>>> people to still participate effectively via email.
>> 
>> Is there any way to have a trial run so we can evaluate the email experience 
>> of using the forum software before we make the final switch?  I agree that 
>> this sounds like the right direction, but it’s hard to know what the email 
>> experience will really be like until we give it a try for a week or so.
> 
> I need to formalize a plan, but yes I’d like to trial this somehow.  Nate 
> Cook created a staged installation of Discourse when the thread on 
> swift-evolution was happening and there was some useful telemetry out of that 
> experiment (such as how rich text email interacted with doing inline 
> replies).  Moving to Discourse (or some alternate forum software if we decide 
> Discourse is not a fit) would be a staged thing.  The main question to me is 
> how do we do a meaningful trial without actually doing the real discussions 
> in the forum (while the mailing lists are still running).
> ___
> swift-users mailing list
> swift-us...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Jeff Kelley via swift-evolution]

Hi Charles,

If Swift code were to send NSNotFound to a method that took a nullable
NSArrayIndex, under this example, one of two things could happen:

1.) The Swift compiler fails with a fix-it to use nil instead.
2.) The value is passed as-is and Objective-C handles it as usual.

My preference would be for 1, as then the fix-its can help update code to
use the new syntax, but my opinion can definitely be swayed.


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  |
jeffkelley.org

On Fri, Feb 17, 2017 at 3:24 PM, Charles Srstka 
wrote:

> On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Hi all,
>
> I don’t have a formal proposal written up yet, but in my continued quest
> to make better-annotated Objective-C code, I had an idea for bridging nil with
> primitives. Since in Objective-C we often use constant values to represent
> invalid values or nil, the most obvious being NSNotFound, could we use
> that as a shorthand for nil? Something like this for NSArray:
>
> - (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;
>
> This is a little verbose, so it could also work with a typedef:
>
> typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
> - (NSArrayIndex)indexOfObject:(ObjectType)anObject;
>
> This would change the existing Swift interface to return an Int? instead
> of an Int. I see this as working both ways—converting these values to nil when
> returning from Objective-C to Swift, and sending these values instead of
> nil when Swift calls into Objective-C code.
>
> Is this worth writing up a proposal for? Is another, better method already
> in someone’s mind?
>
>
> What happens if code on the Swift side sets the property’s value to the
> sentinel?
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Anton Zhilin via swift-evolution]

Several proposals will follow this one: allowing multiple error types,
removing Error, replacing rethrows, etc.
Those topics are more controversial, but fortunately for them, they mostly
add on top of the core feature being discussed.
So IMO, if a detail can be split into its own proposal, we should just do
it and forget about it for a little while.

2017-02-17 23:16 GMT+03:00 Tino Heth <2...@gmx.de>:


> I thought it was going to be any one subtype of Error, be it a struct, an
> enum, or a protocol existential, or Error itself.
>
>
> Imho we should remove the restriction that you can only throw
> Error-conforming types if typed throws are added:
> It's a compatibility feature, and if you manually declare what can be
> thrown, you should be allowed to break with Objective-C.
>
> As Error has no requirements at all, it looks like harassment, as its
> whole magic is neither visible nor necessary.
>
> ​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Charles Srstka via swift-evolution]

> On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> Hi all,
> 
>   I don’t have a formal proposal written up yet, but in my continued 
> quest to make better-annotated Objective-C code, I had an idea for bridging 
> nil with primitives. Since in Objective-C we often use constant values to 
> represent invalid values or nil, the most obvious being NSNotFound, could we 
> use that as a shorthand for nil? Something like this for NSArray:
> 
> - (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;
> 
>   This is a little verbose, so it could also work with a typedef:
> 
> typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
> - (NSArrayIndex)indexOfObject:(ObjectType)anObject;
> 
>   This would change the existing Swift interface to return an Int? 
> instead of an Int. I see this as working both ways—converting these values to 
> nil when returning from Objective-C to Swift, and sending these values 
> instead of nil when Swift calls into Objective-C code.
> 
>   Is this worth writing up a proposal for? Is another, better method 
> already in someone’s mind?

What happens if code on the Swift side sets the property’s value to the 
sentinel?

Charles

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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

Wouldn’t that mean that you couldn’t use your Swift library in Objective-C 
anymore, at least the error type as an NSError?



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 21:16:57, Tino Heth (2...@gmx.de) schrieb:


I thought it was going to be any one subtype of Error, be it a struct, an enum, 
or a protocol existential, or Error itself.

Imho we should remove the restriction that you can only throw Error-conforming 
types if typed throws are added:
It's a compatibility feature, and if you manually declare what can be thrown, 
you should be allowed to break with Objective-C.

As Error has no requirements at all, it looks like harassment, as its whole 
magic is neither visible nor necessary.

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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

I disagree with that, it works if you only have a single function parameter 
type that throws an error, but if there are more than one inferring the type 
won’t be possible anymore: func foo(_: () throws(T) -> Void, _: () throws(S) -> 
Void) rethrows(S) (here, we’re assuming that T is handled inside foo).



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 21:17:42, Kevin Nattinger (sw...@nattinger.net) schrieb:


On Feb 17, 2017, at 11:50 AM, Adrian Zubarev via swift-evolution 
 wrote:

Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from the 
given context of the first post by Anton. :) Just forget everything I mentioned 
about typealias, because it was based on the assumption of an error list.

Anyways +1 for typed throws. The syntax throws(T) and rethrows(T) is fine by me.

I feel like  rethrows can and should be inferred. It’s just a pass-through.




-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:45:55, Matthew Johnson (matt...@anandabits.com) 
schrieb:


On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution 
 wrote:

So the typed throws are going to be limited to a single error type, is that the 
direction we're heading to?

Yes, this topic was discussed thoroughly last year.


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

In this case, you’d better create a new error type, which includes all the 
cases of those errors:

// FileNotFoundError and WrongFormat are Error-s

struct PreferencesError : Error {
init(_: FileNotFoundError)
init(_: WrongFormat)
// ...
}

func readPreferences() throws(PreferencesError)
In the most “lazy” case, you’d just create an enum of those two:

enum PreferencesError : Error {
case fileNotFound(FileNotFoundError)
case wrongFormat(WrongFormatError)
}
Better yet, you should analyze, which cases are meaningful for user of 
readPreferences, and present them with appropriate interface. You may want to 
crash on those cases of initial error types, with which you can’t do anything 
on the level of abstraction of readPreferences. Some of the others will be 
merged or renamed.

With proper error types, a single type in throws clause is enough, without sum 
types.

2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution 
:


Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.


___
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] [Pitch] Bridging nil to Objective-C Primitives

[Alejandro Martinez via swift-evolution]

I would really like to see a nicer way of having Int? Exported to objc. Right 
now it kind of forces to use NSNumber which may be fine in the objc side but 
makes swift uglier, unless you want to write that code in a wrapper which 
doesn't scale really well 

Sent from my iPad

> On 15 Feb 2017, at 09:51, Pranshu Goyal via swift-evolution 
>  wrote:
> 
> +1
> 
>> On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution 
>>  wrote:
>> I would love to see this - and the sooner the better :)
>> 
>> I think that the fact that Swift makes a type-level distinction between 
>> optional and non-optional makes it easier to trip yourself up when you work 
>> with Cocoa APIs that use pseudo-optionality, compared to when you work with 
>> ObjC. In ObjC you are aware 100% of the time that optionality is always 
>> represented in some way or another and that you have to expected 
>> inconsistency in the representation of optionality. So you keep this in mind 
>> and look out for it. But in Swift it’s easy to slide into the assumption 
>> that all APIs which return something that’s technically optional do indeed 
>> represent this as an optional type rather than some special integer value, 
>> float value or singleton object.
>> 
>> 
>> Regards,
>> 
>> Dietmar Planitzer
>> 
>> > On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution 
>> >  wrote:
>> >
>> > The feature in this case I would claim is independent of the adopters. 
>> > Personally I think this would be a useful feature to allow for better 
>> > exposition into swift but also more robust objective-c APIs.
>> >
>> > Something to consider here is that not all NSUIntegers can be NSNotFound, 
>> > sometimes the return value is 0. It would be interesting to consider that 
>> > _Nullable would be parameterized via a constant expression. This is a 
>> > straw man refinement here (the exact spelling would be something we would 
>> > have to audit the way it is implemented and likely use macros to compose 
>> > the right nullability concepts)
>> >
>> > Lets take for example this API:
>> >
>> > + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream 
>> > format:(NSPropertyListFormat)format 
>> > options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
>> >
>> > The return value here would be 0 if an error occurs. So the nullability 
>> > value would be 0.
>> >
>> > + (nullable(0) NSInteger)writePropertyList:(id)plist 
>> > toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format 
>> > options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
>> >
>> > But other APIs like you indicated:
>> >
>> > - (NSUInteger)indexOfObject:(ObjectType)anObject;
>> >
>> > Could be converted to:
>> >
>> > - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
>> >
>> > Which would immediately be an indication to the reader what the “null” 
>> > value would be represented as. Of course your concept of type aliases 
>> > might be a decent way to group concepts together but if lets say there was 
>> > an index type for NSArray; obviously you might want a index return value 
>> > to be nullable but it would be a bit confusing to take a nullable 
>> > parameter into certain APIs.
>> >
>> > Given a concept of NSArrayIndex as you suggested (that being nullable) 
>> > would have the problem that
>> >
>> > - (ObjectType)objectAtIndex:(NSUInteger)index;
>> >
>> > Would either incorrectly indicate it would be nullable or it would have a 
>> > different type.
>> >
>> > There would be other cases where structural types might need a nullable 
>> > placeholder value, e.g. NSRange with a location of NSNotFound and a length 
>> > of 0 (however that strictly isn’t correct since it is just the location 
>> > that indicates null-ness.. but that is probably more of an implementation 
>> > detail and should probably be corrected imho).
>> >
>> > There could also be cases where an API returns either an object of a 
>> > specific type or NSNull as a placeholder. This would be nice to be able to 
>> > express as a nullable type especially in generics. For example: 
>> > `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express 
>> > `Array` which cannot be expressed currently.
>> >
>> > Overall I think this could really reduce some of the overlays for all the 
>> > frameworks on Mac OS X and iOS, improve the expressivity of Objective-C 
>> > APIs, offer more accurate bridged representations, and generally give API 
>> > authors an opportunity to more correctly represent what should be exposed 
>> > in Swift without needing to write overlays that could easily have poor 
>> > interaction with things like subclassing or delegation.
>> >
>> > As a side note: I am not certain if the parameterization of nullability 
>> > annotations would even be possible in the current compiler implementations 
>> > or if it would be easier to 

Re: [swift-evolution] [Pitch] Typed throws

[Kevin Nattinger via swift-evolution]

> On Feb 17, 2017, at 11:50 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from 
> the given context of the first post by Anton. :) Just forget everything I 
> mentioned about typealias, because it was based on the assumption of an error 
> list.
> 
> Anyways +1 for typed throws. The syntax throws(T) and rethrows(T) is fine by 
> me.
> 
I feel like rethrows can and should be inferred. It’s just a pass-through.

> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Februar 2017 um 20:45:55, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> 
>>> On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> So the typed throws are going to be limited to a single error type, is that 
>>> the direction we're heading to?
>> 
>> Yes, this topic was discussed thoroughly last year.
>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com 
>>> ) schrieb:
>>> 
 In this case, you’d better create a new error type, which includes all the 
 cases of those errors:
 
 // FileNotFoundError and WrongFormat are Error-s
 
 struct PreferencesError : Error {
 init(_: FileNotFoundError)
 init(_: WrongFormat)
 // ...
 }
 
 func readPreferences() throws(PreferencesError)
 In the most “lazy” case, you’d just create an enum of those two:
 
 enum PreferencesError : Error {
 case fileNotFound(FileNotFoundError)
 case wrongFormat(WrongFormatError)
 }
 Better yet, you should analyze, which cases are meaningful for user of 
 readPreferences, and present them with appropriate interface. You may want 
 to crash on those cases of initial error types, with which you can’t do 
 anything on the level of abstraction of readPreferences. Some of the 
 others will be merged or renamed.
 
 With proper error types, a single type in throws clause is enough, without 
 sum types.
 
 2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution 
 >:
 
 
 Sure thing, but that’s not what I was asking about. Kevin made a protocol 
 that conforms to Error where all the his enums conformed to MyError 
 protocol. That way we’re losing all enum cases and are not really a step 
 further as before.
 
 
>>> ___
>>> 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] [Pitch] Typed throws

[Tino Heth via swift-evolution]

> I thought it was going to be any one subtype of Error, be it a struct, an 
> enum, or a protocol existential, or Error itself.

Imho we should remove the restriction that you can only throw Error-conforming 
types if typed throws are added:
It's a compatibility feature, and if you manually declare what can be thrown, 
you should be allowed to break with Objective-C.

As Error has no requirements at all, it looks like harassment, as its whole 
magic is neither visible nor necessary.

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

Re: [swift-evolution] [Manifesto] Ownership

[John McCall via swift-evolution]

> On Feb 17, 2017, at 2:51 PM, Xiaodi Wu  wrote:
> What a read! Two questions off the bat:
> 
> 1. Any preliminary estimates as to what the performance cost of dynamic 
> enforcement is shaping up to be, at least in an initial implementation? It'd 
> have a direct impact on how "opt-in" the additional tools really are.

We don't have an initial implementation yet, sorry.  I'm sure it'll vary a lot 
by the application.  My hope is that it'll just be a few extra non-atomic loads 
and stores around every access, but it's possible that we'll need to make at 
least one of those an atomic exchange because it's legal for multiple threads 
to read concurrently.  It hinges in part on how comfortable we are with 
allowing conflicts to escape dynamic detection in complex concurrent cases.
 
> 2. Without the intention of initiating premature bikeshedding, what was the 
> thought behind proposing `inout foo = ...` vs the seemingly more obvious `var 
> foo: inout = ...`, given that `inout` was moved to the type side of the colon?

Well, I think it's pretty semantically different from a var.  It's also really 
tempting to read the latter as "a var of inout type", suggesting that a 
re-assignment would bind it to different storage, which is not how it works, 
should work, or even could work.

John.

> 
> 
> On Fri, Feb 17, 2017 at 11:11 AM, John McCall via swift-evolution 
> > wrote:
>> On Feb 17, 2017, at 12:08 PM, John McCall > > wrote:
>>> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev 
>>> > 
>>> wrote:
>>> Hi John, would you mind creating a markdown document for this manifesto in 
>>> https://github.com/apple/swift/tree/master/docs 
>>> ? :)
>>> 
>>> 
>> Yes, it should go in the repository.  That commit is pending, but the in 
>> meantime, you can see the document properly rendered at:
>>   
>> https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md
>>  
>> 
> Ah, and of course the second I send this, my PR gets merged. :)
> 
> The new URL is:
>   https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md 
> 
> 
> John.
> 
> ___
> 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] final + lazy + fileprivate modifiers

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 11:25 AM, Vladimir.S  wrote:
> 
> On 17.02.2017 20:16, David Sweeris via swift-evolution wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>>> On Feb 17, 2017, at 01:02, Rien  wrote:
>>> 
>>> 
 On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution
  wrote:
 
 
> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution
>  wrote:
> 
> While we’re bikeshedding, I’m going to add my two cents. Hold on
> to your hat because this might be controversial here.
> 
> I think both ‘private’ and ‘fileprivate’ are unnecessary
> complications that only serve to clutter the language.
> 
> It would make a lot more sense to just have internal and public
> only. No private, no fileprivate, no lineprivate, no protected.
> It’s all silly.
 
 Eh, I've used `private` to keep myself honest in terms of going
 through some book-keeping functions instead of directly accessing a
 property.
>>> 
>>> But is that not an argument to get rid of ‘private’ & ‘fileprivate’?
>>> 
>>> With great power there comes great responsibility ;-)
>> 
>> I don't see how... I used `private` on some dicts that interact with
>> each other (faking a lightweight database) to ensure I was using my
>> type's subscript functions (which handle updating all the dicts
>> correctly) instead of directly accessing the dictionaries in some areas
>> where the interactions theoretically wouldn't matter. Since I was able
>> to mark those properties as private, I know that all the access to those
>> properties goes through the proper book-keeping functions. Not only does
>> this reduce the opportunity for bugs, it makes it far simpler to change
>> the implementation later if I decide it should be backed by a "proper"
>> database since everything that directly touches the storage will be
>> right there in the type definition instead of spread through however
>> many extensions across however many files.
>> 
> 
> David, I assume personally you see a benefits of 'private' as it is currently 
> and don't support extending its scope to "type and subtypes and extensions in 
> the same module"? My suggestion was to extend it…

I wouldn’t mind something synonymous with C++’s “friend”, although I don’t 
really have an opinion on the spelling. Right now, I use “fileprivate” to kinda 
fake it by putting everything that needs access to property/function in 
question in the same file. That approach doesn’t really scale well (or at all, 
if you want to publish a class that you intend your clients to subclass), but 
so far the codebase I’m using it in is small enough that’s just an annoyance 
rather than an actual issue.

> Personally I'd like to have a way to say all of this as access scope(in 
> addition to current public/internal/fileprivate):
> 1. type only
> 2. type and subtypes in the same module
> 3. type and subtypes and extensions in the same module
> 4. file and subtypes in the same module
> 5. file and subtypes and extensions in the same module
> 
> Probably we could have just (3) without (2), and (5) without (4), need to 
> discuss if it is important to be able to provide access to subtype but not 
> for extensions.
> 
> So, it seems for me like we need to return 'public' keyword where it was in 
> Swift2(so to have public/internal/private "file"-based scope), and introduce 
> well-designed scope access levels with own keywords.
> 
> For example, if we really need just (3) and just (5) (without 2 and 4):
> typeprivate - type only
> typeprotected - type and subtypes and extensions in the same module
> typeinternal - file and subtypes and extensions in the same module
> 
> Opinions?

Personally, I’d prefer “access(option)” over “optionaccess”, but I’m more 
interested in getting agreement on the functionality than how it’s spelled. My 
only strong feeling on the matter of spelling is that it should be clear and 
consistent… “davesCrutch”, while arguably accurate, would be a horrible name 
because its meaning is so unclear, and even though it’d be my preferred 
spelling, I would be opposed to adding “private(type)” unless we also replace 
“fileprivate” with “private(file)”.

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

Re: [swift-evolution] [Manifesto] Ownership

[Xiaodi Wu via swift-evolution]

What a read! Two questions off the bat:

1. Any preliminary estimates as to what the performance cost of dynamic
enforcement is shaping up to be, at least in an initial implementation?
It'd have a direct impact on how "opt-in" the additional tools really are.

2. Without the intention of initiating premature bikeshedding, what was the
thought behind proposing `inout foo = ...` vs the seemingly more obvious
`var foo: inout = ...`, given that `inout` was moved to the type side of
the colon?


On Fri, Feb 17, 2017 at 11:11 AM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 17, 2017, at 12:08 PM, John McCall  wrote:
>
> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev  com> wrote:
>
> Hi John, would you mind creating a markdown document for this manifesto in
>  https://github.com/apple/swift/tree/master/docs? :)
>
> Yes, it should go in the repository.  That commit is pending, but the in
> meantime, you can see the document properly rendered at:
>   https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d636
> 63c1ef841f/docs/OwnershipManifesto.md
>
>
> Ah, and of course the second I send this, my PR gets merged. :)
>
> The new URL is:
>   https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md
>
> John.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from the 
given context of the first post by Anton. :) Just forget everything I mentioned 
about typealias, because it was based on the assumption of an error list.

Anyways +1 for typed throws. The syntax throws(T) and rethrows(T) is fine by me.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:45:55, Matthew Johnson (matt...@anandabits.com) 
schrieb:


On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution 
 wrote:

So the typed throws are going to be limited to a single error type, is that the 
direction we're heading to?

Yes, this topic was discussed thoroughly last year.


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

In this case, you’d better create a new error type, which includes all the 
cases of those errors:

// FileNotFoundError and WrongFormat are Error-s

struct PreferencesError : Error {
init(_: FileNotFoundError)
init(_: WrongFormat)
// ...
}

func readPreferences() throws(PreferencesError)
In the most “lazy” case, you’d just create an enum of those two:

enum PreferencesError : Error {
case fileNotFound(FileNotFoundError)
case wrongFormat(WrongFormatError)
}
Better yet, you should analyze, which cases are meaningful for user of 
readPreferences, and present them with appropriate interface. You may want to 
crash on those cases of initial error types, with which you can’t do anything 
on the level of abstraction of readPreferences. Some of the others will be 
merged or renamed.

With proper error types, a single type in throws clause is enough, without sum 
types.

2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution 
:


Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.


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

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

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

[Charles Srstka via swift-evolution]

> On Feb 17, 2017, at 1:42 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> - Much better performance. In my testing, updating the completedUnitProperty, 
> with something observing it, takes 1.04 seconds on my 2013 Retinabook, 
> compared with NSProgress’s 52.91 seconds (58.53 seconds if an autorelease 
> pool is used). This frees back-end code from the responsibility of being 
> adulterated with what is effectively UI code in order to determine when the 
> progress object should be updated.

This should have said “updating the completedUnitProperty one million times, 
with something observing it.” I eagerly await the implementation of our new 
forum, hopefully with an edit feature, with bated breath.

Charles

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

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> So the typed throws are going to be limited to a single error type, is that 
> the direction we're heading to?

Yes, this topic was discussed thoroughly last year.

> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com 
> ) schrieb:
> 
>> In this case, you’d better create a new error type, which includes all the 
>> cases of those errors:
>> 
>> // FileNotFoundError and WrongFormat are Error-s
>> 
>> struct PreferencesError : Error {
>> init(_: FileNotFoundError)
>> init(_: WrongFormat)
>> // ...
>> }
>> 
>> func readPreferences() throws(PreferencesError)
>> In the most “lazy” case, you’d just create an enum of those two:
>> 
>> enum PreferencesError : Error {
>> case fileNotFound(FileNotFoundError)
>> case wrongFormat(WrongFormatError)
>> }
>> Better yet, you should analyze, which cases are meaningful for user of 
>> readPreferences, and present them with appropriate interface. You may want 
>> to crash on those cases of initial error types, with which you can’t do 
>> anything on the level of abstraction of 
>> readPreferences. Some of the others will be merged or renamed.
>> 
>> With proper error types, a single type in 
>> throws clause is enough, without sum types.
>> 
>> 2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution 
>> >:
>> 
>> 
>> Sure thing, but that’s not what I was asking about. Kevin made a protocol 
>> that conforms to Error where all the his enums conformed to MyError 
>> protocol. That way we’re losing all enum cases and are not really a step 
>> further as before.
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

So the typed throws are going to be limited to a single error type, is that the 
direction we're heading to?

-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

In this case, you’d better create a new error type, which includes all the 
cases of those errors:

// FileNotFoundError and WrongFormat are Error-s

struct PreferencesError : Error {
init(_: FileNotFoundError)
init(_: WrongFormat)
// ...
}

func readPreferences() throws(PreferencesError)
In the most “lazy” case, you’d just create an enum of those two:

enum PreferencesError : Error {
case fileNotFound(FileNotFoundError)
case wrongFormat(WrongFormatError)
}
Better yet, you should analyze, which cases are meaningful for user of  
readPreferences, and present them with appropriate interface. You may want to 
crash on those cases of initial error types, with which you can’t do anything 
on the level of abstraction of  
readPreferences. Some of the others will be merged or renamed.

With proper error types, a single type in  
throws clause is enough, without sum types.

2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution 
:

Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.

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

[swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

[Charles Srstka via swift-evolution]

I’ve been working on a replacement for Progress (NSProgress) for use in my own 
code for a while now. It hasn’t been extensively battle-tested yet, but for the 
time being it seems to work. The full code for it is at 
https://github.com/CharlesJS/CSProgress 
 (BSD licensed, with the exception 
that Apple/the Swift team is granted permission to treat it as public-domain 
code if they so choose).

A rather detailed description of this class and its motivations are in the 
read-me for the linked repository, and copying the whole thing would probably 
run afoul of the mailing list’s size limit. However, these are the highlights:

- Much better performance. In my testing, updating the completedUnitProperty, 
with something observing it, takes 1.04 seconds on my 2013 Retinabook, compared 
with NSProgress’s 52.91 seconds (58.53 seconds if an autorelease pool is used). 
This frees back-end code from the responsibility of being adulterated with what 
is effectively UI code in order to determine when the progress object should be 
updated.

- Much better RAM usage. NSProgress generates a large number of autoreleased 
objects, which can cause considerable memory bloat if they are not wrapped in 
an autorelease pool, which further hinders performance. By using Swift-native 
types whenever available, this problem is avoided.

- Better thread safety, by using atomic operations to update the 
completedUnitCount property. NSProgress requires taking the lock twice, once to 
read the old value, and once to write the new value. CSProgress reduces this by 
allowing the delta to be sent, meanwhile solving the race condition that can 
occur if something else updates the property in between the two operations.

- Includes a “granularity” property, customizable by the user, which determines 
how often fractionCompleted notifications will be sent. The default is 0.01, 
which means that fractionCompleted notifications will be sent whenever 
fractionCompleted becomes at least 0.01 greater than its value at the time the 
last notification was sent. For a steady increase from 0 to totalUnitCount, the 
notification will be sent 100 times. This prevents unnecessary UI updates when 
the progress is incremented by a negligible amount.

- Much better and “Swiftier” interface:
- All observations are done via closures, rather than KVO.

- All observations are sent via an OperationQueue which is specifiable 
by the user, and which defaults to the main queue. This means that
  UI elements can be directly set from within the notification closures.

- Unlike the closure-based APIs on NSProgress such as 
cancellationHandler, CSProgress allows multiple closures to be specified for 
each observation type, in case a progress object has more than one client that 
wants to observe it.

- Uses generics for all functions taking unit counts, so that any 
integer can be passed to them instead of having to cast everything to Int64.

- Adds a wrapper struct encapsulating both a parent progress and a 
pending unit count, so that explicit tree composition can be used without
  requiring functions to know the pending unit counts of their parents, 
thus preserving the loose coupling inherent to the old-fashioned implicit style.

- Bridging to the standard Objective-C Progress/NSProgress. This code was added 
the most recently, and is the most hackish by far, so it will need a lot of 
testing, but for the time being it seems to pass my unit tests. The bridging is 
designed to allow CSProgress to insert itself into any part of an NSProgress 
tree, being able to handle NSProgress objects as parents or as children. 
Updates to parent NSProgresses are also done on a user-specified 
OperationQueue, which defaults to the main queue. This means that if you prefer 
NSProgress’s KVO-based API, you can actually bind your UI elements directly to 
the NSProgress, and since all updates to the NSProgress will happen on the main 
queue, you won’t need any special property observers to forward notifications 
to the main thread.

I am wondering what the community thinks of this. I’ve tried to keep the 
interface as close to Progress/NSProgress’s as possible, to allow this to be a 
drop-in replacement. There are a few features of NSProgress that are still 
unimplemented; however, I could add them if the response is positive. With the 
interface mirroring Progress’s, this means that, with some tweaking and 
extensive battle testing, CSProgress could potentially serve as a replacement 
for Progress, with the original Progress being renamed back to NSProgress. The 
result would break binary compatibility, but could be source-compatible, and I 
think it has the potential to improve the experience on Swift.

What do you think?

Charles

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Typed throws

[Anton Zhilin via swift-evolution]

In this case, you’d better create a new error type, which includes all the
cases of those errors:

// FileNotFoundError and WrongFormat are Error-s

struct PreferencesError : Error {
init(_: FileNotFoundError)
init(_: WrongFormat)
// ...
}

func readPreferences() throws(PreferencesError)

In the most “lazy” case, you’d just create an enum of those two:

enum PreferencesError : Error {
case fileNotFound(FileNotFoundError)
case wrongFormat(WrongFormatError)
}

Better yet, you should analyze, which cases are meaningful for user of
readPreferences, and present them with appropriate interface. You may want
to crash on those cases of initial error types, with which you can’t do
anything on the level of abstraction of readPreferences. Some of the others
will be merged or renamed.

With proper error types, a single type in throws clause is enough, without
sum types.

2017-02-17 22:22 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:

Sure thing, but that’s not what I was asking about. Kevin made a protocol
> that conforms to Error where all the his enums conformed to MyError
> protocol. That way we’re losing all enum cases and are not really a step
> further as before.
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

Sorry I meant “recover from MyError (protocol)”.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:30:35, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

The function that throws MyError might contain your error enum (or other types 
in general), but you would have to recover from MyType to the dynamic type 
first.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:26:48, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, Feb 17, 2017 at 1:22 PM, Adrian Zubarev via swift-evolution 
 wrote:
Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.


Sorry, can you elaborate? What do you mean by losing enum cases?

Am 17. Februar 2017 um 20:18:48, David Sweeris (daveswee...@mac.com) schrieb:


On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution 
 wrote:

Is the throwing type always a protocol? In your example it is, but is this 
going to be always the case?

I think right now, there’s a bit of compiler magic in that you can only throw 
something that conforms to `Error`.

- Dave Sweeris

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


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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

The function that throws MyError might contain your error enum (or other types 
in general), but you would have to recover from MyType to the dynamic type 
first.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:26:48, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, Feb 17, 2017 at 1:22 PM, Adrian Zubarev via swift-evolution 
 wrote:
Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.


Sorry, can you elaborate? What do you mean by losing enum cases?

Am 17. Februar 2017 um 20:18:48, David Sweeris (daveswee...@mac.com) schrieb:


On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution 
 wrote:

Is the throwing type always a protocol? In your example it is, but is this 
going to be always the case?

I think right now, there’s a bit of compiler magic in that you can only throw 
something that conforms to `Error`.

- Dave Sweeris

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


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

Re: [swift-evolution] [Pitch] Typed throws

[Matthew Johnson via swift-evolution]

> On Feb 17, 2017, at 1:24 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Let's not bring bikeshedding the commonly proposed and rejected union 
> spelling into this.
> Typed throws would be a nice addition, assuming that the core team finds it 
> in scope for phase 2. It seems only logical that any type can be thrown (i.e. 
> conforms to Error) should be permitted to be listed in `throws()`.

Agree.  Typed throws should have a single thrown type.  Making it more 
convenient to throw and catch more than one error type with typed throws 
without having to manually create a wrapper is an orthogonal issue.  David 
Owens convinced me of this last year when we had a thread on the topic.

> 
> 
> On Fri, Feb 17, 2017 at 1:18 PM, Adrian Zubarev via swift-evolution 
> > wrote:
> That’s what I thought too. That’s also the case I showed a simple example how 
> we could solve the giant list with a typealias even if the pipe | operator 
> would be exclusive for anything that conforms to Error.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Februar 2017 um 20:16:30, Anton Zhilin (antonyzhi...@gmail.com 
> ) schrieb:
> 
>> 2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution 
>> >:
>> 
>> 
>> Is the throwing type always a protocol? In your example it is, but is this 
>> going to be always the case?
>> 
>> 
>> I thought it was going to be any one subtype of 
>> Error, be it a struct, an enum, or a protocol existential, or 
>> Error itself.
>> 
> 
> 
> 
> ___
> 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] [Pitch] Typed throws

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 1:22 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Sure thing, but that’s not what I was asking about. Kevin made a protocol
> that conforms to Error where all the his enums conformed to MyError
> protocol. That way we’re losing all enum cases and are not really a step
> further as before.
>

Sorry, can you elaborate? What do you mean by losing enum cases?

Am 17. Februar 2017 um 20:18:48, David Sweeris (daveswee...@mac.com)
> schrieb:
>
>
> On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is the throwing type always a protocol? In your example it is, but is this
> going to be always the case?
>
> I think right now, there’s a bit of compiler magic in that you can only
> throw something that conforms to `Error`.
>
> - Dave Sweeris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[T.J. Usiyan via swift-evolution]

There shouldn't be a need for a third arrow with regard to purity. Impure
encompasses pure in that there is simply no guarantee of purity with an
impure function. You should be able to use a pure function in place of an
impure function without any issue whatsoever.

On Fri, Feb 17, 2017 at 1:35 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> My suggestion is that -> would be the conditional arrow that can be both
> *pure* or *impure*. That would make @pure func foo(_ f: @pure (Int) ->
> Int) -> Int equivalent to func foo(_ f: (Int) ~> Int) -> Int. Plus
> depending on the implementation the compiler *might* be able to help and
> tell you that foo could use ~> instead.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 19:25:41, Anton Zhilin (antonyzhi...@gmail.com)
> schrieb:
>
> Just let
>
> @pure func foo(_ f: (Int) -> Int) -> Int
>
> be the same as those two combined:
>
> @pure func foo(_ f: @pure (Int) -> Int) -> Int
> func foo(_ f: (Int) -> Int) -> Int
>
> No need for anything like “re-pure” or ≃>.
> ​
>
>
> ___
> 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] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Stephen Canon via swift-evolution]

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> There's nothing, afaik, which stands in the way of that syntax today. The 
> proposal is to extend the standard library to add syntax for a math library. 
> The idea of having a core math library has already been mentioned on this 
> list, to great approval, but it should come in the form of an actual library, 
> and not a syntax only!

Right. IMO the way to do this is to develop such a library outside of the 
stdlib to the point that it’s useful enough to be employed for real work and 
people can evaluate what works and what doesn’t. That may require small 
language and stdlib changes for support, which should be brought-up here.

Once such a library were reasonably mature, it would be reasonable to propose 
it for inclusion in swift proper. I expect this process will take a couple 
*years*.

FWIW, I personally despise MATLAB .operator notation, though I accept that it’s 
pretty much achieved saturation at this point. It looks reasonably nice for 
simple single-operand expressions, but it imposes a large burden on the 
compiler (and often leads to inefficient code). In this regard, they are 
something of an attractive nuisance. Consider your example:

3.0 .* A .* B ./ (C.^ 4.0)

with the most obvious implementation, this generates four calls to vector 
functions:

- multiply array by scalar (tmp0 <— 3 .* A)
- elementwise multiplication (tmp1 <— tmp0 .* B)
- elementwise exponentiation (tmp2 <— C .^ 4)
- elementwise division (result <— tmp1 ./ tmp2)

again, with the obvious implementation, this wastes space for temporaries and 
results in extraneous passes through the data. It is often *possible* to solve 
these issues (at least for some the most common cases) by producing proxy 
objects that can fuse loops, but that gets very messy very fast, and it’s ton 
of work to support all the interesting cases.

On the other hand, the stupid obvious loop:

for i in 0 ..< count {
result[i] = 3*A[i]*B[i]/(C[i]*C[i]*C[i]*C[i])
}

or the cleaner, with a little sugar:

zip3(A,B,C).map { 3 * $0.0 * $0.1 / ($0.2 ^ 4) }

requires a tiny bit of boilerplate, but only a single pass through the data and 
allows the compiler to vectorize. Even if the four vector functions use by the 
.operations are perfectly hand-optimized, the multiple passes and extra memory 
traffic they entail often makes it *slower* than the stupid for loop.

I don’t mean to be too discouraging; all of these issues are surmountable, but 
I (personally) think there’s a lot of development that should happen *outside* 
of the stdlib before such a feature is considered for inclusion in the stdlib.

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Vladimir.S via swift-evolution]

On 17.02.2017 20:16, David Sweeris via swift-evolution wrote:




Sent from my iPhone

On Feb 17, 2017, at 01:02, Rien  wrote:



On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution
 wrote:



On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution
 wrote:

While we’re bikeshedding, I’m going to add my two cents. Hold on
to your hat because this might be controversial here.

I think both ‘private’ and ‘fileprivate’ are unnecessary
complications that only serve to clutter the language.

It would make a lot more sense to just have internal and public
only. No private, no fileprivate, no lineprivate, no protected.
It’s all silly.


Eh, I've used `private` to keep myself honest in terms of going
through some book-keeping functions instead of directly accessing a
property.


But is that not an argument to get rid of ‘private’ & ‘fileprivate’?

With great power there comes great responsibility ;-)


I don't see how... I used `private` on some dicts that interact with
each other (faking a lightweight database) to ensure I was using my
type's subscript functions (which handle updating all the dicts
correctly) instead of directly accessing the dictionaries in some areas
where the interactions theoretically wouldn't matter. Since I was able
to mark those properties as private, I know that all the access to those
properties goes through the proper book-keeping functions. Not only does
this reduce the opportunity for bugs, it makes it far simpler to change
the implementation later if I decide it should be backed by a "proper"
database since everything that directly touches the storage will be
right there in the type definition instead of spread through however
many extensions across however many files.



David, I assume personally you see a benefits of 'private' as it is 
currently and don't support extending its scope to "type and subtypes and 
extensions in the same module"? My suggestion was to extend it...


Personally I'd like to have a way to say all of this as access scope(in 
addition to current public/internal/fileprivate):

1. type only
2. type and subtypes in the same module
3. type and subtypes and extensions in the same module
4. file and subtypes in the same module
5. file and subtypes and extensions in the same module

Probably we could have just (3) without (2), and (5) without (4), need to 
discuss if it is important to be able to provide access to subtype but not 
for extensions.


So, it seems for me like we need to return 'public' keyword where it was in 
Swift2(so to have public/internal/private "file"-based scope), and 
introduce well-designed scope access levels with own keywords.


For example, if we really need just (3) and just (5) (without 2 and 4):
typeprivate - type only
typeprotected - type and subtypes and extensions in the same module
typeinternal - file and subtypes and extensions in the same module

Opinions?


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


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

Re: [swift-evolution] [Pitch] Typed throws

[Xiaodi Wu via swift-evolution]

Let's not bring bikeshedding the commonly proposed and rejected union
spelling into this.
Typed throws would be a nice addition, assuming that the core team finds it
in scope for phase 2. It seems only logical that any type can be thrown
(i.e. conforms to Error) should be permitted to be listed in `throws()`.


On Fri, Feb 17, 2017 at 1:18 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> That’s what I thought too. That’s also the case I showed a simple example
> how we could solve the giant list with a typealias even if the pipe |
> operator would be exclusive for anything that conforms to Error.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 20:16:30, Anton Zhilin (antonyzhi...@gmail.com)
> schrieb:
>
> 2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>
> Is the throwing type always a protocol? In your example it is, but is this
>> going to be always the case?
>>
> I thought it was going to be any one subtype of Error, be it a struct, an
> enum, or a protocol existential, or Error itself.
> ​
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

Sure thing, but that’s not what I was asking about. Kevin made a protocol that 
conforms to Error where all the his enums conformed to MyError protocol. That 
way we’re losing all enum cases and are not really a step further as before.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:18:48, David Sweeris (daveswee...@mac.com) schrieb:


On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution 
 wrote:

Is the throwing type always a protocol? In your example it is, but is this 
going to be always the case?

I think right now, there’s a bit of compiler magic in that you can only throw 
something that conforms to `Error`.

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu  wrote:

> On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S  wrote:
>
>> On 17.02.2017 20:48, Xiaodi Wu wrote:
>>
>>> What you are really asking for is a way of flexibly designating a "unit
>>> of
>>> code" within a module, for which the general solution is submodules. The
>>> objection is that, instead of tackling that issue, these are suggestions
>>> to
>>> invent ad-hoc units of code (scope + extensions only in the same file,
>>> scope + extensions only in the same module, class + extensions only in
>>> the
>>> same file + subclasses only in the same module), and it is possible to
>>> invent arbitrary many of these.
>>>
>>
>> No, sorry, I don't agree with you.
>> Current situation forces us to generate huge source files or write each
>> type in its own submodule/file. IMO it is very naturally to have a need to
>> protect access to some details *even* in the same file(please find David
>> Sweeris's answer in previous email in this thread. with current 'private'
>> he can *guarantee* that no code touches internal props even in the same
>> file), also many of us need a way to share some details only for
>> extensions/subtypes in other files in the same module/submodule even just
>> to organize code as *one* need/want and to express intention about who
>> should "touch" this code and get help from compiler when accidentally try
>> to use protected method/prop.
>>
>
> I reject the premise that it is a goal of the Swift compiler to protect
> you from yourself.
>

I should clarify, it should certainly protect you from unintentional
accidents that you make, where those are foreseeable, etc. But here we're
talking about _you_ invoking functions that _you_ wrote, which is a pretty
darn clear demonstration of intentionality. And so what I mean to say is
that the Swift compiler, IMO, has no real business trying to protect your
intentions from your other intentions.

You can *guarantee* that nothing in the same file touches what it shouldn't
> touch *by your own eyes*; `private` makes it "easier" but it is by no means
> necessary. Indeed I argue that reading code should be the go-to way reason
> about the behavior of code, and that compiler help is justified only when
> such a method of reasoning is unusually hard or error-prone.
>
> Likewise, you can express intention by documentation. Indeed I argue that
> reading the documentation should be the go-to way for a reader to learn how
> to use unfamiliar code. Since a user will consult the documentation if he
> or she is wondering, "how or when should I use this method?", it is
> perfectly sufficient and elegant to put a sentence in the documentation
> that says, "actually, you should never use this method." It is self-evident
> why one might _want_ compiler help, but it is unclear to me why one _needs_
> compiler help for this: after all, if you call an internal method that
> doesn't behave as intended, you can read the source code to find out
> exactly why--you can even change it!
>
> Someone, who want just internal/public can use only them in own code, no
>> problems. But many feels that they need a more detailed access levels to
>> structure their code, they find current situation not comfortable.
>>
>
> As I said, there are arbitrarily many ways to structure your code. If you
> insist that the compiler should help you to control, perfectly, exactly
> what lines of code can call what other lines of code, and that the way to
> spell this desire is through access levels, then you will need many more
> access levels. My point is that, taken to its logical end, you would need
> infinitely many access levels. Although it would be unnecessary for the
> language to active prohibit certain styles of organizing code, I believe
> very strongly it is a non-goal of Swift to actively support, by the
> addition of new features, all imaginable styles of organizing code.
>
>
>
>>
>>
>>> There is, objectively, an actual minimum number of access modifiers,
>>> which
>>> is two. Those two are: visible only inside the unit of code, or visible
>>> both inside and outside the unit of code. In Swift, those are spelled
>>> internal and public. Everything else here is really talking about better
>>> or
>>> more flexible ways of defining a unit of code.
>>>
>>>
>>> On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
>>> > wrote:
>>>
>>> On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
>>> >
>>> >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
>>> >> 
>>> >> >>>
>>>
>>> wrote:
>>> >>
>>> >> True, what I meant was a wider feedback - let's face it, there
>>> are many
>>> >> more Swift developers now than 2 years ago.
>>> >>
>>> >> My objection 

Re: [swift-evolution] [Pitch] Typed throws

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Is the throwing type always a protocol? In your example it is, but is this 
> going to be always the case?
> 
I think right now, there’s a bit of compiler magic in that you can only throw 
something that conforms to `Error`.

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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

That’s what I thought too. That’s also the case I showed a simple example how 
we could solve the giant list with a typealias even if the pipe | operator 
would be exclusive for anything that conforms to Error.



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:16:30, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution 
:

Is the throwing type always a protocol? In your example it is, but is this 
going to be always the case?

I thought it was going to be any one subtype of  
Error, be it a struct, an enum, or a protocol existential, or  
Error itself.

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Florent Vilmart via swift-evolution]

I'm really not sold about the ~> operator, as it would be easy to miss. Swift 
is known and loved for the expressiveness of the language, using that operator 
doesn't help with that.

On another hand, I agree that this is the sexiest, less intrusive solution.

On 17 févr. 2017 13:36 -0500, Adrian Zubarev via swift-evolution 
, wrote:
> My suggestion is that -> would be the conditional arrow that can be both pure 
> or impure. That would make @pure func foo(_ f: @pure (Int) -> Int) -> Int 
> equivalent to func foo(_ f: (Int) ~> Int) -> Int. Plus depending on the 
> implementation the compiler might be able to help and tell you that foo could 
> use ~> instead.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 19:25:41, Anton Zhilin (antonyzhi...@gmail.com) 
> schrieb:
> > Just let
> >
> > @pure func foo(_ f: (Int) -> Int) -> Int
> >
> > be the same as those two combined:
> >
> > @pure func foo(_ f: @pure (Int) -> Int) -> Int
> > func foo(_ f: (Int) -> Int) -> Int
> >
> > No need for anything like “re-pure” or ≃>.
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Anton Zhilin via swift-evolution]

2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:

Is the throwing type always a protocol? In your example it is, but is this
> going to be always the case?
>
I thought it was going to be any one subtype of Error, be it a struct, an
enum, or a protocol existential, or Error itself.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

Is the throwing type always a protocol? In your example it is, but is this 
going to be always the case?



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 20:08:38, Kevin Nattinger (sw...@nattinger.net) schrieb:

protocol MyError: Error {}
enum MyFooError: MyError { … }
enum MyBarError: MyError { … }

func baz() throws(MyError)

On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
 wrote:

I suggest we need to find a way to shorten the list of the possible error types 
with a the help of typeallias

extension MyError1: Error { ... }
extension MyError2: Error { ... }
extension MyError3: Error { ... }

typealias MyErrors = MyError1 | MyError2 | MyError3   

func foo() throws(MyErrors) -> MyResult
func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 19:47:47, Anton Zhilin via swift-evolution 
(swift-evolution@swift.org) schrieb:

Now this is on-topic, I guess.
Last time we stopped at John McCall’s syntax:

extension MyError: Error { ... }

func foo() throws(MyError) -> MyResult
It’s conservative and prevents visual ambiguity with extra parentheses.

If we (somewhat) agree on this, then submitting a proposal will be trivial.

___
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] final + lazy + fileprivate modifiers

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S  wrote:

> On 17.02.2017 20:48, Xiaodi Wu wrote:
>
>> What you are really asking for is a way of flexibly designating a "unit of
>> code" within a module, for which the general solution is submodules. The
>> objection is that, instead of tackling that issue, these are suggestions
>> to
>> invent ad-hoc units of code (scope + extensions only in the same file,
>> scope + extensions only in the same module, class + extensions only in the
>> same file + subclasses only in the same module), and it is possible to
>> invent arbitrary many of these.
>>
>
> No, sorry, I don't agree with you.
> Current situation forces us to generate huge source files or write each
> type in its own submodule/file. IMO it is very naturally to have a need to
> protect access to some details *even* in the same file(please find David
> Sweeris's answer in previous email in this thread. with current 'private'
> he can *guarantee* that no code touches internal props even in the same
> file), also many of us need a way to share some details only for
> extensions/subtypes in other files in the same module/submodule even just
> to organize code as *one* need/want and to express intention about who
> should "touch" this code and get help from compiler when accidentally try
> to use protected method/prop.
>

I reject the premise that it is a goal of the Swift compiler to protect you
from yourself.

You can *guarantee* that nothing in the same file touches what it shouldn't
touch *by your own eyes*; `private` makes it "easier" but it is by no means
necessary. Indeed I argue that reading code should be the go-to way reason
about the behavior of code, and that compiler help is justified only when
such a method of reasoning is unusually hard or error-prone.

Likewise, you can express intention by documentation. Indeed I argue that
reading the documentation should be the go-to way for a reader to learn how
to use unfamiliar code. Since a user will consult the documentation if he
or she is wondering, "how or when should I use this method?", it is
perfectly sufficient and elegant to put a sentence in the documentation
that says, "actually, you should never use this method." It is self-evident
why one might _want_ compiler help, but it is unclear to me why one _needs_
compiler help for this: after all, if you call an internal method that
doesn't behave as intended, you can read the source code to find out
exactly why--you can even change it!

Someone, who want just internal/public can use only them in own code, no
> problems. But many feels that they need a more detailed access levels to
> structure their code, they find current situation not comfortable.
>

As I said, there are arbitrarily many ways to structure your code. If you
insist that the compiler should help you to control, perfectly, exactly
what lines of code can call what other lines of code, and that the way to
spell this desire is through access levels, then you will need many more
access levels. My point is that, taken to its logical end, you would need
infinitely many access levels. Although it would be unnecessary for the
language to active prohibit certain styles of organizing code, I believe
very strongly it is a non-goal of Swift to actively support, by the
addition of new features, all imaginable styles of organizing code.



>
>
>> There is, objectively, an actual minimum number of access modifiers, which
>> is two. Those two are: visible only inside the unit of code, or visible
>> both inside and outside the unit of code. In Swift, those are spelled
>> internal and public. Everything else here is really talking about better
>> or
>> more flexible ways of defining a unit of code.
>>
>>
>> On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
>> > wrote:
>>
>> On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
>> >
>> >> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
>> >> 
>> > >>>
>>
>> wrote:
>> >>
>> >> True, what I meant was a wider feedback - let's face it, there are
>> many
>> >> more Swift developers now than 2 years ago.
>> >>
>> >> My objection is not to the documentation itself, but to the fact
>> that I'm
>> >> unnecessarily exposing an internal implementation detail to the
>> rest of
>> >> the module. Being able to hide it from the rest IMHO leads to
>> better
>> >> though-through API that is indeed meant to be exposed; whereas
>> exposing
>> >> internal details leads to allowing various quick hacks instead. We
>> know
>> >> these quick hacks very well from the ObjC world by accessing
>> private
>> >> parts of the object via duck typing or setting values via KVO.
>> >>
>> >> At least this is my 

Re: [swift-evolution] [Pitch] Typed throws

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 10:45 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Now this is on-topic, I guess.
> Last time we stopped at John McCall’s syntax:
> 
> extension MyError: Error { ... }
> 
> func foo() throws(MyError) -> MyResult
> It’s conservative and prevents visual ambiguity with extra parentheses.
> 
> If we (somewhat) agree on this, then submitting a proposal will be trivial.
> 
That mostly works for me. I’m a bit hesitant because I’m not sure how well that 
syntax would scale (if there are multiple types of errors that could be 
thrown). If the consensus is that such a scenario isn’t likely to be a problem 
in practice, then +1

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

Re: [swift-evolution] [Pitch] Typed throws

[Kevin Nattinger via swift-evolution]

protocol MyError: Error {}
enum MyFooError: MyError { … }
enum MyBarError: MyError { … }

func baz() throws(MyError)

> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I suggest we need to find a way to shorten the list of the possible error 
> types with a the help of typeallias
> 
> extension MyError1: Error { ... }
> extension MyError2: Error { ... }
> extension MyError3: Error { ... }
> 
> typealias MyErrors = MyError1 | MyError2 | MyError3  
> 
> func foo() throws(MyErrors) -> MyResult
> func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Februar 2017 um 19:47:47, Anton Zhilin via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Now this is on-topic, I guess.
>> Last time we stopped at John McCall’s syntax:
>> 
>> extension MyError: Error { ... }
>> 
>> func foo() throws(MyError) -> MyResult
>> It’s conservative and prevents visual ambiguity with extra parentheses.
>> 
>> If we (somewhat) agree on this, then submitting a proposal will be trivial.
>> 
>> ___
>> 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] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu  wrote:
> 
> 
> On Fri, Feb 17, 2017 at 12:46 PM, David Sweeris  > wrote:
> 
>> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution 
>> > wrote:
>> 
>> If I read Nicolas's post correctly, I think he's more arguing for the
>> ability to create syntax that allows Swift to behave in a similar way
>> to Numpy/Matlab. While Swift already does allow you to define your own
>> operators, the main complaint is that he can't define the specific
>> operators he would like.
> 
> In Xcode 8.2.1, with the 8.2.1 toolchain, this works (well, it compiles… 
> obviously it doesn’t check for mis-matched array lengths):
> infix operator .+
> func .+  (lhs: [T], rhs: [T]) -> [T] {
> 
> precondition(lhs.count == rhs.count)
>  
> return zip(lhs, rhs).map { $0.0 + $0.1 }
> }
> print([1,2,3].+[4,5,6]) //outputs [5, 7, 9]
> 
> There's nothing, afaik, which stands in the way of that syntax today.
Yep, that’s what I was demonstrating

> The proposal is to extend the standard library to add syntax for a math 
> library. The idea of having a core math library has already been mentioned on 
> this list, to great approval, but it should come in the form of an actual 
> library, and not a syntax only!

Oh, sorry, I was confused… I thought the proposal was to allow the syntax.

Well, count me as another +1 for adding a `CoreMath` library (although it 
should probably be called something else, unless we can make it work in Obj-C, 
too).

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

Re: [swift-evolution] [Pitch] Typed throws

[Adrian Zubarev via swift-evolution]

I suggest we need to find a way to shorten the list of the possible error types 
with a the help of typeallias

extension MyError1: Error { ... }
extension MyError2: Error { ... }
extension MyError3: Error { ... }

typealias MyErrors = MyError1 | MyError2 | MyError3  

func foo() throws(MyErrors) -> MyResult
func bar(_: () throws(T) -> Void) rethrows(MyErrors, T) -> MyResult


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 19:47:47, Anton Zhilin via swift-evolution 
(swift-evolution@swift.org) schrieb:

Now this is on-topic, I guess.
Last time we stopped at John McCall’s syntax:

extension MyError: Error { ... }

func foo() throws(MyError) -> MyResult
It’s conservative and prevents visual ambiguity with extra parentheses.

If we (somewhat) agree on this, then submitting a proposal will be trivial.

___
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] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 12:46 PM, David Sweeris  wrote:

>
> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If I read Nicolas's post correctly, I think he's more arguing for the
> ability to create syntax that allows Swift to behave in a similar way
> to Numpy/Matlab. While Swift already does allow you to define your own
> operators, the main complaint is that he can't define the specific
> operators he would like.
>
>
> In Xcode 8.2.1, with the 8.2.1 toolchain, this works (well, it compiles…
> obviously it doesn’t check for mis-matched array lengths):
> infix operator .+
> func .+  (lhs: [T], rhs: [T]) -> [T] {
>

precondition(lhs.count == rhs.count)


> return zip(lhs, rhs).map { $0.0 + $0.1 }
> }
> print([1,2,3].+[4,5,6]) //outputs [5, 7, 9]
>

There's nothing, afaik, which stands in the way of that syntax today. The
proposal is to extend the standard library to add syntax for a math
library. The idea of having a core math library has already been mentioned
on this list, to great approval, but it should come in the form of an
actual library, and not a syntax only!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Xiaodi Wu via swift-evolution]

On Fri, Feb 17, 2017 at 12:34 PM, Nicolas Fezans 
wrote:

>
> > If you're simply looking for elementwise multiply without performance
> > requirements, map(*) is a very succinct spelling.
>
> Yes, it is (combined with zip), but:
> 1) zip map will not enforce same size (which shall be done to fail hard
> early), nor allow to combine with an array of a single element, nor with a
> single element (same type but not even wrapped in the array)
> 2) the syntax becomes a bit uglier if you want an element-wise
> multiplication of two [[[Double]]]
> 3) And the syntax I propose allow scientist to write things like (here
> Version 2)
>
> 3.0 .* A .* B ./ (C.^ 4.0)
>
> which is extremely clear to read and look pretty much as we would write in
> maths. BTW some of the functionalities I am mentioning here are existing
> with no specific libraries with the std::valarray in C++.
>

What you're asking for is a Swift-native math library! This is something
that people are interested in making, and I would want one too.

>
> > Performant implementations for these operations like you have in Matlab
> rely
> > on special math libraries. Apple platforms have Accelerate that makes
> this
> > possible, and other implementations of BLAS/LAPACK do the same for Linux
> and
> > Windows platforms.
> >
> > There has been talk on this list of writing Swifty wrappers for such
> > libraries. The core team has said that the way to get such facilities
> into
> > Swift corelibs is to write your own library, get broad adoption, then
> > propose its acceptance here. Currently, several libraries like Surge and
> > Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms;
> it
> > would be interesting to explore whether the same can be done in a
> > cross-platform way.
> >
> > But simply adding sugar to the standard library will not give you the
> > results you're looking for (by which I mean, the performance will be
> > unacceptable), and there's no point in providing sugar for something that
> > doesn't work like the operator implies (Matlab's elementwise operators
> offer
> > _great_ performance).
> >
>
>
> Yes this is clear to me. My proposal is rather on bringing these syntax to
> the language and the code given is only here to illustrate the kind of
> behavior that I desire. Whether the computations are delegate to external
> libraries, etc. is something that is very important for the performance but
> that *should happen behind the scene* and which is IMO relatively
> decoupled from the syntax exposed to the programmers.
>

Yes, what you are describing is the syntax for a Swift math library. But
you're saying you're interested in designing only the syntax but not the
implementation! Swift Evolution proposals that are accepted actually get
implemented: someone actually needs to make things happen behind the scenes.

What I'm saying is that there are people who are actively designing Swift
math libraries. Although it may not look it based on the chains that get
the highest response, bikeshedding syntax isn't what this list is for. A
proposal needs to have a detailed design for implementing a feature, not
just propose a syntax. Elementwise operators need to come with a performant
implementation.

I would like to insist on a particular point which is of daily concern to
> me at work, where I cannot really use swift (at least not yet) and do these
> kinds of things in C or C++. One issues that we have in academia is that we
> often have algorithms developed independently by different groups of people
> in different projects and for many years with no intentions to bring them
> together.
>
> Team A decides to built a solution based on a dedicated library libA
> whereas team B decides to use another library libB for providing these
> functionalities. Often it might even be the same library but in completely
> different versions because there was 10 years between both developments.
> Now a project C started and need to reuse pieces from project A and B but
> the libraries do not "talk to each other": a matrix-type from libA is
> different from a matrix-type from libB and you must refactor most of the
> code to get the whole thing work together.
>
> This situation also never happen (or to a very limited extend) in Matlab,
> because the whole basic objects, matrices and so on are directly part of
> the language and not provided by external libraries. The call to the highly
> performant BLAS/LAPACK libraries happen behind the scenes and in
> 99.9% of the cases you never have to take care of anything. If
> swift was integrating the right syntaxes in the language, my guess is that
> many scientists who currently use C++ would be very interested (just as
> most of them were preferring FORTRAN to C/C++ a long time ago).
>

Right, this is an excellent argument for a core math library in Swift. And
members of the core team have supported that idea. However, they have
stated that the _method_ to 

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution 
>  wrote:
> 
> If I read Nicolas's post correctly, I think he's more arguing for the
> ability to create syntax that allows Swift to behave in a similar way
> to Numpy/Matlab. While Swift already does allow you to define your own
> operators, the main complaint is that he can't define the specific
> operators he would like.

In Xcode 8.2.1, with the 8.2.1 toolchain, this works (well, it compiles… 
obviously it doesn’t check for mis-matched array lengths):
infix operator .+
func .+  (lhs: [T], rhs: [T]) -> [T] {
return zip(lhs, rhs).map { $0.0 + $0.1 }
}
print([1,2,3].+[4,5,6]) //outputs [5, 7, 9]

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

[swift-evolution] [Pitch] Typed throws

[Anton Zhilin via swift-evolution]

Now this is on-topic, I guess.
Last time we stopped at John McCall’s syntax:

extension MyError: Error { ... }

func foo() throws(MyError) -> MyResult

It’s conservative and prevents visual ambiguity with extra parentheses.

If we (somewhat) agree on this, then submitting a proposal will be trivial.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Vladimir.S via swift-evolution]

On 17.02.2017 20:48, Xiaodi Wu wrote:

What you are really asking for is a way of flexibly designating a "unit of
code" within a module, for which the general solution is submodules. The
objection is that, instead of tackling that issue, these are suggestions to
invent ad-hoc units of code (scope + extensions only in the same file,
scope + extensions only in the same module, class + extensions only in the
same file + subclasses only in the same module), and it is possible to
invent arbitrary many of these.


No, sorry, I don't agree with you.
Current situation forces us to generate huge source files or write each 
type in its own submodule/file. IMO it is very naturally to have a need to 
protect access to some details *even* in the same file(please find David 
Sweeris's answer in previous email in this thread. with current 'private' 
he can *guarantee* that no code touches internal props even in the same 
file), also many of us need a way to share some details only for 
extensions/subtypes in other files in the same module/submodule even just 
to organize code as *one* need/want and to express intention about who 
should "touch" this code and get help from compiler when accidentally try 
to use protected method/prop.


Someone, who want just internal/public can use only them in own code, no 
problems. But many feels that they need a more detailed access levels to 
structure their code, they find current situation not comfortable.





There is, objectively, an actual minimum number of access modifiers, which
is two. Those two are: visible only inside the unit of code, or visible
both inside and outside the unit of code. In Swift, those are spelled
internal and public. Everything else here is really talking about better or
more flexible ways of defining a unit of code.


On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution
> wrote:

On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:
>
>> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution
>> 
>>
wrote:
>>
>> True, what I meant was a wider feedback - let's face it, there are many
>> more Swift developers now than 2 years ago.
>>
>> My objection is not to the documentation itself, but to the fact
that I'm
>> unnecessarily exposing an internal implementation detail to the rest of
>> the module. Being able to hide it from the rest IMHO leads to better
>> though-through API that is indeed meant to be exposed; whereas exposing
>> internal details leads to allowing various quick hacks instead. We know
>> these quick hacks very well from the ObjC world by accessing private
>> parts of the object via duck typing or setting values via KVO.
>>
>> At least this is my experience with which the less implementation
details
>> are exposed to the outer world, the better.
>
> I think the fundamental disagreement we’re seeing in this thread is the
> meaning of “outer world”; to some, it means “users of your module”. To
> others, it also means “other developers on my team who are working on
other
> files in the module”.
>
> Personally I feel enforced encapsulation of implementation detail to the
> latter group is less important than the former, and can be handled by
> convention. Whereas other users of your module definitely benefit from
> access control and being able to consume a clearly-defined interface.

I assume we are discussing access modifiers mainly for the former group,
i.e. when we are "inside" the module (even when this module is written by
the same one person, and especially when it is written by the group).

"handled by convention" - are we talking about something like declaring
props and methods as __privateprop , m_privateprop etc and write comments
to mark that they should not be used outside of some scope? Is it really
Swifty and acceptable for the modern language? Will this help to prevent
some mistakes with incorrect access? Is it better than simple and clean
schema for access modifiers and compiler's help?  I don't understand this.

IMO, access modifiers is very known and handy abstraction to distinct
levels of access and to structure code many developers knows about and use
in other languages.
At the end, if one wants to keep all internal - no problems!, you can do
this right now, just don't use fileprivate/private/etc.

Yes, I agree we need a simple and clean schema, not over-complicated, we
need nice keywords, we need a required minimum of access modifiers,
not more, and I do believe currently we don't have this minimum.

Was already suggested, trying again(I do believe this could be a
compromised solution to suit needs of the 

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Abe Schneider via swift-evolution]

If I read Nicolas's post correctly, I think he's more arguing for the
ability to create syntax that allows Swift to behave in a similar way
to Numpy/Matlab. While Swift already does allow you to define your own
operators, the main complaint is that he can't define the specific
operators he would like.

I've been working on a Tensor library that would also benefit from
this. I ended up creating unicode operators for inner product etc. and
then used the standard operators for elementwise operations. However,
I think there is some virtue in not having to use the unicode
characters (many people don't want to have to remap their keyboard),
so providing alternatives might be nice.

While I've never been a fan of Matlab's notation, other people might
be familiar with it, so there's some virtue in making it available.


On Fri, Feb 17, 2017 at 1:01 PM, Xiaodi Wu via swift-evolution
 wrote:
> If you're simply looking for elementwise multiply without performance
> requirements, map(*) is a very succinct spelling.
>
> Performant implementations for these operations like you have in Matlab rely
> on special math libraries. Apple platforms have Accelerate that makes this
> possible, and other implementations of BLAS/LAPACK do the same for Linux and
> Windows platforms.
>
> There has been talk on this list of writing Swifty wrappers for such
> libraries. The core team has said that the way to get such facilities into
> Swift corelibs is to write your own library, get broad adoption, then
> propose its acceptance here. Currently, several libraries like Surge and
> Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms; it
> would be interesting to explore whether the same can be done in a
> cross-platform way.
>
> But simply adding sugar to the standard library will not give you the
> results you're looking for (by which I mean, the performance will be
> unacceptable), and there's no point in providing sugar for something that
> doesn't work like the operator implies (Matlab's elementwise operators offer
> _great_ performance).
>
>
>
>
> On Fri, Feb 17, 2017 at 11:46 Nicolas Fezans via swift-evolution
>  wrote:
>>
>> Dear all,
>>
>> In swift (just as in many other languages) I have been terribly
>> missing the operators like  .*  ./  .^  as I know them from
>> MATLAB/Scilab. These operators are very handy and do element-wise
>> operations on vectors or matrices of the same size.
>>
>> So for instance A*B is a matrix multiplication (and the number of
>> columns for A must correspond to the number of rows in B), whereas A*B
>> (with A and B of same size) returns the matrix of that size whose
>> elements are obtained by making the product of each pair of elements
>> at the same location in A and B.
>>
>> So just a small example:
>> [1.0 , 2.5 , 3.0] .* [2.0 , 5.0 , -1.0] -> [2.0 , 12.5 , -3.0]
>>
>> The same exists for the division (./) or for instance for the power
>> function (.^). Here another example with *, .* , ^ , and .^ to show
>> the difference in behaviour in MATLAB/Scilab
>>
>> >> A = [1 2 3 ; 4 5 6 ; 7 8 9];
>> >> A*A
>>
>> ans =
>>
>> 303642
>> 668196
>>102   126   150
>>
>> >> A.*A
>>
>> ans =
>>
>>  1 4 9
>> 162536
>> 496481
>>
>> >> A^2
>>
>> ans =
>>
>> 303642
>> 668196
>>102   126   150
>>
>> >> A.^3
>>
>> ans =
>>
>>  1 827
>> 64   125   216
>>343   512   729
>>
>> For addition and subtraction the regular operator (+ and -) and their
>> counterparts (.+ and .-) are actually doing the same. However note
>> that since the + operator on arrays is defined differently (it does an
>> append operation), there is a clear use for a .+ operation in swift.
>>
>> Version 1:
>> In principle, we can define it recursively, for instance ...+ would be
>> the element-wise application of the ..+ operator, which is itself the
>> element-wise application of the .+ operator, which is also the
>> element-wise application of the + operator.
>>
>> Version 2:
>> Alternatively we could have a concept where .+ is the element-wise
>> application of the .+ operator and finally when reaching the basic
>> type (e.g. Double when starting from Double) the .+ operator
>> needs to be defined as identical to the + operator. I do prefer this
>> version since it does not need to define various operators depending
>> on the "level" (i.e. Double -> level 0, [Double] -> level 1,
>> [[Double]] -> level 2, etc.). I could make this option work without
>> generics, but as I tried it with generics it generated a runtime error
>> as the call stack grew indefinitely (which does not seem as something
>> that should actually happen since at each call the level gets lower
>> and when reaching 0 it all solvable).
>>
>>
>> Anyway, I would like to discuss first the basic idea of defining these
>> element-wise operators for Arrays, before seeing how far it would be
>> 

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

[Nicolas Fezans via swift-evolution]

> If you're simply looking for elementwise multiply without performance
> requirements, map(*) is a very succinct spelling.

Yes, it is (combined with zip), but:
1) zip map will not enforce same size (which shall be done to fail hard
early), nor allow to combine with an array of a single element, nor with a
single element (same type but not even wrapped in the array)
2) the syntax becomes a bit uglier if you want an element-wise
multiplication of two [[[Double]]]
3) And the syntax I propose allow scientist to write things like (here
Version 2)

3.0 .* A .* B ./ (C.^ 4.0)

which is extremely clear to read and look pretty much as we would write in
maths. BTW some of the functionalities I am mentioning here are existing
with no specific libraries with the std::valarray in C++.

>
> Performant implementations for these operations like you have in Matlab
rely
> on special math libraries. Apple platforms have Accelerate that makes this
> possible, and other implementations of BLAS/LAPACK do the same for Linux
and
> Windows platforms.
>
> There has been talk on this list of writing Swifty wrappers for such
> libraries. The core team has said that the way to get such facilities into
> Swift corelibs is to write your own library, get broad adoption, then
> propose its acceptance here. Currently, several libraries like Surge and
> Upsurge offer vectorized wrappers in Swifty syntax for Apple platforms; it
> would be interesting to explore whether the same can be done in a
> cross-platform way.
>
> But simply adding sugar to the standard library will not give you the
> results you're looking for (by which I mean, the performance will be
> unacceptable), and there's no point in providing sugar for something that
> doesn't work like the operator implies (Matlab's elementwise operators
offer
> _great_ performance).
>


Yes this is clear to me. My proposal is rather on bringing these syntax to
the language and the code given is only here to illustrate the kind of
behavior that I desire. Whether the computations are delegate to external
libraries, etc. is something that is very important for the performance but
that *should happen behind the scene* and which is IMO relatively decoupled
from the syntax exposed to the programmers.


I would like to insist on a particular point which is of daily concern to
me at work, where I cannot really use swift (at least not yet) and do these
kinds of things in C or C++. One issues that we have in academia is that we
often have algorithms developed independently by different groups of people
in different projects and for many years with no intentions to bring them
together.

Team A decides to built a solution based on a dedicated library libA
whereas team B decides to use another library libB for providing these
functionalities. Often it might even be the same library but in completely
different versions because there was 10 years between both developments.
Now a project C started and need to reuse pieces from project A and B but
the libraries do not "talk to each other": a matrix-type from libA is
different from a matrix-type from libB and you must refactor most of the
code to get the whole thing work together.

This situation also never happen (or to a very limited extend) in Matlab,
because the whole basic objects, matrices and so on are directly part of
the language and not provided by external libraries. The call to the highly
performant BLAS/LAPACK libraries happen behind the scenes and in
99.9% of the cases you never have to take care of anything. If
swift was integrating the right syntaxes in the language, my guess is that
many scientists who currently use C++ would be very interested (just as
most of them were preferring FORTRAN to C/C++ a long time ago).



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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 9:48 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> What you are really asking for is a way of flexibly designating a "unit of 
> code" within a module, for which the general solution is submodules. The 
> objection is that, instead of tackling that issue, these are suggestions to 
> invent ad-hoc units of code (scope + extensions only in the same file, scope 
> + extensions only in the same module, class + extensions only in the same 
> file + subclasses only in the same module), and it is possible to invent 
> arbitrary many of these.
> 
> There is, objectively, an actual minimum number of access modifiers, which is 
> two. Those two are: visible only inside the unit of code, or visible both 
> inside and outside the unit of code. In Swift, those are spelled internal and 
> public. Everything else here is really talking about better or more flexible 
> ways of defining a unit of code.

Wasn’t there a thread about submodules a while back? I’m pretty sure I remember 
reading some back and forth about it here, but I don’t recall any conclusions.

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Adrian Zubarev via swift-evolution]

That autocorrection sometimes :/

Purity could easily be expressed through the arrow, plus it enforces you to 
have a return type (other than Void).


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 19:27:12, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

Purity could be easily be expressed throw the arrow, plus it enforces you to 
have a return type (other than Void).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[David Sweeris via swift-evolution]

> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution 
>  wrote:
> 
>> But given the scope capturing nature of closures I was actually wondering if 
>> this 'purity' should be applied to closures.
> I think It should, pure closure cannot have outside references and therefore 
> cannot create reference cycles even though they are escaping.
> 
> I tend toward using the => sign since it doesn't require a lot of change, it 
> has a nice lightweight syntax and seems different enough from -> .
> The pure keyword in front of the function signature looks like a lot of noise 
> for such a simple concept. And It will only get worse in function signatures.
> 
> see the difference between 
> 
> func pureCurryCompose(f: @pure(B) -> C) -> @pure(@pure(A) -> B) -> 
> (@pure(A) -> C)
> 
> and 
> 
> func pureCurryCompose(f: (B) => C) => ((A) => B) => (A) => C
> 
> The second is easiest to read.
> 
> (of course I would argue that 
> 
> func pureCurryCompose(f: B => C) => (A => B) => (A => C) 
> 
> is the most readable of all but I'm too late for that proposal )

I don’t think it’s worth burning an operator for this (especially since the 
ones that are visually similar to “->” and “=“ are likely to be used by people 
trying to “wrap” functions or assignment).

I’m also currently -1 on the idea of giving some attributes special syntax… 
What happens when we decide some other attribute is worth adding? Does, say, 
“distributive" get to be written as “func * (x:Foo, y:Foo) %> Foo”? How would 
we denote a function that’s both “pure” and “distributive”? “func * (x:Foo, 
y:Foo) %~> Foo”? That gets real hard to read (and eats up large swathes of 
operators) real fast.

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

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Adrian Zubarev via swift-evolution]

Who said that pure functions should be newcomer friendly? Swift attributes are 
way at the end of the swift’s book. Using the -> arrow at first won’t break 
anything. If one would optimize some functions by annotating them to be pure, 
the change to something like ~> would be really easy.

IMHO clustering the whole code with hundred’s of different attributes isn’t the 
right way either. Purity could be easily be expressed throw the arrow, plus it 
enforces you to have a return type (other than Void).



-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 18:59:17, Nicolas Fezans (nicolas.fez...@gmail.com) 
schrieb:

The arrow proposals -> vs. ~> vs. => are not really much shorter than 
the 4 letters of the pure keyword but just confusing and frightening 
for newcomers (BTW __pure exists in GCC if I remember well) whereas 
"pure func" is something that people can easily google in case they 
need to learn the concept. The different arrows are very compact but 
feel a bit like J, which is a language I would not like swift to look 
like. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Anton Zhilin via swift-evolution]

Just let

@pure func foo(_ f: (Int) -> Int) -> Int

be the same as those two combined:

@pure func foo(_ f: @pure (Int) -> Int) -> Int
func foo(_ f: (Int) -> Int) -> Int

No need for anything like “re-pure” or ≃>.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution