Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

[Adrian Zubarev via swift-evolution]

I was a little afraid of that when I read Teds message first, but I thought I 
give it a try. This additional change doest feel heavy at all to me.

My question is, when is the right time for this if not now? If not now than 
this won’t happen in Swift 4.1 either, and I highly doubt it for Swift 5, 
because then we’re probably going to focus on ABI again to get it finally done.

If that change could be accepted, than just leave it until someone had some 
time to implement it. That means if no one had time for Swift 4, then it might 
happen in Swift 4.1. The point is that it will potentially happen at some 
point, because it would be already accepted.

Furthermore I think such _smaller_ proposals are more attractive to people who 
wants to jump in and contribute to Swift, but might not want to start with 
heavy features like ‘Conditional conformances’.

I really would like the core team to consider this proposal for a review. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 04:33:13, Chris Lattner (clatt...@nondot.org) schrieb:


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

I’d like to revive an additive proposal that couldn’t make it into Swift 3. 
This proposal has a small improvement to the language compared to other big 
features currently being proposed. It almost feels like a bug fix rather than a 
new feature, but it still needs a full and quick review process.

You can read the formatted version here: 
https://github.com/apple/swift-evolution/pull/608

Just MHO, but I consider this syntactic sugar, not a fundamental feature that 
fits the goal of Swift 4 stage 2.  

I’m also pretty opposed to doing it at any time.  The rationale of “implicit 
return” in closures is specifically because they are limited to a single 
expression, which makes the semantics “obvious”.  This was carefully considered.

-Chris

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

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

[Derrick Ho via swift-evolution]

What wrong with [unowned self]
On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> This reminded me of an idea I had long time ago which will have a similar
> effect: add a way to disable implicit captures for closures. FWIW.
>
> > On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > # `@selfsafe`: a new way to avoid reference cycles
> >
> > * Proposal: [SE-](-selfsafe.md)
> > * Authors: [Matthew Johnson](https://github.com/anandabits)
> > * Review Manager: TBD
> > * Status: **Awaiting review**
> >
> > ## Introduction
> >
> > This proposal introduces the `@selfsafe` function argument attribute
> which together with a `withWeakSelf` property on values of function type.
> Together these features enable library authors to create APIs can be
> statically verified to never extend the lifetime of the `self` a function
> they take may have captured.  This is accomplished by allowing the library
> implementation convert the function to a nearly identical function that is
> guaraneteed to have a `weak` capture of `self` and be a no-op after `self`
> is released.
> >
> > Swift-evolution thread: []()
> >
> > ## Motivation
> >
> > Accidentally forgeting to use weak references is a common problem and
> can easily lead to reference cycles.  Some APIs are best designed such that
> users *cannot* extend the lifetime of `self` by escaping a closure that
> happens to strongly capture `self`.  For example,
> `UIControl.addTarget(_:action:for:) does not retain the target, thereby
> preventing users from making the mistake of using a closure with an
> accidental strong reference.  We can do something similar in Swift:
> >
> > ```swift
> > // in the library:
> > func addTarget(_ target: T, action: T -> Int -> Void) {
> >   // store a weak reference to the target
> >   // when the action is fired call ref.map{ action($0)(42) }
> > }
> >
> > // in user code:
> > class C {
> >   init() {
> >  addTarget(self, action: C.takesInt)
> >   }
> >
> >   func takesInt(_ i: Int) {}
> > }
> > ```
> >
> > Both the library and the caller have to deal with a lot of details and
> boilerplate that we would prefer to avoid.  The natural design in Swift
> would be to simply take an action function.  Unfortunately if we do that we
> run into a problem:
> >
> > ```swift
> > // in the library
> > func addAction(_ f: Int -> Void) {
> >   // store a strong ref to f, which might include a strong ref to a
> captured self
> >   // later when the action is fired call f(42)
> > }
> >
> > // in user code
> > class C {
> >   init() {
> >  addAction(takesInt)
> >  // oops! should have been: addAction{ [weak self]
> self?.takesInt($0) }
> >   }
> >
> >   func takesInt(_ i: Int) {}
> > }
> > ```
> >
> > Here the syntax is much nicer, but unfortunately we have unintentionally
> extended the lifetime of `self`.  The burden of ensuring `self` is not
> captured or captured weakly falls on users of the library.
> >
> > It would very nice if it were possible to design an API that has weak
> capture semantics while still acheiving the more concise and Swifty syntax.
> >
> > ## Proposed Solution
> >
> > This proposal introduces a read-only property on all function types:
> `withWeakSelf` as well as a `@selfsafe` function argument annotation.
> (This name for the annotation is a strawman - I would love to hear better
> ideas)
> >
> > ### `withWeakSelf`
> >
> > `withWeakSelf` can be imagined as a property declared like the following:
> >
> > ```swift
> > extension T -> Void {
> >  var withWeakSelf: T -> Void { return // compiler magic }
> > }
> > extension T -> U {
> >  var withWeakSelf: T -> U? { return // compiler magic }
> > }
> > extension T -> U? {
> >  var withWeakSelf: T -> U? { return // compiler magic }
> > }
> > ```
> >
> > It returns a closure that is identical to itself in every respect except
> four:
> > 1. If the context includes a strong or unowned `self` capture, that is
> converted to a weak capture.
> > 2. If the function returns a non-`Void`, non-`Optional` type the return
> type is wrapped in an `Optional`.
> > 3. The function returned by `withWeakSelf` is a no-op after `self` has
> been released.  If the return type is non-`Void`, the function returns
> `nil` after `self` has been released.
> > 4. Any addtional non-`self` context is released as soon as possible
> after `self` is released.
> >
> > From these rules, it follows that `withWeakSelf` can be a no-op unless
> `self` is captured strong or unowned or the return type is non-`Void` and
> non-`Optional`.
> >
> > Important note: any additional context the closure requies beyond `self`
> continues to be captured as it was originally.
> >
> > ### `@selfsafe`
> >
> > When a function argument is annotated with `@selfsafe` two rules are in
> effect for the implementation:
> > 1. The argument *is not* allowed to escape the function.
> > 2. The closure returend by `withWeakSelf`

Re: [swift-evolution] [Draft] open and public protocols

[David Waite via swift-evolution]

I am unsure if this feature is a good idea. Does someone have a real-world use 
for this which isn’t just hiding strong implementation coupling behind a 
protocol?

When I consume a protocol, it is under the assumption that the protocol is 
documented such that I would be able to work against *any* implementation of 
the protocol. With a closed protocol, I would have to assume that there are 
significant side effects, either undocumented or difficult for a third party to 
duplicate. To my experience, that sounds brittle.

Assuming you aren’t switching on the implementing type of a protocol (which 
itself can be a sign that your design isn’t properly using polymorphism), one 
could get this design by creating a struct with the interface desired, and 
passing invocations through to an internal protocol reference.

-DW

> On Feb 18, 2017, at 1:41 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Now that we’re in phase 2 I’d like to officially propose we introduce `open` 
> protocols and require conformances to  `public` protocols be inside the 
> declaring module.  Let’s use this thread for feedback on the official 
> proposal.  After a healthy round of discussion I’ll open a PR to submit it 
> for review.
> 
> 
> # Feature name
> 
> * Proposal: [SE-](-open-public-protocols.md)
> * Authors: [Matthew Johnson](https://github.com/anandabits)
> * Review Manager: TBD
> * Status: **Awaiting review**
> 
> ## Introduction
> 
> This proposal introduces `open protocol` and changes the meaning of `public 
> protocol` to match the meaning of `public class` (in this case, conformances 
> are only allowed inside the declaring module).
> 
> The pitch thread leading up to this proposal was: [consistent public access 
> modifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031653.html)
> 
> ## Motivation
> 
> A general principle the Swift community has adopted for access control is 
> that defaults should reserve maximum flexibility for a library.  The ensures 
> that any capabilities beyond mere visibility are not available unless the 
> author of the library has explicitly declared their intent that the 
> capabilities be made available.  Finally, when it is possible to switch from 
> one semantic to another without breaking clients (but not vice-versa) we 
> should prefer the more forgiving (i.e. fixable) semantic as the (soft) 
> default.
> 
> `public` is considered a "soft default" in the sense that it is the first 
> access modifier a user will reach for when exposing a declaration outside of 
> the module.  In the case of protocols the current meaning of `public` does 
> not meet the principle of preserving maximum flexibility for the author of 
> the library.  It allows users of the library to conform to the protocol.
> 
> There are good reasons a library may not wish to allow users to add 
> conformances to a protocol.  For example, it may not wish to expose the 
> conforming concrete types.  While similar behavior could be accomplished with 
> an enum if cases could be private, that requires an implementation to use 
> switch statements rather than polymorphism.
> 
> Even if all the conforming types are also public there are cases where 
> polymorphism is the preferred implementation.  For example, if the set of 
> conforming types is not expected to be fixed (despite all being inside the 
> library) the authors may not want to have to maintain switch statements every 
> time they need to add or remove a confroming type which would be necessary if 
> an enum were used instead.  Polymorphism allows us to avoid this, giving us 
> the ability to add and remove conforming types within the implementation of 
> the library without the burden of maintaining switch statements.
> 
> Aligning the access modifiers for protocols and classes allows us to specify 
> both conformable and non-conformable protocols, provides a soft default that 
> is consistent with the principle of (soft) defaults reserving maximum 
> flexibility for the library, and increases the overall consistency of the 
> language by aligning the semantics of access control for protocols and 
> classes.
> 
> The standard library currently has at least one protocol (`MirrorPath`) that 
> is documented as disallowing client conformances.  If this proposal is 
> adopted it is likely that `MirrorPath` would be declared `public protocol` 
> and not `open protocol`.
> 
> Jordan Rose has indicated that the Apple frameworks also include a number of 
> protocols documented with the intent that users do not add conformances.  
> Perhaps an importer annotation would allow the compiler to enforce these 
> semantics in Swift code as well.
> 
> ## Proposed solution
> 
> The proposed solution is to change the meaning of `public protocol` to 
> disallow conformances outside the declaring module and introduce `open 
> protocol` to allow conformances outside the decalring module (equivalent to 
> the current meaning of `public protocol

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

[Jose Cheyo Jimenez via swift-evolution]

How exactly is the use of scope private harmful? 

Do you have specific examples when scope private was harmful?



> On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution 
>  wrote:
> 
> On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution 
> wrote:
>> I don’t think there is evidence that scope private in Swift3 is "actively 
>> harmful”. 
>> 
> 
> This thread would quite simply not exist if not to present exactly that 
> evidence. It exists; we, the change's detractors, exist.
> 
> Zachary
> 
> ___
> 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 18, 2017, at 12:40 AM, Xiaodi Wu  wrote:
> 
> On Sat, Feb 18, 2017 at 1:07 AM, David Waite  > wrote:
> 
> 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.

IMHO doc comment is no different than a keyword or attribute flagging the 
capability other than the color paint used on the bike shed. I’d disagree with 
an attribute or doc comment unless ‘override’ was also moved to be similar.

Documentation styles differ greatly between developers and projects, but I 
personally subscribe to the idea of self-documenting internal code, resorting 
to documentation when that is not possible. Published documentation (doc 
comments) are reserved for when code is meant to be accessed externally.

Even then, I wouldn’t document an *implementation* of a protocol unless the 
protocol was being implemented by a public type *and* left flexibility in the 
behavior of the implementation, Otherwise, I would rely on the documentation of 
the protocol.

For the vast majority of code, I simply don’t see people using doc comments by 
default. So this feature would have them creating doc comments for the purpose 
of indicating "RequiredBy"

Second, most of the reasons for marking a method or property as being required 
by a protocol go away if such a feature is optional per-method. Developers 
scanning code looking for the cause of odd behavior aren’t going to notice that 
there is a typo in the method signature, still, nor are they going to see a 
missing “RequiredBy” doc comment as a clue unless their coding style requires 
such (most likely enforced by a third party linter)

All that said, I’ve seen plenty of code attempt to indicate such a “RequiredBy” 
feature via extensions, e.g.

extension ClassName : ProtocolName { … }

I could see a compromise of an opt-in feature where such an extension is 
expected to contain the body of the protocol implementation (or of multiple 
protocols, e.g. Equatable and Hashable), and that any non-private method in the 
extension would result in a warning if it was not applied toward implementing 
the specified protocols.

Is that something people would be interested in? I don’t know if it is just the 
weekend, but this thread has been very quiet.

> 
> 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 you list here. Such alternative designs would be opt-in, so 
> those who care about this additional compiler help can use it, and those who 
> do not won't need to, consistent with Swift's new emphasis on compatibility 
> and its established emphasis on progressive disclosure.

The design I specified does not result in source breakage. There would be 
warnings for Swift 3 code compiled under Swift 4 saying that the keywords were 
missing, and that the behavior as if the keywords were specified is assumed.

Swift 4 code using the keywords would not be backward compatible with Swift 3, 
but I know of no similar backward compatibility requirements that Swift 4 code 
compile on Swift 3.

-DW


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

Re: [swift-evolution] [Draft] open and public protocols

[Xiaodi Wu via swift-evolution]

There's no way to make a source-breaking change non-breaking. A migration
path that meanders through several different designs just increases the
aggregate pain over multiple releases. The proposed migration path has the
great drawback that, even once approved, no person would actually be
allowed to write code that would compile under the final accepted design
until several versions in the future.

Either this issue about `open` protocols is so important that it meets the
bar for a source-breaking change in Swift 4 (see Ted Kremenek's post about
the very stringent criteria), and thus it merits a single discrete break in
source compatibility between Swift versions, or it is not sufficiently
important.


On Sat, Feb 18, 2017 at 4:44 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 18, 2017, at 14:28, Matthew Johnson 
> wrote:
> >
> >
> >> On Feb 18, 2017, at 3:52 PM, David Sweeris  wrote:
> >>
> >>
> >>> On Feb 18, 2017, at 13:12, Matthew Johnson 
> wrote:
> >>>
> >>>
>  On Feb 18, 2017, at 3:01 PM, David Sweeris 
> wrote:
> 
> 
> > On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > ## Source compatibility
> >
> > This proposal breaks source compatibility, but in a way that allows
> for a simple mechanical migration.  A multi-release stratgegy will be used
> to roll out this proposal to provide maximum possible source compatibility
> from one release to the next.
> >
> > 1. In Swift 4, introduce the `open` keyword and the `@nonopen`
> attribute (which can be applied to `public protocol` to give it the new
> semantics of `public`).
> > 2. In Swift 4 (or 4.1 if necessary) start warning for `public
> protocol` with no annotation.
> > 3. In the subsequent release `public protocol` without annotation
> becomes an error.
> > 4. In the subsequent relase `public protocol` without annotation
> takes on the new semantics.
> > 5. `@nonopen` becomes a warning, and evenutally an erro as soon as
> we are comfortable making those changes.
> 
>  I don’t think we need @nonopen or warnings. IMHO, public/open should
> have the same semantics and syntax regardless of whether the declaration is
> a protocol or a concrete type (or a property?).
> 
>  Other than that nit, I can’t think of a reason to oppose this. So…
> +1, because I like making things as consistent as possible (also because of
> the reasons in the motivation).
> >>>
> >>> The purpose of using `@nonopen` for the migration is to eventually
> break people’s code if they don’t use the migrator and don’t annotate it.
> If we don’t do that the library may ship a version that unintentionally
> breaks their clients (by continuing to use `public` after its meaning has
> changed).
> >>>
> >>> It’s better to break the library before it breaks any clients.  That
> will impact many fewer developers.  This can be handled automatically by
> the migrator and will be a relatively minor inconvenience for developers
> who don’t use it.  That’s better than allowing an accidentally bad version
> of a library from shipping.
> >>
> >> Do we need it for types? "@nonopen public class Foo {...}"?
> >>
> >> (Serious question... I don't recall if we did this phased thing for
> open vs public types)
> >
> > No, because we already introduced that in Swift 3.  Swift 4 has a higher
> bar for breaking changes.  If the core team is willing to accept the
> proposal without a staged migration strategy I would not object to that.
> But I believe it’s best for breaking proposals to present a staged
> migration strategy for the core team to consider.  That’s what this is.  I
> wouldn’t want lack of a staged migration strategy to sink the proposal.
>
> Ah! Ok, I can see that.
>
> Well, for whatever my opinion is worth, I'd prefer we left that part out.
> But I'd rather leave it in than for the proposal to get rejected, though.
>
> - 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] @testable private members

[Brent Royal-Gordon via swift-evolution]

> On Feb 18, 2017, at 10:14 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> When writing unit tests sometimes it is necessary to artificially elevate a 
> member to `internal` in order to make it visible to unit tests where it could 
> otherwise be `private` or `fileprivate`.  We could introduce an `@testable` 
> attribute that could be applied anywhere an access modifier is used.  This 
> attribute would elevate the access modifier to `internal` when the module is 
> imported using the `@testable import MyModule` syntax in a test suite.

extension MyModel {
public func load(fromJSON jsonData: Data) throws {
...
}

private func parse(_ json: Data) -> Any { … }
}

extension MyModel {
public func load(fromPropertyList plistData: Data) throws {
…
}

private func parse(_ plist: Data) -> Any { … }
}

What happens when you try to test `MyModel.parse(_:)`?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

[Xiaodi Wu via swift-evolution]

Ted Kremenek just wrote a post detailing Swift 4 stage 2. Here is the
relevant part again [unable to increase the quotation level for unclear
reasons, but the following is a verbatim copy from that message]:
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.



On Sat, Feb 18, 2017 at 11:59 PM, Kevin Nattinger via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’d like to revive an additive proposal that couldn’t make it into Swift
> 3. This proposal has a small improvement to the language compared to other
> big features currently being proposed. It almost feels like a bug fix
> rather than a new feature, but it still needs a full and quick review
> process.
>
> You can read the formatted version here: https://github.com/
> apple/swift-evolution/pull/608
>
> Just MHO, but I consider this syntactic sugar, not a fundamental feature
> that fits the goal of Swift 4 stage 2.
>
>
> Not that I’m necessarily in favor of this change, but my impression was
> that the whole point of stage 1/2 was that anything not allowed in stage 1
> is fair game in stage 2 (if it happens; that doesn’t seem to be likely at
> this point). What exactly is the goal of stage 2 then, should there
> actually be time for it?
>
>
> I’m also pretty opposed to doing it at any time.  The rationale of
> “implicit return” in closures is specifically because they are limited to a
> single expression, which makes the semantics “obvious”.  This was carefully
> considered.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] @testable private members

[Robert Widmann via swift-evolution]

@testable is already a hack.  Why not just extend it to fileprivate members?

~Robert Widmann

> On Feb 18, 2017, at 1:14 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> When writing unit tests sometimes it is necessary to artificially elevate a 
> member to `internal` in order to make it visible to unit tests where it could 
> otherwise be `private` or `fileprivate`.  We could introduce an `@testable` 
> attribute that could be applied anywhere an access modifier is used.  This 
> attribute would elevate the access modifier to `internal` when the module is 
> imported using the `@testable import MyModule` syntax in a test suite.
> 
> Is this something that others have interest in?  Is it something that might 
> be considered for Swift 4 now that phase 2 has begun?
> 
> Matthew
> ___
> 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] [Stage–2] `return` consistency for single-expressions

[Kevin Nattinger via swift-evolution]

> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I’d like to revive an additive proposal that couldn’t make it into Swift 3. 
>> This proposal has a small improvement to the language compared to other big 
>> features currently being proposed. It almost feels like a bug fix rather 
>> than a new feature, but it still needs a full and quick review process.
>> 
>> You can read the formatted version here: 
>> https://github.com/apple/swift-evolution/pull/608 
>> 
> Just MHO, but I consider this syntactic sugar, not a fundamental feature that 
> fits the goal of Swift 4 stage 2.  

Not that I’m necessarily in favor of this change, but my impression was that 
the whole point of stage 1/2 was that anything not allowed in stage 1 is fair 
game in stage 2 (if it happens; that doesn’t seem to be likely at this point). 
What exactly is the goal of stage 2 then, should there actually be time for it?

> 
> I’m also pretty opposed to doing it at any time.  The rationale of “implicit 
> return” in closures is specifically because they are limited to a single 
> expression, which makes the semantics “obvious”.  This was carefully 
> considered.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Zach Waldowski via swift-evolution]

On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution wrote:
> I don’t think there is evidence that scope private in Swift3 is
> "actively harmful”.


This thread would quite simply not exist if not to present exactly that
evidence. It exists; we, the change's detractors, exist.


Zachary


___
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

[Zach Waldowski via swift-evolution]

On Fri, Feb 17, 2017, at 08:45 PM, Joe Groff via swift-evolution wrote:
> • What is your evaluation of the proposal?



Extremely strong +1.



Unlike others, I agree with the proposed deprecation of
BitwiseOperations. It's not pulling its own weight under this new model.
I encourage other reviewers to try, as the proposal suggests, to come up
with a compelling user of just BitwiseOperations.


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


Yes; it's not as easy to work with integers in Swift 3 as floating
point, which is annoying, since integers are important to binary
programming.


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



The graph of methods and protocols is well-considered, and while it's
probably not mathematically perfect, I could easily see the API being
used to teach binary arithmetic.


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


I've tried (and failed) to use Swift's previous protocols for generic
programming.


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


Thorough reading of previous revisions, glance through of this one.
Thanks for providing the updates section!


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




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

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

[Dave Abrahams via swift-evolution]

I'm on vacation and don't have time for a full review right now, but I am 
concerned that wild this proposal would make enums more general and uniform 
with the rest of the language , they also would become much more awkward for 
common use cases. I have recently been very pleased that I didn't have to 
supply labels in switch statements where the label name would simply have 
matched the name of the variable to be bound.  This looks needlessly verbose:

  case .valid(value: let value, resumptionPoint: let resumptionPoint):

I cannot imagine a real life use case where one would have labels in the case 
and desire to bind associated values to variables having different names than 
the labels.

Secondly, I can't imagine a case where one would want to use the same case 
basename and different labels. The very common use case where the types of 
associated values completely distinguish the case and one would rather not have 
to supply a case name at all is completely unaddressed. If my quick read is not 
mistaken, this proposal makes it legal for cases to have different complete 
names (including base name and labels), but doesn't make it legal to have the 
same full name (which I would love to be "_" or missing in some cases) with 
different associated value types. If we were truly following the precedent set 
by function signatures, wouldn't that be possible too?

Sent from my moss-covered three-handled family gradunza

> On Feb 17, 2017, at 5:26 PM, John McCall  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?
>   • 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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

[Daniel Duan via swift-evolution]

This reminded me of an idea I had long time ago which will have a similar 
effect: add a way to disable implicit captures for closures. FWIW.

> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> # `@selfsafe`: a new way to avoid reference cycles
> 
> * Proposal: [SE-](-selfsafe.md)
> * Authors: [Matthew Johnson](https://github.com/anandabits)
> * Review Manager: TBD
> * Status: **Awaiting review**
> 
> ## Introduction
> 
> This proposal introduces the `@selfsafe` function argument attribute which 
> together with a `withWeakSelf` property on values of function type.  Together 
> these features enable library authors to create APIs can be statically 
> verified to never extend the lifetime of the `self` a function they take may 
> have captured.  This is accomplished by allowing the library implementation 
> convert the function to a nearly identical function that is guaraneteed to 
> have a `weak` capture of `self` and be a no-op after `self` is released.
> 
> Swift-evolution thread: []()
> 
> ## Motivation
> 
> Accidentally forgeting to use weak references is a common problem and can 
> easily lead to reference cycles.  Some APIs are best designed such that users 
> *cannot* extend the lifetime of `self` by escaping a closure that happens to 
> strongly capture `self`.  For example, `UIControl.addTarget(_:action:for:) 
> does not retain the target, thereby preventing users from making the mistake 
> of using a closure with an accidental strong reference.  We can do something 
> similar in Swift:
> 
> ```swift
> // in the library:
> func addTarget(_ target: T, action: T -> Int -> Void) {
>   // store a weak reference to the target
>   // when the action is fired call ref.map{ action($0)(42) }
> }
> 
> // in user code:
> class C {
>   init() {
>  addTarget(self, action: C.takesInt)
>   }
> 
>   func takesInt(_ i: Int) {}
> }
> ```
> 
> Both the library and the caller have to deal with a lot of details and 
> boilerplate that we would prefer to avoid.  The natural design in Swift would 
> be to simply take an action function.  Unfortunately if we do that we run 
> into a problem:
> 
> ```swift
> // in the library
> func addAction(_ f: Int -> Void) {
>   // store a strong ref to f, which might include a strong ref to a captured 
> self
>   // later when the action is fired call f(42)
> }
> 
> // in user code
> class C {
>   init() {
>  addAction(takesInt)
>  // oops! should have been: addAction{ [weak self] self?.takesInt($0) }
>   }
> 
>   func takesInt(_ i: Int) {}
> }
> ```
> 
> Here the syntax is much nicer, but unfortunately we have unintentionally 
> extended the lifetime of `self`.  The burden of ensuring `self` is not 
> captured or captured weakly falls on users of the library.
> 
> It would very nice if it were possible to design an API that has weak capture 
> semantics while still acheiving the more concise and Swifty syntax.
> 
> ## Proposed Solution
> 
> This proposal introduces a read-only property on all function types: 
> `withWeakSelf` as well as a `@selfsafe` function argument annotation.  (This 
> name for the annotation is a strawman - I would love to hear better ideas)
> 
> ### `withWeakSelf`
> 
> `withWeakSelf` can be imagined as a property declared like the following:
> 
> ```swift
> extension T -> Void {
>  var withWeakSelf: T -> Void { return // compiler magic }
> }
> extension T -> U {
>  var withWeakSelf: T -> U? { return // compiler magic }
> }
> extension T -> U? {
>  var withWeakSelf: T -> U? { return // compiler magic }
> }
> ```
> 
> It returns a closure that is identical to itself in every respect except four:
> 1. If the context includes a strong or unowned `self` capture, that is 
> converted to a weak capture.
> 2. If the function returns a non-`Void`, non-`Optional` type the return type 
> is wrapped in an `Optional`.  
> 3. The function returned by `withWeakSelf` is a no-op after `self` has been 
> released.  If the return type is non-`Void`, the function returns `nil` after 
> `self` has been released.
> 4. Any addtional non-`self` context is released as soon as possible after 
> `self` is released.
> 
> From these rules, it follows that `withWeakSelf` can be a no-op unless `self` 
> is captured strong or unowned or the return type is non-`Void` and 
> non-`Optional`.
> 
> Important note: any additional context the closure requies beyond `self` 
> continues to be captured as it was originally.
> 
> ### `@selfsafe`
> 
> When a function argument is annotated with `@selfsafe` two rules are in 
> effect for the implementation:
> 1. The argument *is not* allowed to escape the function.
> 2. The closure returend by `withWeakSelf` *is* allowed to escape the function.
> 
> There should also be a warning if `argument.withWeakSelf` *does not* escape 
> the function in any code paths (because the `@selfsafe` annotation is 
> meaningless if it does not escape).
> 
> This allows a library to do something like the following (a simpli

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

[Chris Lattner via swift-evolution]

> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’d like to revive an additive proposal that couldn’t make it into Swift 3. 
> This proposal has a small improvement to the language compared to other big 
> features currently being proposed. It almost feels like a bug fix rather than 
> a new feature, but it still needs a full and quick review process.
> 
> You can read the formatted version here: 
> https://github.com/apple/swift-evolution/pull/608 
> 
Just MHO, but I consider this syntactic sugar, not a fundamental feature that 
fits the goal of Swift 4 stage 2.  

I’m also pretty opposed to doing it at any time.  The rationale of “implicit 
return” in closures is specifically because they are limited to a single 
expression, which makes the semantics “obvious”.  This was carefully considered.

-Chris

___
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 Hart via swift-evolution]

> On 17 Feb 2017, at 23:30, Matthew Johnson via swift-evolution 
>  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() }

Or:
{ x => x.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)
>>> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
>>> * Status: **Awaiting review**
>>> * Review manager: TBD
>>> 
>>> ## I

[swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

[Matthew Johnson via swift-evolution]

# `@selfsafe`: a new way to avoid reference cycles

* Proposal: [SE-](-selfsafe.md)
* Authors: [Matthew Johnson](https://github.com/anandabits)
* Review Manager: TBD
* Status: **Awaiting review**

## Introduction

This proposal introduces the `@selfsafe` function argument attribute which 
together with a `withWeakSelf` property on values of function type.  Together 
these features enable library authors to create APIs can be statically verified 
to never extend the lifetime of the `self` a function they take may have 
captured.  This is accomplished by allowing the library implementation convert 
the function to a nearly identical function that is guaraneteed to have a 
`weak` capture of `self` and be a no-op after `self` is released.

Swift-evolution thread: []()

## Motivation

Accidentally forgeting to use weak references is a common problem and can 
easily lead to reference cycles.  Some APIs are best designed such that users 
*cannot* extend the lifetime of `self` by escaping a closure that happens to 
strongly capture `self`.  For example, `UIControl.addTarget(_:action:for:) does 
not retain the target, thereby preventing users from making the mistake of 
using a closure with an accidental strong reference.  We can do something 
similar in Swift:

```swift
// in the library:
func addTarget(_ target: T, action: T -> Int -> Void) {
   // store a weak reference to the target
   // when the action is fired call ref.map{ action($0)(42) }
}

// in user code:
class C {
   init() {
  addTarget(self, action: C.takesInt)
   }
   
   func takesInt(_ i: Int) {}
}
```

Both the library and the caller have to deal with a lot of details and 
boilerplate that we would prefer to avoid.  The natural design in Swift would 
be to simply take an action function.  Unfortunately if we do that we run into 
a problem:

```swift
// in the library
func addAction(_ f: Int -> Void) {
   // store a strong ref to f, which might include a strong ref to a captured 
self
   // later when the action is fired call f(42)
}

// in user code
class C {
   init() {
  addAction(takesInt)
  // oops! should have been: addAction{ [weak self] self?.takesInt($0) }
   }
   
   func takesInt(_ i: Int) {}
}
```

Here the syntax is much nicer, but unfortunately we have unintentionally 
extended the lifetime of `self`.  The burden of ensuring `self` is not captured 
or captured weakly falls on users of the library.

It would very nice if it were possible to design an API that has weak capture 
semantics while still acheiving the more concise and Swifty syntax.

## Proposed Solution

This proposal introduces a read-only property on all function types: 
`withWeakSelf` as well as a `@selfsafe` function argument annotation.  (This 
name for the annotation is a strawman - I would love to hear better ideas)

### `withWeakSelf`

`withWeakSelf` can be imagined as a property declared like the following:

```swift
extension T -> Void {
  var withWeakSelf: T -> Void { return // compiler magic }
}
extension T -> U {
  var withWeakSelf: T -> U? { return // compiler magic }
}
extension T -> U? {
  var withWeakSelf: T -> U? { return // compiler magic }
}
```

It returns a closure that is identical to itself in every respect except four:
1. If the context includes a strong or unowned `self` capture, that is 
converted to a weak capture.
2. If the function returns a non-`Void`, non-`Optional` type the return type is 
wrapped in an `Optional`.  
3. The function returned by `withWeakSelf` is a no-op after `self` has been 
released.  If the return type is non-`Void`, the function returns `nil` after 
`self` has been released.
4. Any addtional non-`self` context is released as soon as possible after 
`self` is released.

From these rules, it follows that `withWeakSelf` can be a no-op unless `self` 
is captured strong or unowned or the return type is non-`Void` and 
non-`Optional`.

Important note: any additional context the closure requies beyond `self` 
continues to be captured as it was originally.

### `@selfsafe`

When a function argument is annotated with `@selfsafe` two rules are in effect 
for the implementation:
1. The argument *is not* allowed to escape the function.
2. The closure returend by `withWeakSelf` *is* allowed to escape the function.

There should also be a warning if `argument.withWeakSelf` *does not* escape the 
function in any code paths (because the `@selfsafe` annotation is meaningless 
if it does not escape).

This allows a library to do something like the following (a simplified version 
of a hypothetical future method on `UIControl`):

```swift
   class UIControl {
   
  var action: () -> Void
   
  func setAction(_ action: @selfsafe () -> Void) {
 self.action = action.withWeakSelf
  }
   }
```

In the previous example the function declares the argument with the `@selfsafe` 
annotation.  The compiler verifies that the `action` argument does not escape 
`setAction` and that `action.withWeakSelf` *does* esc

Re: [swift-evolution] [Draft] open and public protocols

[David Sweeris via swift-evolution]

> On Feb 18, 2017, at 14:28, Matthew Johnson  wrote:
> 
> 
>> On Feb 18, 2017, at 3:52 PM, David Sweeris  wrote:
>> 
>> 
>>> On Feb 18, 2017, at 13:12, Matthew Johnson  wrote:
>>> 
>>> 
 On Feb 18, 2017, at 3:01 PM, David Sweeris  wrote:
 
 
> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> ## Source compatibility
> 
> This proposal breaks source compatibility, but in a way that allows for a 
> simple mechanical migration.  A multi-release stratgegy will be used to 
> roll out this proposal to provide maximum possible source compatibility 
> from one release to the next.
> 
> 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute 
> (which can be applied to `public protocol` to give it the new semantics 
> of `public`).
> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` 
> with no annotation.
> 3. In the subsequent release `public protocol` without annotation becomes 
> an error.
> 4. In the subsequent relase `public protocol` without annotation takes on 
> the new semantics.
> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are 
> comfortable making those changes.
 
 I don’t think we need @nonopen or warnings. IMHO, public/open should have 
 the same semantics and syntax regardless of whether the declaration is a 
 protocol or a concrete type (or a property?).
 
 Other than that nit, I can’t think of a reason to oppose this. So… +1, 
 because I like making things as consistent as possible (also because of 
 the reasons in the motivation).
>>> 
>>> The purpose of using `@nonopen` for the migration is to eventually break 
>>> people’s code if they don’t use the migrator and don’t annotate it.  If we 
>>> don’t do that the library may ship a version that unintentionally breaks 
>>> their clients (by continuing to use `public` after its meaning has 
>>> changed).  
>>> 
>>> It’s better to break the library before it breaks any clients.  That will 
>>> impact many fewer developers.  This can be handled automatically by the 
>>> migrator and will be a relatively minor inconvenience for developers who 
>>> don’t use it.  That’s better than allowing an accidentally bad version of a 
>>> library from shipping.
>> 
>> Do we need it for types? "@nonopen public class Foo {...}"?
>> 
>> (Serious question... I don't recall if we did this phased thing for open vs 
>> public types)
> 
> No, because we already introduced that in Swift 3.  Swift 4 has a higher bar 
> for breaking changes.  If the core team is willing to accept the proposal 
> without a staged migration strategy I would not object to that.  But I 
> believe it’s best for breaking proposals to present a staged migration 
> strategy for the core team to consider.  That’s what this is.  I wouldn’t 
> want lack of a staged migration strategy to sink the proposal.

Ah! Ok, I can see that.

Well, for whatever my opinion is worth, I'd prefer we left that part out. But 
I'd rather leave it in than for the proposal to get rejected, though.

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

Re: [swift-evolution] [Draft] open and public protocols

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 3:52 PM, David Sweeris  wrote:
> 
> 
>> On Feb 18, 2017, at 13:12, Matthew Johnson  wrote:
>> 
>> 
>>> On Feb 18, 2017, at 3:01 PM, David Sweeris  wrote:
>>> 
>>> 
 On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution 
  wrote:
 
 ## Source compatibility
 
 This proposal breaks source compatibility, but in a way that allows for a 
 simple mechanical migration.  A multi-release stratgegy will be used to 
 roll out this proposal to provide maximum possible source compatibility 
 from one release to the next.
 
 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute 
 (which can be applied to `public protocol` to give it the new semantics of 
 `public`).
 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` 
 with no annotation.
 3. In the subsequent release `public protocol` without annotation becomes 
 an error.
 4. In the subsequent relase `public protocol` without annotation takes on 
 the new semantics.
 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are 
 comfortable making those changes.
>>> 
>>> I don’t think we need @nonopen or warnings. IMHO, public/open should have 
>>> the same semantics and syntax regardless of whether the declaration is a 
>>> protocol or a concrete type (or a property?).
>>> 
>>> Other than that nit, I can’t think of a reason to oppose this. So… +1, 
>>> because I like making things as consistent as possible (also because of the 
>>> reasons in the motivation).
>> 
>> The purpose of using `@nonopen` for the migration is to eventually break 
>> people’s code if they don’t use the migrator and don’t annotate it.  If we 
>> don’t do that the library may ship a version that unintentionally breaks 
>> their clients (by continuing to use `public` after its meaning has changed). 
>>  
>> 
>> It’s better to break the library before it breaks any clients.  That will 
>> impact many fewer developers.  This can be handled automatically by the 
>> migrator and will be a relatively minor inconvenience for developers who 
>> don’t use it.  That’s better than allowing an accidentally bad version of a 
>> library from shipping.
> 
> Do we need it for types? "@nonopen public class Foo {...}"?
> 
> (Serious question... I don't recall if we did this phased thing for open vs 
> public types)

No, because we already introduced that in Swift 3.  Swift 4 has a higher bar 
for breaking changes.  If the core team is willing to accept the proposal 
without a staged migration strategy I would not object to that.  But I believe 
it’s best for breaking proposals to present a staged migration strategy for the 
core team to consider.  That’s what this is.  I wouldn’t want lack of a staged 
migration strategy to sink the proposal.

> 
> - Dave Sweeris

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

Re: [swift-evolution] [Draft] open and public protocols

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 3:43 PM, Charles Srstka  wrote:
> 
>> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> There are good reasons a library may not wish to allow users to add 
>> conformances to a protocol.  For example, it may not wish to expose the 
>> conforming concrete types.  While similar behavior could be accomplished 
>> with an enum if cases could be private, that requires an implementation to 
>> use switch statements rather than polymorphism.
> 
> Uh, what? You can expose protocols without exposing the concrete types that 
> conform to them. That’s kind of the whole point of protocols.
> 
> public protocol P {}
> 
> private struct S: P {}
> 
> public var p: P
> 
> reduces to this interface:
> 
> public protocol P {
> }
> 
> 
> public var p: P
> 
> The library can then assign something of type S to the “p” variable, and 
> clients will be able to use it without having access to its concrete type.
> 
> Charles
> 

Sorry, this part was not stated as clearly as it should have been.  What 
intends to say is that the library may wish to not only hide the concrete 
types, but also control the set of types which may conform to the protocol (or 
be associated values of the enum) such that users cannot add to the set of 
types.  I will update the document to more clearly describe this use case.  
Thanks for catching this!

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

Re: [swift-evolution] [Draft] open and public protocols

[Adrian Zubarev via swift-evolution]

Great proposal Matthew, huge thanks for pushing this forward and putting it 
together. I simply cannot wait for this to be implemented. :)

+1

I spotted two typos while reading:

public protocol P P{} - one P too much
There is somewhere an erro without an r at the end


-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 21:42:41, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:

Now that we’re in phase 2 I’d like to officially propose we introduce `open` 
protocols and require conformances to `public` protocols be inside the 
declaring module. Let’s use this thread for feedback on the official proposal. 
After a healthy round of discussion I’ll open a PR to submit it for review.


# Feature name

* Proposal: [SE-](-open-public-protocols.md)
* Authors: [Matthew Johnson](https://github.com/anandabits)
* Review Manager: TBD
* Status: **Awaiting review**

## Introduction

This proposal introduces `open protocol` and changes the meaning of `public 
protocol` to match the meaning of `public class` (in this case, conformances 
are only allowed inside the declaring module).

The pitch thread leading up to this proposal was: [consistent public access 
modifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031653.html)

## Motivation

A general principle the Swift community has adopted for access control is that 
defaults should reserve maximum flexibility for a library. The ensures that any 
capabilities beyond mere visibility are not available unless the author of the 
library has explicitly declared their intent that the capabilities be made 
available. Finally, when it is possible to switch from one semantic to another 
without breaking clients (but not vice-versa) we should prefer the more 
forgiving (i.e. fixable) semantic as the (soft) default.

`public` is considered a "soft default" in the sense that it is the first 
access modifier a user will reach for when exposing a declaration outside of 
the module. In the case of protocols the current meaning of `public` does not 
meet the principle of preserving maximum flexibility for the author of the 
library. It allows users of the library to conform to the protocol.

There are good reasons a library may not wish to allow users to add 
conformances to a protocol. For example, it may not wish to expose the 
conforming concrete types. While similar behavior could be accomplished with an 
enum if cases could be private, that requires an implementation to use switch 
statements rather than polymorphism.

Even if all the conforming types are also public there are cases where 
polymorphism is the preferred implementation. For example, if the set of 
conforming types is not expected to be fixed (despite all being inside the 
library) the authors may not want to have to maintain switch statements every 
time they need to add or remove a confroming type which would be necessary if 
an enum were used instead. Polymorphism allows us to avoid this, giving us the 
ability to add and remove conforming types within the implementation of the 
library without the burden of maintaining switch statements.

Aligning the access modifiers for protocols and classes allows us to specify 
both conformable and non-conformable protocols, provides a soft default that is 
consistent with the principle of (soft) defaults reserving maximum flexibility 
for the library, and increases the overall consistency of the language by 
aligning the semantics of access control for protocols and classes.

The standard library currently has at least one protocol (`MirrorPath`) that is 
documented as disallowing client conformances. If this proposal is adopted it 
is likely that `MirrorPath` would be declared `public protocol` and not `open 
protocol`.

Jordan Rose has indicated that the Apple frameworks also include a number of 
protocols documented with the intent that users do not add conformances. 
Perhaps an importer annotation would allow the compiler to enforce these 
semantics in Swift code as well.

## Proposed solution

The proposed solution is to change the meaning of `public protocol` to disallow 
conformances outside the declaring module and introduce `open protocol` to 
allow conformances outside the decalring module (equivalent to the current 
meaning of `public protocol`).

## Detailed design

The detailed design is relatively straightforward but there are three important 
wrinkles to consider.

### User refinement of public protocols

Consider the following example:

```swift
// Library module:
public protocol P {}
public class C: P {}

// User module:
protocol User: P {}
extension C: User {}
```

The user module is allowed to add a refinement to `P` because this does not 
have any impact on the impelementation of the library or its possible 
evolution. It simply allows the user to write code that is generic over a 
subset of the conforming types provided by the library.

### Public protocols with open conforming classe

Re: [swift-evolution] [Manifesto] Ownership

[Michel Fortin via swift-evolution]

Le 17 févr. 2017 à 15:08, John McCall via swift-evolution 
 a écrit :
> 
> 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.

I think the idea of dynamic bookkeeping state is pretty great, and, in 
particular, not having to be exact about the state in the presence of 
concurrent access is a nice way to make it lightweight.

The way I read the manifesto, the bookkeeping field would work like this:

(a) Thread 1 sets bookkeeping state to read, saves previous state (unaccessed)
(b) Thread 2 sets bookkeeping state to read, saves previous state (read)
(c) Thread 1 ends access, restores state to unacceseed -- too early, but 
whatever!
(d) Thread 2 ends access, restores state to read? No, you NEVER restore a read.

If you never restore a previously saved "read" state, then you'll never get 
stuck in a "read" state even if the restore order is wrong (like it is here, 
because of the multiple threads).

In this scenario, thread 2 could also restore the state to "unaccessed" instead 
of doing that conditionally on the saved state. In general however, for 
reentrant functions to keep single-thearded bookkeeping always exact, setting 
the state to "unaccessed" has to be conditional to the saved state being the 
same.

If (a) and (b) are not atomic exchanges, a third thread could write a "modify" 
state during the non-atomic writing of your "read" state, which would make the 
overlap of the two incompatible accesses undetected.

With atomic exchanges in (a) and (b), an incorrect "modify" can only pass 
undetected during the time between (c) and (d). If by chance (c) and (d) were 
to occur in reverse order (making it proper nesting time-wise), an incorrect 
"modify" between the two would become detectable.

This is all very interesting.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Draft] open and public protocols

[Adrian Zubarev via swift-evolution]

Protocols solve way more problems than this. Sometimes they are used as 
backdoors to existing APIs as well. It’s simply an implementation artifact that 
such a protocol might end up public, but there is no point to allow the client 
to conform to it.

I also showed a concrete example in the discussion thread where I needed a 
public-but-not-open protocol really badly. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 22:45:00, Charles Srstka via swift-evolution 
(swift-evolution@swift.org) schrieb:

On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution 
 wrote:

There are good reasons a library may not wish to allow users to add 
conformances to a protocol.  For example, it may not wish to expose the 
conforming concrete types.  While similar behavior could be accomplished with 
an enum if cases could be private, that requires an implementation to use 
switch statements rather than polymorphism.

Uh, what? You can expose protocols without exposing the concrete types that 
conform to them. That’s kind of the whole point of protocols.

public protocol P {}

private struct S: P {}

public var p: P

reduces to this interface:

public protocol P {
}


public var p: P

The library can then assign something of type S to the “p” variable, and 
clients will be able to use it without having access to its concrete type.

Charles

___
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] [Draft] open and public protocols

[David Sweeris via swift-evolution]

> On Feb 18, 2017, at 13:12, Matthew Johnson  wrote:
> 
> 
>> On Feb 18, 2017, at 3:01 PM, David Sweeris  wrote:
>> 
>> 
>>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> ## Source compatibility
>>> 
>>> This proposal breaks source compatibility, but in a way that allows for a 
>>> simple mechanical migration.  A multi-release stratgegy will be used to 
>>> roll out this proposal to provide maximum possible source compatibility 
>>> from one release to the next.
>>> 
>>> 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute 
>>> (which can be applied to `public protocol` to give it the new semantics of 
>>> `public`).
>>> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` 
>>> with no annotation.
>>> 3. In the subsequent release `public protocol` without annotation becomes 
>>> an error.
>>> 4. In the subsequent relase `public protocol` without annotation takes on 
>>> the new semantics.
>>> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are 
>>> comfortable making those changes.
>> 
>> I don’t think we need @nonopen or warnings. IMHO, public/open should have 
>> the same semantics and syntax regardless of whether the declaration is a 
>> protocol or a concrete type (or a property?).
>> 
>> Other than that nit, I can’t think of a reason to oppose this. So… +1, 
>> because I like making things as consistent as possible (also because of the 
>> reasons in the motivation).
> 
> The purpose of using `@nonopen` for the migration is to eventually break 
> people’s code if they don’t use the migrator and don’t annotate it.  If we 
> don’t do that the library may ship a version that unintentionally breaks 
> their clients (by continuing to use `public` after its meaning has changed).  
> 
> It’s better to break the library before it breaks any clients.  That will 
> impact many fewer developers.  This can be handled automatically by the 
> migrator and will be a relatively minor inconvenience for developers who 
> don’t use it.  That’s better than allowing an accidentally bad version of a 
> library from shipping.

Do we need it for types? "@nonopen public class Foo {...}"?

(Serious question... I don't recall if we did this phased thing for open vs 
public types)

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

Re: [swift-evolution] [Draft] open and public protocols

[Charles Srstka via swift-evolution]

> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> There are good reasons a library may not wish to allow users to add 
> conformances to a protocol.  For example, it may not wish to expose the 
> conforming concrete types.  While similar behavior could be accomplished with 
> an enum if cases could be private, that requires an implementation to use 
> switch statements rather than polymorphism.

Uh, what? You can expose protocols without exposing the concrete types that 
conform to them. That’s kind of the whole point of protocols.

public protocol P {}

private struct S: P {}

public var p: P

reduces to this interface:

public protocol P {
}


public var p: P

The library can then assign something of type S to the “p” variable, and 
clients will be able to use it without having access to its concrete type.

Charles

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

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

[Matt Whiteside via swift-evolution]

> 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.
> 
> Slava

I am behind this idea too.  The access control modifiers seem like mostly a 
distraction from more interesting considerations.  If they are causing big 
headaches in the implementation, I wouldn’t mind if they were cut down to just 
internal and public.

-Matt


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

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 3:16 PM, Haravikk  wrote:
> 
> 
>> On 18 Feb 2017, at 16:28, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 This is an idea I had while working with collections, and is particularly 
 inspired by those that use common index types.
 
 Consider for example an array; for indices it simply uses an integer, 
 however, while this is a perfectly valid type to use it opens up the 
 possibility of integers from any number of different sources being passed 
 in by mistake and causing run-time errors. The same is true for wrapping 
 types that use AnyIndex, or really any type that uses Any* to hide 
 underlying types, as on the surface all AnyIndex instances give the 
 illusion of being compatible when they're not, and will only produce 
 errors at run-time when a conflict arises.
 
 The idea to combat this is simple; a new attribute that can be applied to 
 a typealias, my working name is @unique, but there's probably a much 
 better name for it. When applied to a type-alias it indicates to the 
 type-checker that the type being aliased should be treated as a unique 
 type outside of the scope in which it is declared.
>>> 
>>> I've encountered the same problem in essentially the same place, so I'd 
>>> like to see a solution too.
>>> 
>>> This sounds like a slight variation on what, in previous discussions, has 
>>> been called `newtype`. IIRC, one of the reasons we've never done `newtype` 
>>> is that it's not clear which features you want to bring over from the base 
>>> type, or which types should be used for things like operators. (If you have 
>>> `func + (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, 
>>> rhs: Index) -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
>>> 
>>> I'd like to suggest a design that I don't think has been considered before. 
>>> Currently, if the first type in an enum's inheritance clause is a concrete 
>>> type, a set of magical behaviors occur:
>>> 
>>> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
>>> concrete type.
>>> * Each case is associated with a raw value, specified by a literal attached 
>>> to the case.
>>> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
>>> 
>>> There is currently no equivalent for structs, but I suggest we add one.
>>> 
>>> If you say:
>>> 
>>> struct Index: Int {}
>>> 
>>> This is automatically equivalent to saying:
>>> 
>>> struct Index: RawRepresentable {
>>> var rawValue: Int
>>> init(rawValue: Int) { self.rawValue = rawValue }
>>> }
>>> 
>>> And a special rule is applied: You may not declare any other stored 
>>> properties.
>>> 
>>> Additionally, for both `enum`s and `struct`s with raw types, I would 
>>> suggest that, if you conform to a protocol which the raw type conforms to 
>>> and then fail to fulfill its (non-defaulted) requirements, Swift should 
>>> generate a member which forwards to the raw value's implementation. It 
>>> might even be nice to do the same when an initializer, method, property, or 
>>> subscript is declared without providing a body. This would make it easy to 
>>> decide which functionality should be exposed and how it should be 
>>> provided--and it would provide a partial way to fulfill the frequent 
>>> request for syntactic sugar for `Equatable`, `Hashable`, and `Comparable` 
>>> conformances. (I could imagine this being generalized later on.)
>>> 
>>> The main drawback I can see is that the `rawValue` could not be 
>>> encapsulated, since the conformance to the public `RawRepresentable` 
>>> protocol could not be made private. That might be acceptable in a 
>>> convenience feature, or we might decide (perhaps for both `struct`s and 
>>> `enum`s) that Swift should generate the members without actually conforming 
>>> the type unless explicitly asked to.
>> 
>> A lot of this is very similar to the protocol-based forwarding proposal I 
>> worked on last year.  That proposal would avoid the problems you describe 
>> around not being able to properly encapsulate `RawRepresentable`.  It was 
>> also able to handle many nuances around forwarding of self and associated 
>> type requirements.  It even had an example of how something like `newtype` 
>> could be defined in terms of the mechanisms it provides.
>> 
>> I was mid-way through a second draft when it became clear it was not in 
>> scope for Swift 3.  At that point I deferred further work until the time is 
>> right.  I would like to revisit it eventually, but it is clearly out of 
>> scope for Swift 4 as well.
> 
> Did you get as far as putting up anywhere to look at?
> 
> It may be relevant to Swift 

Re: [swift-evolution] [Manifesto] Ownership

[Michel Fortin via swift-evolution]

Le 17 févr. 2017 à 3:25, John McCall via swift-evolution 
 a écrit :

> func endScope(_ value: T) -> () {}

Just to be sure, that is the same thing as `move` where you to discard the 
return value, right?

let something = make()
endScope(something)

vs.

let something = make()
_ = move(something)

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 16:28, Matthew Johnson  wrote:
> 
>> 
>> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>>>  wrote:
>>> 
>>> This is an idea I had while working with collections, and is particularly 
>>> inspired by those that use common index types.
>>> 
>>> Consider for example an array; for indices it simply uses an integer, 
>>> however, while this is a perfectly valid type to use it opens up the 
>>> possibility of integers from any number of different sources being passed 
>>> in by mistake and causing run-time errors. The same is true for wrapping 
>>> types that use AnyIndex, or really any type that uses Any* to hide 
>>> underlying types, as on the surface all AnyIndex instances give the 
>>> illusion of being compatible when they're not, and will only produce errors 
>>> at run-time when a conflict arises.
>>> 
>>> The idea to combat this is simple; a new attribute that can be applied to a 
>>> typealias, my working name is @unique, but there's probably a much better 
>>> name for it. When applied to a type-alias it indicates to the type-checker 
>>> that the type being aliased should be treated as a unique type outside of 
>>> the scope in which it is declared.
>> 
>> I've encountered the same problem in essentially the same place, so I'd like 
>> to see a solution too.
>> 
>> This sounds like a slight variation on what, in previous discussions, has 
>> been called `newtype`. IIRC, one of the reasons we've never done `newtype` 
>> is that it's not clear which features you want to bring over from the base 
>> type, or which types should be used for things like operators. (If you have 
>> `func + (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, 
>> rhs: Index) -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
>> 
>> I'd like to suggest a design that I don't think has been considered before. 
>> Currently, if the first type in an enum's inheritance clause is a concrete 
>> type, a set of magical behaviors occur:
>> 
>> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
>> concrete type.
>> * Each case is associated with a raw value, specified by a literal attached 
>> to the case.
>> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
>> 
>> There is currently no equivalent for structs, but I suggest we add one.
>> 
>> If you say:
>> 
>>  struct Index: Int {}
>> 
>> This is automatically equivalent to saying:
>> 
>>  struct Index: RawRepresentable {
>>  var rawValue: Int
>>  init(rawValue: Int) { self.rawValue = rawValue }
>>  }
>> 
>> And a special rule is applied: You may not declare any other stored 
>> properties.
>> 
>> Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
>> that, if you conform to a protocol which the raw type conforms to and then 
>> fail to fulfill its (non-defaulted) requirements, Swift should generate a 
>> member which forwards to the raw value's implementation. It might even be 
>> nice to do the same when an initializer, method, property, or subscript is 
>> declared without providing a body. This would make it easy to decide which 
>> functionality should be exposed and how it should be provided--and it would 
>> provide a partial way to fulfill the frequent request for syntactic sugar 
>> for `Equatable`, `Hashable`, and `Comparable` conformances. (I could imagine 
>> this being generalized later on.)
>> 
>> The main drawback I can see is that the `rawValue` could not be 
>> encapsulated, since the conformance to the public `RawRepresentable` 
>> protocol could not be made private. That might be acceptable in a 
>> convenience feature, or we might decide (perhaps for both `struct`s and 
>> `enum`s) that Swift should generate the members without actually conforming 
>> the type unless explicitly asked to.
> 
> A lot of this is very similar to the protocol-based forwarding proposal I 
> worked on last year.  That proposal would avoid the problems you describe 
> around not being able to properly encapsulate `RawRepresentable`.  It was 
> also able to handle many nuances around forwarding of self and associated 
> type requirements.  It even had an example of how something like `newtype` 
> could be defined in terms of the mechanisms it provides.
> 
> I was mid-way through a second draft when it became clear it was not in scope 
> for Swift 3.  At that point I deferred further work until the time is right.  
> I would like to revisit it eventually, but it is clearly out of scope for 
> Swift 4 as well.

Did you get as far as putting up anywhere to look at?

It may be relevant to Swift 4 stage 2, though I'll admit I'm confused as hell 
what is and is not in scope; but I believe the ABI compatibility stuff has been 
pushed back so it might be accepting more general proposals again, I was going 
to re-submit some of mine that were out

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

[Martin Waitz via swift-evolution]

> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution 
> :
> 
> Thank you for taking the time to put this proposal together Anton!  I really 
> want to see typed throws make it into Swift 4.  This will be a very nice 
> feature to have.
> 
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by 
> making every function have an error type which is by default `Never` for 
> non-throwing functions and `Error` for throwing functions that do not specify 
> an error type.  
> 
> I want to urge you to consider updating the proposal to take this direction 
> now rather than later.  This is a breaking change which means the longer we 
> wait the harder it is to justify.  In fact, I think incorporating the 
> breaking change could increase the chances of it being accepted for Swift 4.  
> Without that it is a purely additive change and those are not being given 
> priority in the Swift 4 release.

Seconded.
With typed throwing function parameters, it makes a lot of sense to be able to 
specify the rethrown type, based on the function given as parameter.

Now some bike-shedding:
I’m not really happy with the `throws(Type)` syntax, as it is too close to 
function parameters.
Why exactly is `throws Type` ambiguous?
The proposal mentions `Type -> Result` as potential thrown type, but functions 
cannot conform to `Error`.
Maybe we can instruct the parser to just allow simple type names between 
`throws` and the arrow `->`.

If that is not possible, we should at least try to find some visual hints to 
separate Error type from function parameters.

E.g. we could use brackets (think of: we are specialising the `throws`):

func foo() throws { … }

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

Re: [swift-evolution] [Draft] open and public protocols

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 3:01 PM, David Sweeris  wrote:
> 
> 
>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> ## Source compatibility
>> 
>> This proposal breaks source compatibility, but in a way that allows for a 
>> simple mechanical migration.  A multi-release stratgegy will be used to roll 
>> out this proposal to provide maximum possible source compatibility from one 
>> release to the next.
>> 
>> 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute 
>> (which can be applied to `public protocol` to give it the new semantics of 
>> `public`).
>> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` with 
>> no annotation.
>> 3. In the subsequent release `public protocol` without annotation becomes an 
>> error.
>> 4. In the subsequent relase `public protocol` without annotation takes on 
>> the new semantics.
>> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are 
>> comfortable making those changes.
> 
> I don’t think we need @nonopen or warnings. IMHO, public/open should have the 
> same semantics and syntax regardless of whether the declaration is a protocol 
> or a concrete type (or a property?).
> 
> Other than that nit, I can’t think of a reason to oppose this. So… +1, 
> because I like making things as consistent as possible (also because of the 
> reasons in the motivation).

The purpose of using `@nonopen` for the migration is to eventually break 
people’s code if they don’t use the migrator and don’t annotate it.  If we 
don’t do that the library may ship a version that unintentionally breaks their 
clients (by continuing to use `public` after its meaning has changed).  

It’s better to break the library before it breaks any clients.  That will 
impact many fewer developers.  This can be handled automatically by the 
migrator and will be a relatively minor inconvenience for developers who don’t 
use it.  That’s better than allowing an accidentally bad version of a library 
from shipping.

> 
> - Dave Sweeris

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

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

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 2:55 PM, Daniel Duan  wrote:
> 
>> 
>> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> • What is your evaluation of the proposal?
>> 
>> +1.  I am extremely confident that this is the right direction to go in.
>> 
>> I really like Brent’s idea for allowing us to distinguish the parameter 
>> label from what he calls the “internal name”.  
>> 
>> In the value subtyping manifesto I recently posted I showed how we can 
>> assign a unique type to each enum case which is a subtype of the enum 
>> itself.  The “internal name” Brent mentions would be the name of the stored 
>> property holding the value if that idea were introduced in the future.  It 
>> has value beyond just documentation and autocompletion.
>> 
> 
> Intriguing! I wish I had read this before I replied to Brent’s. Would it be 
> better to include the internal name addition in the subtyping proposal? 

Yes, I will update it to reflect this as soon as I have a chance.  

Keep in mind that the value subtyping manifesto is not a proposal or proposal 
draft.  It is intended to be a map of possible future proposals which would 
need to be specified in more detail.  If you think any of the topics in that 
manifesto might be relevant to consider in Swift 4 now that we’re in phase 2, 
please reply to that thread.  I’d love to hear your feedback!

> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes.  Several years of experience with Swift are showing that there are many 
>> reasons for this to change.
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Very much so.
>> 
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> I have not.  The approach Swift takes to compound names is unique in my 
>> experience and is a very nice design.
>> 
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> 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-announce mailing list
>>> swift-evolution-annou...@swift.org 
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] open and public protocols

[David Sweeris via swift-evolution]

> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> ## Source compatibility
> 
> This proposal breaks source compatibility, but in a way that allows for a 
> simple mechanical migration.  A multi-release stratgegy will be used to roll 
> out this proposal to provide maximum possible source compatibility from one 
> release to the next.
> 
> 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute 
> (which can be applied to `public protocol` to give it the new semantics of 
> `public`).
> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` with 
> no annotation.
> 3. In the subsequent release `public protocol` without annotation becomes an 
> error.
> 4. In the subsequent relase `public protocol` without annotation takes on the 
> new semantics.
> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are 
> comfortable making those changes.

I don’t think we need @nonopen or warnings. IMHO, public/open should have the 
same semantics and syntax regardless of whether the declaration is a protocol 
or a concrete type (or a property?).

Other than that nit, I can’t think of a reason to oppose this. So… +1, because 
I like making things as consistent as possible (also because of the reasons in 
the motivation).

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

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

[Daniel Duan via swift-evolution]

> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>  • What is your evaluation of the proposal?
> 
> +1.  I am extremely confident that this is the right direction to go in.
> 
> I really like Brent’s idea for allowing us to distinguish the parameter label 
> from what he calls the “internal name”.  
> 
> In the value subtyping manifesto I recently posted I showed how we can assign 
> a unique type to each enum case which is a subtype of the enum itself.  The 
> “internal name” Brent mentions would be the name of the stored property 
> holding the value if that idea were introduced in the future.  It has value 
> beyond just documentation and autocompletion.
> 

Intriguing! I wish I had read this before I replied to Brent’s. Would it be 
better to include the internal name addition in the subtyping proposal? 

>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes.  Several years of experience with Swift are showing that there are many 
> reasons for this to change.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Very much so.
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I have not.  The approach Swift takes to compound names is unique in my 
> experience and is a very nice design.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> 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-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Daniel Duan via swift-evolution]

Hi Brent,

> On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 17, 2017, at 7:26 PM, John McCall  wrote:
>> 
>>  Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
>> 
>>  • What is your evaluation of the proposal?
> 
> I'm torn. Being able to handle the associated value as a tuple is very 
> convenient, but I also want the argument list features described here. In 
> practice, my own enums tend to end up using argument-like parameter labels, 
> which works better when constructing and pattern-matching, but worse when 
> extracting values.
> 
> I think I'd like to ask for two changes. One is probably easy; the other is a 
> bit of a stretch.
> 
> Easy: Cases should allow internal names for documentation and autocompletion.
> 
>   enum SQLError: Error {
>   …
>   case valueInvalid(_ underlying: Error, for key: SQLColumnKey, 
> in statement: SQLStatement)
>   …
>   }
>   …
>   throw SQLError.valueInvalid(error, for: key, in: statement)
>   …
>   switch sqlError {
>   case let .valueInvalid(<#underlying#>, for: <#key#>, in: <#statement#>):
>   …
>   }
>   …
> 

A very natural conclusion if one wants to use enum constructors like real 
functions. When I considered this, my reaction to it myself was that the 
internal name may not be very useful in a meaningful way. In pattern matching, 
for example, the variables declared in the pattern are the counterpart of 
internal name. Using the would-be external labels for associated values’ labels 
(hey, they are both called “labels”!). The last thing to note: we can add 
internal name later without making a breaking change.

IMO this is worth considering if the community consider it valuable.

> Stretch: There should be a way to extract the associated values during a 
> pattern match as a tuple. Sketch (with strawman syntax):
> 
>   // Different forms of the same case statement:
>   case let .valueInvalid(underlying, for: key, in: statement):
>   
>   case let params in . valueInvalid:
> 
>   case let params in . valueInvalid(_:for:in:):
> 
>   case let (underlying, key, statement) in . valueInvalid:
> 
>   case let (underlying, key, statement) in . valueInvalid(_:for:in:):

Someone brought this up in the draft discussion as well. I prefer to delay this 
feature until we have a clearer story on “splats”. Since this is “splat” in 
reverse, the syntax could be related. 

> 
> Other than these things, I'm pretty happy with this proposal. I agree with 
> the ideas of treating the labels as part of the case name, making them more 
> usable as functions, and supporting default values.

>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes—the issues described in the "Motivation" section are pretty ugly.
> 
>>  • 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?
> 
> Not really in-depth, but I did put some thought into it.
> 
> -- 
> 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] [Draft] open and public protocols

[Matthew Johnson via swift-evolution]

Now that we’re in phase 2 I’d like to officially propose we introduce `open` 
protocols and require conformances to  `public` protocols be inside the 
declaring module.  Let’s use this thread for feedback on the official proposal. 
 After a healthy round of discussion I’ll open a PR to submit it for review.


# Feature name

* Proposal: [SE-](-open-public-protocols.md)
* Authors: [Matthew Johnson](https://github.com/anandabits)
* Review Manager: TBD
* Status: **Awaiting review**

## Introduction

This proposal introduces `open protocol` and changes the meaning of `public 
protocol` to match the meaning of `public class` (in this case, conformances 
are only allowed inside the declaring module).

The pitch thread leading up to this proposal was: [consistent public access 
modifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031653.html)

## Motivation

A general principle the Swift community has adopted for access control is that 
defaults should reserve maximum flexibility for a library.  The ensures that 
any capabilities beyond mere visibility are not available unless the author of 
the library has explicitly declared their intent that the capabilities be made 
available.  Finally, when it is possible to switch from one semantic to another 
without breaking clients (but not vice-versa) we should prefer the more 
forgiving (i.e. fixable) semantic as the (soft) default.

`public` is considered a "soft default" in the sense that it is the first 
access modifier a user will reach for when exposing a declaration outside of 
the module.  In the case of protocols the current meaning of `public` does not 
meet the principle of preserving maximum flexibility for the author of the 
library.  It allows users of the library to conform to the protocol.

There are good reasons a library may not wish to allow users to add 
conformances to a protocol.  For example, it may not wish to expose the 
conforming concrete types.  While similar behavior could be accomplished with 
an enum if cases could be private, that requires an implementation to use 
switch statements rather than polymorphism.

Even if all the conforming types are also public there are cases where 
polymorphism is the preferred implementation.  For example, if the set of 
conforming types is not expected to be fixed (despite all being inside the 
library) the authors may not want to have to maintain switch statements every 
time they need to add or remove a confroming type which would be necessary if 
an enum were used instead.  Polymorphism allows us to avoid this, giving us the 
ability to add and remove conforming types within the implementation of the 
library without the burden of maintaining switch statements.

Aligning the access modifiers for protocols and classes allows us to specify 
both conformable and non-conformable protocols, provides a soft default that is 
consistent with the principle of (soft) defaults reserving maximum flexibility 
for the library, and increases the overall consistency of the language by 
aligning the semantics of access control for protocols and classes.

The standard library currently has at least one protocol (`MirrorPath`) that is 
documented as disallowing client conformances.  If this proposal is adopted it 
is likely that `MirrorPath` would be declared `public protocol` and not `open 
protocol`.

Jordan Rose has indicated that the Apple frameworks also include a number of 
protocols documented with the intent that users do not add conformances.  
Perhaps an importer annotation would allow the compiler to enforce these 
semantics in Swift code as well.

## Proposed solution

The proposed solution is to change the meaning of `public protocol` to disallow 
conformances outside the declaring module and introduce `open protocol` to 
allow conformances outside the decalring module (equivalent to the current 
meaning of `public protocol`).

## Detailed design

The detailed design is relatively straightforward but there are three important 
wrinkles to consider.

### User refinement of public protocols

Consider the following example:

```swift
// Library module:
public protocol P {}
public class C: P {}

// User module:
protocol User: P {}
extension C: User {}
```

The user module is allowed to add a refinement to `P` because this does not 
have any impact on the impelementation of the library or its possible 
evolution.  It simply allows the user to write code that is generic over a 
subset of the conforming types provided by the library.

### Public protocols with open conforming classes

Consider the following example:

```swift
public protocol P P{}
open class C: P {}
```

Users of this module will be able to add subclasses of `C` that have a 
conformance to `P`.  This is allowed becuase the client of the module did not 
need to explicitly declare a conformance and the module has explicitly stated 
its intent to allow subclasses of `C` with the `open` access modifier.

### Open pr

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

[Martin Waitz via swift-evolution]

> 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
>  
> 
> 
I haven’t followed the discussion too closely, so I’m sorry if this has already 
been answered:
What’s the rationale for selecting this proposal over the alternatives?
Especially with the upcoming Ownership Manifesto, value mutation may be solved 
much more easily.
Should we invest some more time into exploring the `modify` declaration for 
dictionaries?

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

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

[Daniel Duan via swift-evolution]

Hi Slava,

> On Feb 18, 2017, at 12:30 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> +1, two small questions:
> 
> - If two cases have the same base name but different full names, will 
> matching on the base name match both cases, or will it be an error?

An error.

> - What are the memory layout optimizations described here? From a first 
> glance this looks purely syntactic.

Nothing has stopped us from optimizing the layout further by stop using a 
tuple. In that sense this proposal is purely syntactic indeed. I got this idea 
from Joe. So I’ll just quote him here :P

“...makes it easier to allow layout optimization, since the layout of each 
payload would be unique to the enum instead of having to play double duty as a 
tuple. Since tuples are structural types and can be dynamically passed into 
generic contexts we're constrained by the limitations of value witness tables 
in laying them out; no overlapping spare bits or anything like that."

> 
> Slava
> 
>> On Feb 17, 2017, at 7:26 PM, John McCall via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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?
>>  • 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
> 
> ___
> 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

[Karl Wagner via swift-evolution]

>   • What is your evaluation of the proposal?

+1

I assume the “SignedNumber” protocol is the same as the existing one in the 
standard library. That is to say, Strideable.Stride will now conform to Number 
and have operators.

Also minor nitpick, would it be too onerous to require Number.Magnitude to be 
Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.

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

Sure is

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

Yup

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

Nope

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

Followed previous discussions, read proposal twice.

- Karl

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

Re: [swift-evolution] [Pitch] @testable private members

[thislooksfun via swift-evolution]

Whoops, accidentally sent this off-list.

-thislooksfun (tlf)

> On Feb 18, 2017, at 12:26 PM, thislooksfun  wrote:
> 
> Big +1 from me. I see no point in having to elevate access just to make sure 
> everything is working.
> 
> -thislooksfun (tlf)
> 
>> On Feb 18, 2017, at 12:14 PM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> When writing unit tests sometimes it is necessary to artificially elevate a 
>> member to `internal` in order to make it visible to unit tests where it 
>> could otherwise be `private` or `fileprivate`.  We could introduce an 
>> `@testable` attribute that could be applied anywhere an access modifier is 
>> used.  This attribute would elevate the access modifier to `internal` when 
>> the module is imported using the `@testable import MyModule` syntax in a 
>> test suite.
>> 
>> Is this something that others have interest in?  Is it something that might 
>> be considered for Swift 4 now that phase 2 has begun?
>> 
>> Matthew
>> ___
>> 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] [Pitch] @testable private members

[Matthew Johnson via swift-evolution]

When writing unit tests sometimes it is necessary to artificially elevate a 
member to `internal` in order to make it visible to unit tests where it could 
otherwise be `private` or `fileprivate`.  We could introduce an `@testable` 
attribute that could be applied anywhere an access modifier is used.  This 
attribute would elevate the access modifier to `internal` when the module is 
imported using the `@testable import MyModule` syntax in a test suite.

Is this something that others have interest in?  Is it something that might be 
considered for Swift 4 now that phase 2 has begun?

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

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

[Karl Wagner via swift-evolution]

> 
> - What are the memory layout optimizations described here? From a first 
> glance this looks purely syntactic.

The compiler could “refactor” the payloads among all enum cases to maximise 
overlapping. If you know that an enum’s payload always contains a 
reference-counted or shared object, or that a element is always at a given 
position in the payload, you can operate on the payload’s elements without 
needing to switch.

(crude example)

enum EditorMode {
case .textEditor(UIViewController)
case .imageEditor(UIViewController)

// This would reduce to just returning the payload without switching.
// We could even think about generating a “EditorMode.0 : UIViewController” 
accessor

var editorController: UIViewController {
  switch self { 
  case .textEditor(let t): return t
  case .imageEditor(let i): return i
}
}
}

- Karl

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

Re: [swift-evolution] [Pitch] Refactor Metatypes

[Adrian Zubarev via swift-evolution]

The problem I was describing is about nested types named .Type, indeed. 
Assuming the proposal would go with Type, then it means you _might_ be able 
to create nested types called Type, but you always would need to call if 
through the whole namespace (e.g. A.B.Type). That is a huge downside.

Metatype on the other hand describes exactly what that _thing_ really is.

Currently on a different branch I added this important note to the 
alternatives, but I’d rather use these types for the whole proposal.

Assuming that the accepted proposal decides to use Metatype, AnyMetatype 
over Type and AnyType would imply that the type Type would no longer be 
ambiguous to use in custome modules. However, such naming choice will affect 
the type(of:) function. It might be necessary to align the function name to 
metatype(of:) to avoid any confusion, which will result in another breaking 
change. Alternatively we could leave the function as func type(of instance: 
T) -> AnyMetatype.
If we’re going for breaking changes again than I’d prefer to align the magical 
type(of:) function to metatype(of:).

I’d love to hear more input on this.



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 17:00:27, Anton Zhilin (antonyzhi...@gmail.com) schrieb:


Type is a bad name for a public type:  
FooType is almost always a better name. Libraries that describe “just types”, 
Swift types, can as well use  
Metatype or  
Mirror or something.
For nested types, like  
Foo.Type, in the meaning of “type of  
Foo“,  
Type can’t be used even now.
I’d give up on  
Type name for the greater future of metatypes.

2017-02-18 16:28 GMT+03:00 Adrian Zubarev :

Personally I’d prefer Metatype and AnyMetatype to get rid of the 
restriction where you mostly cannot create custom types called Type, which 
annoys me a lot. Sometimes Kind as a good workaround but there are times where 
Kind doesn’t fit. :/

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

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

[Matthew Johnson via swift-evolution]

>   • What is your evaluation of the proposal?

+1.  I am extremely confident that this is the right direction to go in.

I really like Brent’s idea for allowing us to distinguish the parameter label 
from what he calls the “internal name”.  

In the value subtyping manifesto I recently posted I showed how we can assign a 
unique type to each enum case which is a subtype of the enum itself.  The 
“internal name” Brent mentions would be the name of the stored property holding 
the value if that idea were introduced in the future.  It has value beyond just 
documentation and autocompletion.

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

Yes.  Several years of experience with Swift are showing that there are many 
reasons for this to change.

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

Very much so.

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

I have not.  The approach Swift takes to compound names is unique in my 
experience and is a very nice design.

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

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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Karl Wagner via swift-evolution]

> On 18 Feb 2017, at 16:27, Karl Wagner  wrote:
> 
> - I wonder if we could try something more ambitious. Since the list of thrown 
> errors is resilience-breaking for the function, it is only beneficial for 
> versioned and @inlineable functions. They should not be able to add new 
> errors (they can remove them though, since errors are intended to be switched 
> over). I wonder if we couldn’t introduce a small pattern grammar for our 
> structured comments (isolated from the rest of the language) - it would be 
> optional, but if you do list your errors, the compiler would validate that 
> you do it exhaustively. Some patterns I would like are:
> 
> // - throws: - MyError.{errorOne, errorThree, errorFive}: Something bad  
> || considered exhaustive
> @inlineable public func canFail() throws {}
> 
> // - throws: - OpeningError: Computer says no... || considered 
> exhaustive if OpeningError is versioned or @fixed
> //   - * || other errors, 
> requires “catch-all” by external callers
> @inlineable public func canFail2() throws {}
> 
> If we want to get really clever, we can have the compiler automatically 
> generate those error-lists for internal functions, so you would automatically 
> get exhaustive error-handling within your own module.
> 
> - Karl

Just to rephrase this a little bit.

- The list of thrown errors would not be part of the function’s signature. 
Instead, there is an ABI invariant that it throws an Error, and that it remains 
"switch-compatible". That’s a loose definition, but it covers things like 
throwing non-public Errors and later making them public while retaining ABI 
compatibility.
- It’s up to the library developer to maintain that invariant. They can remove 
errors, refine errors (e.g. “MyError” -> “MyError.{errorOne, errorThree}”), 
hide or reveal previously-hidden errors.
- If the errors are listed exhaustively, the compiler will generate an implicit 
catch-all to trap in case the library violates this invariant. This means they 
can become more specific while retaining ABI compatibility.

- We would put this information in the structured comments, because it can get 
long and complex and is always optional
- The compiler would ensure that their documentation is accurate, as it does 
any other part of the language.

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

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

[Matthew Johnson via swift-evolution]

Thank you for taking the time to put this proposal together Anton!  I really 
want to see typed throws make it into Swift 4.  This will be a very nice 
feature to have.

I noticed that you included Joe Groff’s idea of replacing `rethrows` by making 
every function have an error type which is by default `Never` for non-throwing 
functions and `Error` for throwing functions that do not specify an error type. 
 

I want to urge you to consider updating the proposal to take this direction now 
rather than later.  This is a breaking change which means the longer we wait 
the harder it is to justify.  In fact, I think incorporating the breaking 
change could increase the chances of it being accepted for Swift 4.  Without 
that it is a purely additive change and those are not being given priority in 
the Swift 4 release.


> On Feb 18, 2017, at 6:54 AM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> I’ve created a proposal draft, copy-pasting some parts from David Owens’ 
> proposal.
> Here it is .
> 
> I had to make one addition, which hasn’t been discussed yet. Look at Multiple 
> throwing calls 
> 
>  section. Is this feature controversal, or it’s fine to keep in the proposal? 
> Is it feasible from implementation point of view?
> 
> ___
> 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] [Pre-Proposal] Type Aliases as Pseudo-Types

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 4:54 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> This is an idea I had while working with collections, and is particularly 
>> inspired by those that use common index types.
>> 
>> Consider for example an array; for indices it simply uses an integer, 
>> however, while this is a perfectly valid type to use it opens up the 
>> possibility of integers from any number of different sources being passed in 
>> by mistake and causing run-time errors. The same is true for wrapping types 
>> that use AnyIndex, or really any type that uses Any* to hide underlying 
>> types, as on the surface all AnyIndex instances give the illusion of being 
>> compatible when they're not, and will only produce errors at run-time when a 
>> conflict arises.
>> 
>> The idea to combat this is simple; a new attribute that can be applied to a 
>> typealias, my working name is @unique, but there's probably a much better 
>> name for it. When applied to a type-alias it indicates to the type-checker 
>> that the type being aliased should be treated as a unique type outside of 
>> the scope in which it is declared.
> 
> I've encountered the same problem in essentially the same place, so I'd like 
> to see a solution too.
> 
> This sounds like a slight variation on what, in previous discussions, has 
> been called `newtype`. IIRC, one of the reasons we've never done `newtype` is 
> that it's not clear which features you want to bring over from the base type, 
> or which types should be used for things like operators. (If you have `func + 
> (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, rhs: Index) 
> -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
> 
> I'd like to suggest a design that I don't think has been considered before. 
> Currently, if the first type in an enum's inheritance clause is a concrete 
> type, a set of magical behaviors occur:
> 
> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
> concrete type.
> * Each case is associated with a raw value, specified by a literal attached 
> to the case.
> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
> 
> There is currently no equivalent for structs, but I suggest we add one.
> 
> If you say:
> 
>   struct Index: Int {}
> 
> This is automatically equivalent to saying:
> 
>   struct Index: RawRepresentable {
>   var rawValue: Int
>   init(rawValue: Int) { self.rawValue = rawValue }
>   }
> 
> And a special rule is applied: You may not declare any other stored 
> properties.
> 
> Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
> that, if you conform to a protocol which the raw type conforms to and then 
> fail to fulfill its (non-defaulted) requirements, Swift should generate a 
> member which forwards to the raw value's implementation. It might even be 
> nice to do the same when an initializer, method, property, or subscript is 
> declared without providing a body. This would make it easy to decide which 
> functionality should be exposed and how it should be provided--and it would 
> provide a partial way to fulfill the frequent request for syntactic sugar for 
> `Equatable`, `Hashable`, and `Comparable` conformances. (I could imagine this 
> being generalized later on.)
> 
> The main drawback I can see is that the `rawValue` could not be encapsulated, 
> since the conformance to the public `RawRepresentable` protocol could not be 
> made private. That might be acceptable in a convenience feature, or we might 
> decide (perhaps for both `struct`s and `enum`s) that Swift should generate 
> the members without actually conforming the type unless explicitly asked to.

A lot of this is very similar to the protocol-based forwarding proposal I 
worked on last year.  That proposal would avoid the problems you describe 
around not being able to properly encapsulate `RawRepresentable`.  It was also 
able to handle many nuances around forwarding of self and associated type 
requirements.  It even had an example of how something like `newtype` could be 
defined in terms of the mechanisms it provides.

I was mid-way through a second draft when it became clear it was not in scope 
for Swift 3.  At that point I deferred further work until the time is right.  I 
would like to revisit it eventually, but it is clearly out of scope for Swift 4 
as well.

> 
> -- 
> 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] [Re-Review] SE-0104: Protocol-oriented integers

[Matthew Johnson via swift-evolution]

> 
>   • What is your evaluation of the proposal?

+1.  Very nice!


>   • 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?

Very much so.

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

Unfortunately, no.

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

A quick read this time.  I read prior versions in depth.

> 
> 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

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

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

[Matthew Johnson via swift-evolution]

> What is your evaluation of the proposal?
+1.

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

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

> 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 read.

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

Re: [swift-evolution] [Manifesto] Ownership

[Matthew Johnson via swift-evolution]

Hi John,

This is fantastic!  I’ve been eagerly anticipating this.  It looks very much as 
I was hoping it would.  I can’t wait to see this vision come to life!

You only show a mutating generator example.  Do you also plan to allow shared 
generators?

One topic you don’t touch on that feels related is the ability to use RAII and 
rely on deferred deinit to ensure an owned resource isn’t released before the 
scope exits.  I can imagine something like `defer let resource = MyResource()`. 
 It may also be interesting to support “defer only” types to force a compiler 
error where non-deferred use would be incorrect.  What do you think?

> On Feb 17, 2017, at 11:08 AM, John McCall via swift-evolution 
>  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
>  
> 
> 
> 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] Implicit conversion between primitive types

[Xiaodi Wu via swift-evolution]

The idea of "f for Float" has been raised here. Core team members have said
that it's been explicitly avoided in Swift on purpose, because in their
judgment it has low readability. Instead of "5.0f" you write "5 as Float".

(Unless I'm mistaken, you can also change the default floating point type
to Float in your own code.)

As to promotion for primitive values, it's something that the core team has
said they're aware of and requires design. However, as Matthew said, Float
could be promoted to Double but never vice versa with that feature.

On Sat, Feb 18, 2017 at 09:56 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 18, 2017, at 7:23 AM, Milos Jakovljevic via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Are there are any plans of adding implicit conversion between primitive
> types?
>
> For example
>
> var float = 5.0
>
> func accept(float: Float) {
>print("this is \(float)")
> }
>
>
> I recently posted a manifesto that covers value subtyping:
> https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d.  My
> opinion is that this is the best way to introduce implicit conversions of
> the kind you’re talking about here.
>
> That said, without changing how Swift handles type inference for
> unannotated assignments from literals your example would not work with
> value subtyping.  This is a good thing!  It is because the type of `float`
> is actually `Double` which can represent many values that are not possible
> to represent with a value of type `Float`.
>
> In order to allow this to work the way you intuitively want we would need
> `float` to be assigned some kind of `***Literal` type that keeps track of
> the fact that the value is small enough to be represented by `Float`.  This
> `***Literal` type would be a subtype of `Float`.
>
> This will raise a warning that double cannot be cast to float. Which is
> really frustrating since i always have to add type explicitly or cast it to
> Float.
>
> I would also like to propose to add "f" modifier for floats.
> Any thoughts?
>
> Best,
> Milos Jakovljevic
> ___
> 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] Refactor Metatypes

[Anton Zhilin via swift-evolution]

Type is a bad name for a public type: FooType is almost always a better
name. Libraries that describe “just types”, Swift types, can as well use
Metatype or Mirror or something.
For nested types, like Foo.Type, in the meaning of “type of Foo“, Type
can’t be used even now.
I’d give up on Type name for the greater future of metatypes.

2017-02-18 16:28 GMT+03:00 Adrian Zubarev :

Personally I’d prefer Metatype and AnyMetatype to get rid of the
> restriction where you mostly cannot create custom types called Type,
> which annoys me a lot. Sometimes Kind as a good workaround but there are
> times where Kind doesn’t fit. :/
>
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Implicit conversion between primitive types

[Matthew Johnson via swift-evolution]

> On Feb 18, 2017, at 7:23 AM, Milos Jakovljevic via swift-evolution 
>  wrote:
> 
> Are there are any plans of adding implicit conversion between primitive types?
> 
> For example
> 
> var float = 5.0
> 
> func accept(float: Float) {
>print("this is \(float)")
> }
> 

I recently posted a manifesto that covers value subtyping: 
https://gist.github.com/anandabits/5b7f8e3836387e893e3a1197a4bf144d 
.  My 
opinion is that this is the best way to introduce implicit conversions of the 
kind you’re talking about here.

That said, without changing how Swift handles type inference for unannotated 
assignments from literals your example would not work with value subtyping.  
This is a good thing!  It is because the type of `float` is actually `Double` 
which can represent many values that are not possible to represent with a value 
of type `Float`.  

In order to allow this to work the way you intuitively want we would need 
`float` to be assigned some kind of `***Literal` type that keeps track of the 
fact that the value is small enough to be represented by `Float`.  This 
`***Literal` type would be a subtype of `Float`.

> This will raise a warning that double cannot be cast to float. Which is 
> really frustrating since i always have to add type explicitly or cast it to 
> Float. 
> 
> I would also like to propose to add "f" modifier for floats.
> Any thoughts?
> 
> Best,
> Milos Jakovljevic
> ___
> 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

[Karl Wagner via swift-evolution]

> On 17 Feb 2017, at 19:45, 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.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


So, I’m not sure about what was decided last time, but my issues with this are:

- The thrown error type will become part of the ABI of the function. If you 
change the type of Error that is thrown, callers may not catch it. At the same 
time, if we make enums resilient by default and only allow specifying a single 
entire type, you will basically need one Error enum per function and it will 
need to be @fixed if you actually want to remove the catch-all block. Otherwise:

// Let’s say this isn’t @fixed...
enum CanFailError {
errorOne
errorTwo
}

func canFail() throws(CanFailError) { /* … */ }

do { try canFail() }
catch CanFailError {
switch error {
case .errorOne: /* handle error one */
case .errorTwo: /* handle error two */
default:/* handle possible new errors in later versions of the 
library */
}
}

do { try canFail() }
catch .errorOne { /* handle error one */ }
catch .errorTwo { /* handle error two */  }
catch   { /* handle possible new errors in later versions of the 
library */ }

- I usually have _semantic_ namespaces for Errors, rather than single types per 
implementation pattern. If we are adding strong annotations about which errors 
can be thrown, I’d quite like to incorporate that pattern. For example:

extension File {
@fixed enum OpeningError { 
case .invalidPath
case .accessDenied  // e.g. asking for write permissions for read-only 
file
}
@fixed enum ReadError {
case .invalidOffset // past EOF
case .deviceError   // probably worth aborting the entire operation the 
read is part of
}

// - throws:
// - .OpeningError if the file can’t be opened
// - .ReadError if the read operation fails
func read(from offset: Int, into buffer: UnsafeBufferPointer) 
throws(OpeningError, ReadError) { /* … */ }
}

- I wonder if we could try something more ambitious. Since the list of thrown 
errors is resilience-breaking for the function, it is only beneficial for 
versioned and @inlineable functions. They should not be able to add new errors 
(they can remove them though, since errors are intended to be switched over). I 
wonder if we couldn’t introduce a small pattern grammar for our structured 
comments (isolated from the rest of the language) - it would be optional, but 
if you do list your errors, the compiler would validate that you do it 
exhaustively. Some patterns I would like are:

// - throws: - MyError.{errorOne, errorThree, errorFive}: Something bad  || 
considered exhaustive
@inlineable public func canFail() throws {}

// - throws: - OpeningError: Computer says no... || considered 
exhaustive if OpeningError is versioned or @fixed
//   - * || other errors, 
requires “catch-all” by external callers
@inlineable public func canFail2() throws {}

If we want to get really clever, we can have the compiler automatically 
generate those error-lists for internal functions, so you would automatically 
get exhaustive error-handling within your own module.

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

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

[Charlie Monroe via swift-evolution]

> On Feb 17, 2017, at 10:56 PM, Xiaodi Wu  wrote:
> 
> 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 
>> mailto: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.

It's not that it's not meant to be called, but to be called from certain 
context. Coming back to a codebase after a while, you don't need to remember 
that method is not meant to be called out of certain context and if you name 
your methods well, you don't really need to go and take a look at what the 
method does, so you might miss this fact since you didn't go and read the docs. 
Xcode wouldn't even offer you this method in autocompletion if it were marked 
protected.

I'm not saying that this is something the Swift community can't live without, 
but it's of a huge convenience for newcomers to a project for whom the IDE 
wouldn't offer methods that should not get called from outside of the enclosing 
type.

I believe we are running to a point where the community is divided into two 
major camps - one part that would like to get the access control almost 
eliminated as they don't the see it that much useful; and second part that on 
the other hand would very much like to see extended access control - not by 
files/modules, but by the enclosing type. People are unlikely to switch these 
camps as their view on the subject is mostly shaped by their previous 
experience with working on team projects. 

IMHO, those who have previously worked with other experienced and responsible 
developers are probably advocates of less access control; those who have 
previously worked will less experienced developers are most likely pushing 
forward a more extended access control model.

I've previously worked as a lead developer in a few start-up businesses where 
people came and went and it was unnecessary burden to point to them why they 
shouldn't do something that way, that they overlooked that the member should 
not be invoked out of the enclosing context because they didn't full read 
documentation for that method; when you do this with a 10th person for the 
100th time, you start w

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

[David Rönnqvist via swift-evolution]

I searched thought my code and most uses of fileprivate were for same-file 
extensions which would be solved by #2 as well.

The other usages are mostly "related" types, which could possibly work with #2 
if these were made inner types instead. 

Two examples:
A "Slots" struct with a collection of "Slot" enum values is able to inspect 
fileprivate information about each Slot to expose some external higher level 
functionality on the Slots struct. 

A CollectionObserver class which inherits from an Observer class (same file) 
and is able to inspect and modify detailed fileprivate state. 


So, while #2 would work for me most of the time, I like the ability to put 
related types in the same file and have them expose more functionality to each 
other than they do to the rest of the project. Sort of like a micro (2-3 type) 
submodule.

In the end I find #1 simpler and more flexible.

Regards,
David

> On 15 Feb 2017, at 10:34, Dietmar Planitzer via swift-evolution 
>  wrote:
> 
> I do like approach #2. It would play well with extensions, look very familiar 
> to how private works in other main stream languages and it wouldn’t get in 
> the way of a possible future refinement of extensions to this model:
> 
> a) 1st party extension (extension defined and owned by the type owner): 
> extension is defined in the same module as the base type:
> 
> - allows access to private type properties and functions even if the base 
> type and extension are in different files
> - allows the definition of stored properties for value and class types
> 
> b) 3rd party extension (extension is defined and owned by the _user_ of a 
> type): extension is defined in a parent module and the base type is defined 
> in a sub-module:
> 
> - forbids access to private properties and functions from the imported type
> - forbids the definition of stored properties for value types
> - MAY allow the definition of stored properties on class types (haven’t 
> really convinced myself that this would be a good idea)
> 
> “parent module” would either mean the application that links against a module 
> (what is supported today) but also the parent module of a sub-module 
> (potential future addition).
> 
> 
> Regards,
> 
> Dietmar Planitzer
> 
> 
>> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 14, 2017, at 3:20 AM, David Hart  wrote:
>>> 
>>> 
 On 14 Feb 2017, at 09:25, Goffredo Marocchi  wrote:
 
 I disagree with that as well as I still think we are damaging the language 
 each time we take a known concept (like access levels) and give new 
 meanings to the same keywords. I still look baffled at the redefinition of 
 do and the addition of repeat for example...
 
 Private, the way it was before, was an admittedly curious take on how most 
 languages mean by private and we have jumped through a lot of hoops to 
 justify why we did not start with Java/C++/C# like access control and 
 augmented it instead of redefining things, omitting others, and then 
 constantly pulling the language left and right with not a lot of permanent 
 consensus either way as this discussion and others before show.
>>> 
>>> It's a curious take, but it is a curious take is perfectly coherent with 
>>> Swift extensions. How else would you access private implementation details 
>>> from an extension? But putting it in the same file, instead of having to 
>>> resort to an internal access level.
>> 
>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>> intentionally designed to remain familiar (and thus reuses many keywords 
>> across the language family), it often does so with slightly different 
>> meaning / behavior.  Consider ‘throw’ for example.
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> On 18 Feb 2017, at 14:16, David Rönnqvist via swift-evolution 
>  wrote:
> 
> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>  wrote:
> 
>> +1, two small questions:
>> 
>> - If two cases have the same base name but different full names, will 
>> matching on the base name match both cases, or will it be an error?
> 
> I feel that it would be safer if it was an error. If the developer intends to 
> match both cases, requiring both explicitly is a (slight) inconvenience but 
> it's also very clear about what's going to match. 

Full name matching would also allow a kind of “overloading” which can be very 
desirable in many cases.
Besides full-name matching seems more intuitive correct (compare for example 
case sensitivity).

Rien. 

> 
>> - What are the memory layout optimizations described here? From a first 
>> glance this looks purely syntactic.
>> 
>> Slava
>> 
>>> On Feb 17, 2017, at 7:26 PM, 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?
>>> • 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
>> 
>> ___
>> 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] Refactor Metatypes

[Adrian Zubarev via swift-evolution]

Personally I’d prefer Metatype and AnyMetatype to get rid of the 
restriction where you mostly cannot create custom types called Type, which 
annoys me a lot. Sometimes Kind as a good workaround but there are times where 
Kind doesn’t fit. :/



-- 
Adrian Zubarev
Sent with Airmail

Am 18. Februar 2017 um 10:20:14, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

Yes,  
Any,  
AnyObject,  
AnyType would look nice together. But I’d suggest to do it separately and for 
now, try to push the main proposal for review.

2017-02-17 19:09 GMT+03:00 Adrian Zubarev :

Personally I’d like a shortcut like AnyType, but it won’t work as a typealias, 
because it will create a circle reference between AnyType and AnyType.

However, there is a small possibility that this type might be generalized like 
Any (now possibly AnyObject) directly into the language. That would probably 
allow us to use AnyType as a shortcut to AnyType.

I’m not sure if this should be part of our proposal or not. I’d like to have 
some more feedback from the core team on this one.

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

[swift-evolution] Implicit conversion between primitive types

[Milos Jakovljevic via swift-evolution]

Are there are any plans of adding implicit conversion between primitive types?

For example

var float = 5.0

func accept(float: Float) {
print("this is \(float)")
}

This will raise a warning that double cannot be cast to float. Which is really 
frustrating since i always have to add type explicitly or cast it to Float. 

I would also like to propose to add "f" modifier for floats.
Any thoughts?

Best,
Milos Jakovljevic
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Rönnqvist via swift-evolution]

> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution 
>  wrote:
> 
> +1, two small questions:
> 
> - If two cases have the same base name but different full names, will 
> matching on the base name match both cases, or will it be an error?

I feel that it would be safer if it was an error. If the developer intends to 
match both cases, requiring both explicitly is a (slight) inconvenience but 
it's also very clear about what's going to match. 

> - What are the memory layout optimizations described here? From a first 
> glance this looks purely syntactic.
> 
> Slava
> 
>> On Feb 17, 2017, at 7:26 PM, 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?
>>  • 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
> 
> ___
> 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] Typed throws

[Anton Zhilin via swift-evolution]

I’ve created a proposal draft, copy-pasting some parts from David Owens’
proposal.
Here it is 
.

I had to make one addition, which hasn’t been discussed yet. Look at Multiple
throwing calls

section. Is this feature controversal, or it’s fine to keep in the
proposal? Is it feasible from implementation point of view?
​
___
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]

> Wouldn’t that mean that you couldn’t use your Swift library in Objective-C 
> anymore, at least the error type as an NSError?
> 
That's the meaning of "break with Objective-C" here ;-) — but note that I wrote 
about allowing to do so, not forcing:
Now, we can only declare that something is thrown, and as interoperability is 
quite important, we have to assume it is needed.
As soon as you declare exactly what will be thrown, it should be up to you to 
decide if you need NSError-bridging.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Torin Kwok via swift-evolution]

Proposal link:

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

However, occasionally a constructor might be non-copying on purpose, so we'll 
need a way to disable the warning.
How about the determination method mentioned in the proposal:

... if developers are performing an assignment operation from within an 
initializer between a property declared as @NSCopyingand an instance of a 
protocol conforming class.
That is, there are two key factors determining whether a fixable error or 
warning should be emitted:

If the destination property has been declared as @NSCopying in class definition
If the source value conforms to  protocol
Once both are true, then what compiler can be sure about is that developer 
definitely missed the required manual copy invocation and it would emit either 
an error or a warning correspondingly. Otherwise, compiler would not complain 
of anything and would just leave the decision up to developers.


> On 18 Feb 2017, at 18:16, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 17, 2017, at 3:18 PM, Douglas Gregor  wrote:
>> 
>> 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?
> 
> I think a warning is very appropriate.
> 
> However, occasionally a constructor might be non-copying on purpose, so we'll 
> need a way to disable the warning. A few possibilities:
> 
> * Use .self on the value
> * Parenthesize the value
> * Parenthesize the variable
> 
> I don't favor using compiler magic. Too spooky.
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yeah, that's a pretty easy mistake to make.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes. Swift usually tries to help you avoid mistakes.
> 
>>  • 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?
> 
> Quick reading.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 17, 2017, at 7:26 PM, John McCall  wrote:
> 
>   Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
> 
>   • What is your evaluation of the proposal?

I'm torn. Being able to handle the associated value as a tuple is very 
convenient, but I also want the argument list features described here. In 
practice, my own enums tend to end up using argument-like parameter labels, 
which works better when constructing and pattern-matching, but worse when 
extracting values.

I think I'd like to ask for two changes. One is probably easy; the other is a 
bit of a stretch.

Easy: Cases should allow internal names for documentation and autocompletion.

enum SQLError: Error {
…
case valueInvalid(_ underlying: Error, for key: SQLColumnKey, 
in statement: SQLStatement)
…
}
…
throw SQLError.valueInvalid(error, for: key, in: statement)
…
switch sqlError {
case let .valueInvalid(<#underlying#>, for: <#key#>, in: <#statement#>):
…
}
…

Stretch: There should be a way to extract the associated values during a 
pattern match as a tuple. Sketch (with strawman syntax):

// Different forms of the same case statement:
case let .valueInvalid(underlying, for: key, in: statement):

case let params in . valueInvalid:

case let params in . valueInvalid(_:for:in:):

case let (underlying, key, statement) in . valueInvalid:

case let (underlying, key, statement) in . valueInvalid(_:for:in:):

Other than these things, I'm pretty happy with this proposal. I agree with the 
ideas of treating the labels as part of the case name, making them more usable 
as functions, and supporting default values.

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

Yes—the issues described in the "Motivation" section are pretty ugly.

>   • 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?

Not really in-depth, but I did put some thought into it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 10:54, Brent Royal-Gordon  wrote:
> 
>> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> This is an idea I had while working with collections, and is particularly 
>> inspired by those that use common index types.
>> 
>> Consider for example an array; for indices it simply uses an integer, 
>> however, while this is a perfectly valid type to use it opens up the 
>> possibility of integers from any number of different sources being passed in 
>> by mistake and causing run-time errors. The same is true for wrapping types 
>> that use AnyIndex, or really any type that uses Any* to hide underlying 
>> types, as on the surface all AnyIndex instances give the illusion of being 
>> compatible when they're not, and will only produce errors at run-time when a 
>> conflict arises.
>> 
>> The idea to combat this is simple; a new attribute that can be applied to a 
>> typealias, my working name is @unique, but there's probably a much better 
>> name for it. When applied to a type-alias it indicates to the type-checker 
>> that the type being aliased should be treated as a unique type outside of 
>> the scope in which it is declared.
> 
> I've encountered the same problem in essentially the same place, so I'd like 
> to see a solution too.
> 
> This sounds like a slight variation on what, in previous discussions, has 
> been called `newtype`. IIRC, one of the reasons we've never done `newtype` is 
> that it's not clear which features you want to bring over from the base type, 
> or which types should be used for things like operators. (If you have `func + 
> (lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, rhs: Index) 
> -> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)
> 
> I'd like to suggest a design that I don't think has been considered before. 
> Currently, if the first type in an enum's inheritance clause is a concrete 
> type, a set of magical behaviors occur:
> 
> * The enum is conformed to `RawRepresentable` with a `RawValue` of the 
> concrete type.
> * Each case is associated with a raw value, specified by a literal attached 
> to the case.
> * `init?(rawValue:)` and `var rawValue { get }` are automatically generated.
> 
> There is currently no equivalent for structs, but I suggest we add one.
> 
> If you say:
> 
>   struct Index: Int {}
> 
> This is automatically equivalent to saying:
> 
>   struct Index: RawRepresentable {
>   var rawValue: Int
>   init(rawValue: Int) { self.rawValue = rawValue }
>   }
> 
> And a special rule is applied: You may not declare any other stored 
> properties.
> 
> Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
> that, if you conform to a protocol which the raw type conforms to and then 
> fail to fulfill its (non-defaulted) requirements, Swift should generate a 
> member which forwards to the raw value's implementation. It might even be 
> nice to do the same when an initializer, method, property, or subscript is 
> declared without providing a body. This would make it easy to decide which 
> functionality should be exposed and how it should be provided--and it would 
> provide a partial way to fulfill the frequent request for syntactic sugar for 
> `Equatable`, `Hashable`, and `Comparable` conformances. (I could imagine this 
> being generalized later on.)
> 
> The main drawback I can see is that the `rawValue` could not be encapsulated, 
> since the conformance to the public `RawRepresentable` protocol could not be 
> made private. That might be acceptable in a convenience feature, or we might 
> decide (perhaps for both `struct`s and `enum`s) that Swift should generate 
> the members without actually conforming the type unless explicitly asked to.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

Hmm, that's a very interesting alternative; it's a lot like what we have to do 
now ourselves anyway, plus more flexible overall. I still like the idea of 
being able to do something at the typealias itself purely for convenience, but 
that's something that could always come later.

For example:

typealias Index:Int // shorthand for struct IntIndex: Int {}, typealias 
Index = IntIndex

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

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 17, 2017, at 2:15 PM, Joanna Carter via swift-evolution 
>  wrote:
> 
> 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.

Let's be clear here: Are you thinking of this exclusively as a feature for 
override points, or are you asking for a `protected` feature in general?

I think that a general `protected` feature is not very compatible with Swift's 
extension-based approach, but I could imagine a feature specifically for 
overriding. For example, a class like UIViewController might declare:

open(override) internal func viewDidAppear(_ animated: Bool) { … }
// Or maybe `open internal(call)`? That'd be more like `public 
internal(set)`…

And then public subclasses could override `viewDidAppear(_:)`, and those 
overrides could call `super.viewDidAppear(_:)`, but neither other methods in 
the subclass nor code outside the subclass could call it.

Would that fulfill your needs, or are you really looking for type-based access 
control?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Brent Royal-Gordon via swift-evolution]

> On Feb 18, 2017, at 2:18 AM, Haravikk via swift-evolution 
>  wrote:
> 
> This is an idea I had while working with collections, and is particularly 
> inspired by those that use common index types.
> 
> Consider for example an array; for indices it simply uses an integer, 
> however, while this is a perfectly valid type to use it opens up the 
> possibility of integers from any number of different sources being passed in 
> by mistake and causing run-time errors. The same is true for wrapping types 
> that use AnyIndex, or really any type that uses Any* to hide underlying 
> types, as on the surface all AnyIndex instances give the illusion of being 
> compatible when they're not, and will only produce errors at run-time when a 
> conflict arises.
> 
> The idea to combat this is simple; a new attribute that can be applied to a 
> typealias, my working name is @unique, but there's probably a much better 
> name for it. When applied to a type-alias it indicates to the type-checker 
> that the type being aliased should be treated as a unique type outside of the 
> scope in which it is declared.

I've encountered the same problem in essentially the same place, so I'd like to 
see a solution too.

This sounds like a slight variation on what, in previous discussions, has been 
called `newtype`. IIRC, one of the reasons we've never done `newtype` is that 
it's not clear which features you want to bring over from the base type, or 
which types should be used for things like operators. (If you have `func + 
(lhs: Int, rhs: Int) -> Int`, you don't want `func + (lhs: Index, rhs: Index) 
-> Index`; you want `func + (lhs: Index, rhs: Int) -> Index`.)

I'd like to suggest a design that I don't think has been considered before. 
Currently, if the first type in an enum's inheritance clause is a concrete 
type, a set of magical behaviors occur:

* The enum is conformed to `RawRepresentable` with a `RawValue` of the concrete 
type.
* Each case is associated with a raw value, specified by a literal attached to 
the case.
* `init?(rawValue:)` and `var rawValue { get }` are automatically generated.

There is currently no equivalent for structs, but I suggest we add one.

If you say:

struct Index: Int {}

This is automatically equivalent to saying:

struct Index: RawRepresentable {
var rawValue: Int
init(rawValue: Int) { self.rawValue = rawValue }
}

And a special rule is applied: You may not declare any other stored properties.

Additionally, for both `enum`s and `struct`s with raw types, I would suggest 
that, if you conform to a protocol which the raw type conforms to and then fail 
to fulfill its (non-defaulted) requirements, Swift should generate a member 
which forwards to the raw value's implementation. It might even be nice to do 
the same when an initializer, method, property, or subscript is declared 
without providing a body. This would make it easy to decide which functionality 
should be exposed and how it should be provided--and it would provide a partial 
way to fulfill the frequent request for syntactic sugar for `Equatable`, 
`Hashable`, and `Comparable` conformances. (I could imagine this being 
generalized later on.)

The main drawback I can see is that the `rawValue` could not be encapsulated, 
since the conformance to the public `RawRepresentable` protocol could not be 
made private. That might be acceptable in a convenience feature, or we might 
decide (perhaps for both `struct`s and `enum`s) that Swift should generate the 
members without actually conforming the type unless explicitly asked to.

-- 
Brent Royal-Gordon
Architechies

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

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

[Joanna Carter via swift-evolution]

> 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.

Removal of private in any form would prove problematic for situations where you 
have a "lazy" var that needs to be "reset" e.g.


  var dataScope: DataScope = .all
  {
didSet
{
  if dataScope != oldValue
  {
_fetchedResultsController = nil
  }
}
  }
  
  private var _fetchedResultsController: NSFetchedResultsController?
  
  fileprivate var fetchedResultsController: NSFetchedResultsController?
  {
get
{
  if _fetchedResultsController == nil
  {
// some stuff

if case .filtered(let filter) = self.dataScope
{
  let predicate = NSPredicate(format: "artist.imageName contains[cd] 
%@", filter)
  
  request.predicate = predicate
}

self._fetchedResultsController = 
NSFetchedResultsController(fetchRequest: request,
   
managedObjectContext: DataProvider.sharedInstance.managedObjectContext,
   
sectionNameKeyPath: "day.narrative",
   cacheName: nil)
  }
  
  return _fetchedResultsController
}
  }


This code is used in a public class which is used to provide the dataSource for 
a UITableView, therefore, the only members that should be exposed are the 
relevant methods for fetching data for the cells in the tableView, which are 
declared in a small extension in the same file. Which is why 
fetchedResultsController is fileprivate for access in the extension and 
_fetchedResultsController is private to ensure neither I, nor anyone who takes 
over the code, can call the underscored version, thus failing to lazily 
initialise the var.

--
Joanna Carter
Carter Consulting

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

[swift-evolution] [Pre-Proposal] Type Aliases as Pseudo-Types

[Haravikk via swift-evolution]

This is an idea I had while working with collections, and is particularly 
inspired by those that use common index types.

Consider for example an array; for indices it simply uses an integer, however, 
while this is a perfectly valid type to use it opens up the possibility of 
integers from any number of different sources being passed in by mistake and 
causing run-time errors. The same is true for wrapping types that use AnyIndex, 
or really any type that uses Any* to hide underlying types, as on the surface 
all AnyIndex instances give the illusion of being compatible when they're not, 
and will only produce errors at run-time when a conflict arises.

The idea to combat this is simple; a new attribute that can be applied to a 
typealias, my working name is @unique, but there's probably a much better name 
for it. When applied to a type-alias it indicates to the type-checker that the 
type being aliased should be treated as a unique type outside of the scope in 
which it is declared.

For example:

struct MyCollection : Collection {
@unique typealias Index = Int
var startIndex:Index { return 0 }
…
}

var foo = MyCollection()
var bar = MyCollection()
foo[bar.startIndex] // warning: incompatible types

Although the underlying type is an Int for both collections, and Ints can be 
used internally to satisfy methods/properties of type Index (i.e- within 
MyCollection the concrete type is still Int), externally indices are treated as 
a unique type of MyCollection.Index, that just happens to have all the same 
methods, operators and properties as Int, minimising the risk of passing an 
index from the wrong source.

If you actually want to pass the "wrong" type you can still do it by casting:

foo[bar.startIndex as MyCollection.Index]

Bit verbose, but it makes absolutely clear that you want this to happen, rather 
than it happening by mistake. The same can also be done in reverse (to change 
an index to an Int).

Of course this isn't completely fool-proof, as two different instances of 
MyCollection could still confuse indices as they're of the same 
pseudo-type, but in other cases it reduces the possibility of a mistake. It was 
the recent discussion on the .enumerate() method that reminded me of this, as a 
common mistake is to think that the offsets produced by enumerate are indices, 
just because they happen to be compatible with an Array, this could eliminate 
that as a mistake by forcing developers to see what's actually happening.

Currently to do something like this requires duplicating types, or using 
wrappers around Int just to make it appear to be different; it's not hard as 
such but there's no standard for it, so making it easier and more prevalent is 
desirable.

This shouldn't have any implications to ABI compatibility as it's a 
type-checker only feature (the code should still compile exactly as the same is 
now), but it's a partially source-breaking change in that if Array etc. are 
changed to use this feature then any code relying on Array indices being 
integers will need to add a cast. Since the types are still known to be 
compatible though a mismatch needn't be an error, a warning should suffice, in 
which case the change won't actually prevent compilation of existing code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 17, 2017, at 3:18 PM, Douglas Gregor  wrote:
> 
> 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?

I think a warning is very appropriate.

However, occasionally a constructor might be non-copying on purpose, so we'll 
need a way to disable the warning. A few possibilities:

* Use .self on the value
* Parenthesize the value
* Parenthesize the variable

I don't favor using compiler magic. Too spooky.

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

Yeah, that's a pretty easy mistake to make.

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

Yes. Swift usually tries to help you avoid mistakes.

>   • 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?

Quick reading.

-- 
Brent Royal-Gordon
Architechies

___
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

[Haravikk via swift-evolution]

> On 18 Feb 2017, at 01:45, Joe Groff via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

Solid +1, though like others I disagree with deprecating BitwiseOperations, and 
feel it should be integrated into the protocol hierarchy.

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

Definitely; interpretability of integers and some ambiguity with the types are 
weaknesses in Swift right now, so the improved design should make a big 
difference.

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

Yes.

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

I've been keeping an eye on the discussion and skimmed the proposal again to 
hopefully catch any changes.
___
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

[Rod Brown via swift-evolution]

> What is your evaluation of the proposal?
It’s clearly a concern and one that should be addressed.

A lot of people have bought up the didSet {} property observers are not called 
when things are set here, either. This is true, but unlike property observers, 
these are attributes, and I don’t know of anywhere else where an @attribute 
works in some cases and not in another. It is understandable that people think 
@NSCopying is implemented with compiler magic that should work everywhere, 
rather than built as part of the setter as it currently is, and thus causes 
confusion.

Like others have commented, I am concerned about how our solution works with 
future plans about making NSCopying a property behaviour. Doug Gregor has 
commented that he believes it should be compiler magic, and I respect that 
opinion. I would like the Core Team to ensure that they believe it is entirely 
compatible and in the spirit of Property Behaviours before the compiler magic 
is added, though, if Property Behaviours are still seriously on the cards for 
the future.

If compiler magic is decided against, I think this is a clear spot where there 
should be a warning, and a proposed fixit.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. This is a confusing and easily missed part of the language. While it is 
currently understood that didSet and willSet are not called, it is not clear to 
developers that @NSCopying falls into that same group, and have not noticed it 
anywhere in documentation.

> Does this proposal fit well with the feel and direction of Swift?
I think adding compiler magic is somewhat in opposition to the general trend to 
reduce said magic, but a solution here seems necessary as the current lack of 
clarity is against the 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?
N/A

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading of the proposal, and involved in the initial discussions 
surrounding this issue.___
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

[Torin Kwok via swift-evolution]

Hello Swift community:

Thank you for your reviews for my proposal. As you may have seen, this proposal 
contains two solutions originally:

Compiler magic
Compile-time checking
However even though Solution: Compiler magic is viable, according to some of 
feedback from several reviewers, a developer who is new to Swift would continue 
to be misled by the introduction of the automatic copy behavior:

from Xiaodi Wu xiaodi...@gmail.com :

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.
from David Hart da...@hartbit.com :

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.
For this consideration, I decided to lower the priority of Solution: Compiler 
magic to Alternatives Considered section and leave Solution: Compile-time 
checking as the only one major solution, which suggests that compiler warns the 
developers to call copy manually, rather than implicit magic:

Have compiler emit a compile-time error or warning if developers are performing 
an assignment operation from within an initializer between a property declared 
as @NSCopying and an instance of a protocol conforming class.
I’ve already submitted a pull-request for this modification.

Best,

Torin

smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

+1, two small questions:

- If two cases have the same base name but different full names, will matching 
on the base name match both cases, or will it be an error?
- What are the memory layout optimizations described here? From a first glance 
this looks purely syntactic.

Slava

> On Feb 17, 2017, at 7:26 PM, 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?
>   • 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

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

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

[Rod Brown via swift-evolution]

My 2c:

+1 to reverting private to the Swift 2 meaning and deprecating or using 
fileprivate as an alias for private.

As a framework developer I am constantly deciding backward and forwards to go 
private only to realise that my embracing extensions makes it impossible to 
allow internal properties in private as we don't support stored properties in 
extensions. And, without it, I think private is overly hamstrung when defining 
classes and types with extensions. There is no difference to the compilation 
beyond a rule that the compiler enforces, but can optimise anyway. In which 
case, it is purely communicative, and is therefore practically useless because 
I can't declare the property the method uses in that extension anyway. And 
littering my code with the ugly fileprivate marker is just an annoying 
inconvenience.

+1 also to add in something like 'protected'. It's a hole in the language where 
subclasses may have reasons to access but other types have no business touching.

> On 18 Feb 2017, at 2:38 pm, Jonathan Hull via swift-evolution 
>  wrote:
> 
> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution