Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Rien via swift-evolution]

While I am in favor of this, I do think this should not be a proposal on its 
own, rather it should be folded into a general overhaul of the entire access 
level structure.

Regards,
Rien

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





> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Hi all,
> 
> Here’s a draft proposal following 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
> .
> 
> The idea is simplify Swift’s syntax by getting rid of the `open` access 
> modifier.
> 
> A rendered version of the proposal is available here: 
> https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
> The raw version follows:
> 
> # Remove open Access Modifier
> 
> * Proposal: [SE-](-remove-open-access-modifier.md)
> * Author: [Dimitri Racordon](
> https://github.com/kyouko-taiga
> ), Joanna Carter
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Swift allows classes, methods, properties and subscripts to be marked as 
> `final`, hence disallowing their subclassing/overriding inside **and** 
> outside of their defining module.
> 
> It also features two access levels `open`, which allows an entity to be 
> accessed outside its defining module, and `public`, which gives the same 
> access level the former **and** allows the entity to be subclassed/overridden.
> 
> There's a clear overlap between `open` and `public`, as they essentially 
> represent the same access control within the boundaries of a module, and do 
> not add any benefit from outside them, as `final` is sufficient to prohibit 
> subclassing/overriding.
> 
> Swift-evolution thread: ['Public' class visibility specifiers](
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
> )
> 
> 
> ## Motivation
> 
> Swift has currently 5 access levels, in the form of:
> 
> * `private`, restricting the use of an entity to its enclosing declaration;
> * `fileprivate`, restricting the use of an entity to its defining source file:
> * `internal`, restricting the use of an entity to its defining module;
> * `public`, allowing the entity to be accessed anywhere;
> * `open`, allowing the entity to be accessed anywhere **and** allowing the 
> entity to be subclassed/overridden outside of their defining module.
> 
> From inside a module, `open` and `public` represent exactly the same access 
> level (everything is visible **and** can be subclassed/overridden).
> From outside a module, `public` is actually akin to `final`.
> 
> ```swift
> // Module 1
> // 
> 
> open class OpenClass {}
> public class PublicClass {}
> 
> public final class PublicFinalClass {}
> 
> // The first two classes above have the same access level.
> class derivedFromOpen: OpenClass {}
> class derivedFromPublic: PublicClass {}
> 
> // Module 2
> // 
> 
> class derivedFromOpenOutside: OpenClass {}
> 
> class derivedFromPublicOutside: PublicClass {}
> // Error: Cannot inherit from non-open class ...
> 
> class derivedFromPublicFinalOutside: PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> Hence, the sole use-case of using both `public` and `final` is for an entity 
> that *inside* its defining module should not be subclassed/overridden.
> 
> ```swift
> // Module 1
> // 
> 
> class derivedFromPublicFinal : PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> We believe this use case is rare and not worth the additional complexity of 
> having an `open` access level in the language.
> Besides, `open` is only applicable on classes and class members while the 
> others can be used on other entities (protocols, structures, ...).
> This asymmetry adds to the complexity of an `open` access level.
> 
> In order to simplify the syntax of Swift, we propose to **remove the `open` 
> access modifier**.
> 
> ## Proposal
> 
> Remove the `open` access modifier from Swift.
> 
> ## Source compatibility
> 
> This is a breaking change, as the `open` keyword would disappear from the 
> language.
> However, a fixit would be quite easy to put in place, simply replacing `open` 
> with `public`.
> 
> ## Alternative considered
> 
> Not removing the `open` access modifier from the language and keep the status 
> quo.
> 
> 
> ___
> 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] Fix Private Access Levels

[Rien via swift-evolution]

I don’t know if you want to add this to the ‘criticism’ or not.

1) The information content added by “fileprivate” is questionable because of 
the ‘soft default’:

- People will switch from private to fileprivate without much thought if that 
is desirable or not.
- Other people will default to ‘fileprivate’, necessary or not.


2) Since the difference between ‘fileprivate’ and  ‘private’ only works within 
a file, anybody who is affected by it also has the possibility to change it 
from one to the other. Making the distinction between them rather arbitrary. 
Teams relying on the distinction may find themselves in a place where a 
developer changed private to fileprivate for a quick investigation/solution, 
and forgetting to revert the change before committing his solution. This error 
might remain undiscovered until several revisions later (or never).


3) Mixing scope and file based access levels makes the entire access level 
concept hard to understand.


Regards,
Rien

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





> On 21 Feb 2017, at 07:58, David Hart via swift-evolution 
>  wrote:
> 
> Hello list,
> 
> Matthew Johnson and I have been putting our proposals together towards a 
> joint “let’s fix private access levels” proposal. As the community seems 
> quite divided on the issue, we offer two solutions in our proposal to let the 
> community debate and to let the core team make the final decision.
> 
> I’d like to concentrate this round of feedback on the quality of the 
> proposal, and not on the merits of Solution 1 or 2. thoughts?
> 
> https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/-fix-private-access-levels.md
> 
> David.
> 
> Fix Private Access Levels
> 
>   • Proposal: SE-
>   • Authors: David Hart, Matthew Johnson
>   • Review Manager: TBD
>   • Status: TBD
> Introduction
> 
> This proposal presents the problems the came with the the access level 
> modifications in SE-0025 and presents two community driven solutions to fix 
> them. As a consensus will not easily emerge, this proposal will allow a last 
> round of voting and let the core team decide. Once that is done, this 
> proposal will be ammended to describe the chosen solution.
> 
> Motivation
> 
> Since the release of Swift 3, the access level change of SE-0025 was met with 
> dissatisfaction by a substantial proportion of the general Swift community. 
> Before offering solutions, lets discuss how and why it can be viewed as 
> actiely harmful, the new requirement for syntax/API changes.
> 
> Criticisms of SE-0025
> 
> There are two primary criticism that have been offered.
> 
> The first is that private is a "soft default" access modifier for restricting 
> access within a file. Scoped access is not a good behavior for a "soft 
> default" because it is extremely common to use several extensions within a 
> file. A "soft default" (and therefore private) should work well with this 
> idiom. It is fair to say that changing the behavior of private such that it 
> does not work well with extensions meets the criteria of actively harmful in 
> the sense that it subtly encourages overuse of scoped access control and 
> discourages the more reasonable default by giving it the awkward name 
> fileprivate.
> 
> The second is that Swift's system of access control is too complex. Many 
> people feel like restricting access control to scopes less than a file is of 
> dubious value and therefore wish to simplify Swift's access control story by 
> removing scoped access. However, there are many others who like the ability 
> to have the compiler verify tighter access levels and believe it helps make 
> it easier to reason about code which is protecting invariants.
> 
> Detailed design
> 
> Both authors agree that the private keyword should be reverted back to its 
> Swift 2 file-based meaning, resolving the first criticism. But the authors 
> disagree on what should be done about the scoped access level and the 
> following solutions represent the two main opinions in the community:
> 
> Solution 1: Remove the scoped access level
> 
> Compared to a file-based access level, the scoped-based access level adds 
> meaningful information by hiding implementation details which do not concern 
> other types or extensions in the same file. But is that distinction between 
> private and fileprivate actively used by the larger community of Swift 
> developers? And if it were used pervasively, would it be worth the cognitive 
> load and complexity of keeping two very similar access levels in the 
> language? This solution argues that answer to both questions is no and that 
> the scoped access level should be removed to resolve the complexity criticism.
> 
> This solution has the added advantage of leaving the most design 
> breathing-room for future discussions about access levels 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/02/21 2:16、Jonathan Hull  のメッセージ:

> It is how it interacts with our current access control.  The scope based 
> nature of this will conflict with the file based nature of the stuff left 
> from Swift 2. I am convinced we need to overhaul it in one sweep to fit one 
> metaphor or the other. The more we mix them, the harder it is to wrap your 
> head around.  We can’t keep rehashing it every 6 months, but that is what 
> will happen so long as it stays in this confused state.

How does this conflict?  Moreover, what do you feel we are adding here that 
crosses the line?

This is not a rehash of existing concepts.  We do not deprecate the access 
control scheme, and we don't extend it except to define how symbols can 
indicate they wish to cross/not cross the module boundary.  This is genuinely a 
system to enable modularity at as little cost as we could suss out given 
inspiration from other programming languages. 

tl;dr I don't want to confuse this with the fileprivate debate.  It is possible 
to have physical access control and modularity, they're not mutually exclusive. 
 And the existing access control scheme cannot express the same concepts a real 
module system can, so it's not enough to paint this as a syntactic/physical 
argument.

> 
> I think I would prefer overall trying swift’s file based system because I 
> think we can completely close that with only 1-2 additional concepts (and it 
> would stay conceptually simple).  I would also be fine with switching to a 
> purely type/scope based system with protected, etc…, but I feel like that 
> will need more complexity to get it fully working (e.g. friends), and will 
> end up being a more complex system overall.

The semantics we intend are all there in the proposal.  You can see for 
yourself just how much this will complect the language versus a different 
proposal to redo access entirely.

> 
> Thanks,
> Jon
> 
> 
>>> On Feb 20, 2017, at 11:03 PM, Robert Widmann  
>>> wrote:
>>> 
>>> 
 On Feb 21, 2017, at 2:01 AM, Jonathan Hull  wrote:
 
 
 On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution 
  wrote:
 
 More generally, we need to move access control away as far away from 
 filesystems as possible.  One day, the compiler is going to get ported 
 over to a platform with some bonkers rules that are going to turn around 
 and bite us.
>>> 
>>> This is the key thing which I think is being debated right now.  Swift 2 
>>> defined the file as a unit of compilation and based its elegant system of 
>>> access modifiers on that.  With Swift 3 we have a mix of type/scope based 
>>> modifiers and file based modifiers… and it is super confusing to everyone 
>>> because we have mixed our metaphors.
>>> 
>>> As much as I want modules, I am now convinced that this proposal will only 
>>> make that situation worse.  We need to pick one way (file based) or the 
>>> other (scope based) and commit to it… but either way, it will require a 
>>> larger overhaul to make the system consistent/usable/teachable again.
>>> 
>>> As an analogy, it is like some people are trying to play rock music during 
>>> a classical music concert.  Both are great independently, and different 
>>> people may prefer one or the other… but trying to play them on top of one 
>>> another just results in noise.
>> 
>> Is there anything specifically about this proposal that turns you off, or is 
>> it access control as it stands today?
>> 
>>> 
>>> Thanks,
>>> Jon
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Ownership

[Florent Bruneau via swift-evolution]

> Le 20 févr. 2017 à 23:16, John McCall  a écrit :
> 
> 
>> On Feb 20, 2017, at 4:55 PM, Florent Bruneau  
>> wrote:
>> 
>> 
>>> Le 20 févr. 2017 à 18:22, John McCall  a écrit :
>>> 
 
 On Feb 20, 2017, at 3:40 AM, Florent Bruneau 
  wrote:
 
 Hi John,
 
 I've spent 3 hours reading the manifesto and its really very interesting. 
 Despite the completeness of the included discussion, I have a few 
 comments/concerns.
 
 
 The first one is about the use a Copyable protocol whose conformance must 
 be explicit in the module of the definition of the type. Since copyability 
 shouldn't be modified outside the module that define a type, using a 
 protocol seems a bit weird since AFAIK no other protocol has this kind of 
 constraints. I do understand this enables some idiomatic constructs (like 
 you example where Array conforms to Copyable whenever its elements are 
 copyable), but on the other hand this looks a bit confusing to me. I don't 
 have a better solution, thought.
>>> 
>>> On the one hand, I agree that it's not quite a normal protocol.  On the 
>>> other hand... it's a capability of a type, which is the sort of thing we 
>>> normally express with a protocol.  And because it's not just a single bit — 
>>> because a generic type can conditionally have that capability — if we made 
>>> it not a protocol, we'd just have to re-invent a new mechanism to declare 
>>> that, which would effectively be exactly like the protocol mechanism.
>>> 
>>> I think it's much simpler to say that certain protocols are "policy" 
>>> protocols which are solely up to the author of the type to decide, and that 
>>> external, "retroactive" conformance is only allowed for non-policy 
>>> protocols.
>> 
>> OK. You got me convinced this is probably the most consistent approach. Do 
>> you envision any other policy protocol?
> 
> Not right away, but it's possible that eventually we might want equivalents 
> to some of the other magic protocols in Rust, like Send (which IIRC promises 
> that shared references are thread-safe; that's a similar sort of fundamental 
> property).
> 
 Secondly, in your discussion about variable independence, you talk about 
 logical dependence: variables that are part of the same container. 
 However, whenever this is some concurrency involved, there is also some 
 kind of physical dependence. If you have two values stored physically in 
 memory in the same cache line, and you may want to modify both 
 independently and concurrently (one thread modifies the first value, the 
 second modifies the other one), you have some false sharing which impacts 
 the performance since the actual writes get sequentialized at CPU level. 
 Is there any plan to take this kind of dependencies into account?
>>> 
>>> Well, for one, CPUs may get cleverer here over time.  So I would be 
>>> uncomfortable with cementing this too much in the language.
>> 
>> I don't think this will dramatically improve over time. Moreover, 
>> spatial/physical dependencies may not be specific to cache lines. Another 
>> example would be two boolean packed into two bits. Those variables are not 
>> independent because writing into one of them requires loading and writing 
>> both of them (unless you exclusively use atomic operations).
> 
> Correct.  This design doesn't *completely* give up on allowing bit-packing in 
> classes, but it does make it much harder.  That was considered. :)
> 
>>> The bigger issue is that we don't have a mechanism for positively declaring 
>>> that two variables will be accessed from different threads.  It would be 
>>> disastrous to over-interpret the *possibility* of concurrent access on 
>>> different class properties as a statement of *probability* of concurrent 
>>> access — because the only option there would be, what, to put each property 
>>> on its own cache line?  And cache line sizes change, so this is not 
>>> statically knowable.
>> 
>> This indeed wouldn't be statically checkable, but this could be (maybe as an 
>> opt-in?) dynamically checked.
> 
> Yes, we could certainly do layout dynamically based on the actual cache-line 
> size.  But I hope we can agree that putting every class property on its own 
> cache line by default is not actually acceptable. :)

Putting every value in its own cache line would clearly be a disaster.

>>> I think it's fine for us to design the implementation around the idea that 
>>> it's not necessarily a good idea to access different properties 
>>> concurrently — that's true semantically, not just for performance, because 
>>> obviously that kind of concurrent access to a class takes a lot more care 
>>> and attention to get right — and leave it up to the programmer to respond.
>>> 
>>> Allowing some sort of intelligent layout to prevent cache-line collisions 
>>> 

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

[Russ Bishop via swift-evolution]

> On Feb 20, 2017, at 1:15 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> It’s expected that if you need resilience, then you will throw an “open” 
>>> enum. Essentially, we pass resilience of typed throws on to those who will 
>>> hopefully establish resilience of enums.
>>> 
>>> If you prefer separate error types, then declare a base protocol for all 
>>> your error types and throw a protocol existential. You won’t even need 
>>> default case in switches, if closed protocols make it into the language.
>>> 
>>> I don’t like any solution that is based on comments. I think that compiler 
>>> should always ignore comments.
>>> 
>> I agree.  And in general, this sort of thing is exactly my core concern 
>> about adding typed throws to the language: I am completely certain that many 
>> programmers will add typed throws annotations because they're programmers 
>> and thus, well, probably a little obsessive/compulsive, and they're trying 
>> to precisely document the behavior of their function without necessarily 
>> thinking about the usefulness of that information for their clients and (if 
>> they're writing a library; and really you should almost always be writing 
>> code as if you're writing a library) whether they're actually willing to 
>> commit to that behavior in their interface.  For those programmers, typed 
>> throws is just going to box them in and force them into anti-patterns in the 
>> long run.
>> 
>> In the vast majority of use-cases, clients are not going to exhaustively 
>> handle all errors — they will always have some generic fall-back.  That is 
>> not pessimism, it's actually the natural result of the complicated world we 
>> live in, where code can fail for a huge host of reasons and most callers 
>> won't have meaningful special-case behavior for all of them.  (On most 
>> operating systems, opening a file or a network connection can fail because 
>> you ran out of file descriptors.  You're seriously telling me that you're 
>> going to add a special case to your error logic for that?)  Go look at the 
>> actual error types that people use in most typed-throws situations and try 
>> to tell me I'm wrong — they probably have like twenty alternatives, and 
>> solidly a quarter or more of them will just be embedding some other 
>> arbitrarily-complex or stringly-typed error value.
> 
> I agree that overly specific API specs are a concern. There's still some 
> documentational benefit to a typed error enum, even if it ultimately ends up 
> containing a catch-all case, since it gives you the ability to also enumerate 
> some number of discrete, realistically handleable cases. Sure, your network 
> request running in an XPC service has infinitely many failure cases due to 
> resource constraints or IPC failure or network chaos, but there's usually 
> some number of domain-specific error cases  too. And if we compare the 
> proposed "you get to specify one error enum type" model to, say, Java or 
> C++98's "you get to specify any number of error classes" model, I think that 
> helps steer people away from the most grievous API mistakes in Java land, 
> since instead of listing a closed set of concrete error classes directly in 
> your API signature, you'll list those error cases in your enum definition, 
> and in a resilient world, the enum will be "open" by default to external 
> users, preventing it from being a permanent liability unless the user 
> explicitly opted into closedness.

Realistically there are only rarely actionable error cases and usually only one 
or two; everything else just bubbles up to the top of the current operation 
where you retry or report a permanent failure. If the enum is open then you 
need a default catch-all error handling case anyway, so what benefit is there 
to typed throws that you don’t get with documentation comments?

I’m positive John is right about what will happen in practice.

> 
> In the discussions around Rust's error handling conventions, they recognized 
> this pattern of APIs either raising some number of layer-appropriate errors 
> or carrying forward the failure modes of the layers below them, and they 
> developed a convention for errors wrapping other errors. It would be 
> reasonable to say we should do the same thing as part of the typed errors 
> design. If we were to generalize enum subtyping beyond Optional, that might 
> be one way to go about it, letting an enum wrap its underlying layers' 
> failure cases as subtypes.
> 
> -Joe

Yeah but Rust has a macro system so error-chain makes re-wrapping trivial. A 
simple `chain_err(|| “my new error message”)` is enough to define and “throw” a 
new error that wraps the 

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Rien via swift-evolution]

Maybe we should try to collect what people want from submodules first.

I wanted modules for organisational purposes, however with the arrival of SPM 
that need has been almost completely removed. At least to the point that I do 
not feel that they are absolutely necessary.

Have the people who want modules tried SPM yet?

PS: be prepared for additional access levels requests when modules are 
available… :-0

Regards,
Rien

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





> On 21 Feb 2017, at 02:36, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Okay, lots of people want to have some kind of submodule feature, so I'd like 
> to sketch one out so we can hopefully agree on what submodules might look 
> like.
> 
> ***
> 
> Any group of Swift files can be grouped together to form a submodule. 
> Submodules belong within a particular module, and have a dotted name: If 
> `ModKit` is a module, it might have a submodule called `ModKit.Foo`. 
> Submodules can be nested within one another: `ModKit.Foo.Bar` is a submodule 
> of `ModKit.Foo`, which is a submodule of `ModKit`.
> 
> No new access levels are necessary. `internal` APIs are only visible within 
> the submodule they're declared in; a module cannot see its submodules' 
> `internal` APIs, and a submodule cannot see its parent module's `internal` 
> APIs. If a submodule wants to expose some of its APIs to its parent or 
> sibling modules, it must mark them as `public` or `open`. Then they can 
> import the submodule to see its APIs:
> 
>   import ModKit.Foo
> 
> By default, outside modules cannot import a submodule. But an import in the 
> parent module can be decorated by an access control keyword to allow that:
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs.
>   open import ModKit.Foo
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs, 
>   /// except `open` APIs are treated as `public`.
>   public import ModKit.Foo
> 
> Imports may also be decorated by the `@exported` attribute, which exposes the 
> submodule's APIs as though they were parent module APIs:
> 
>   @exported open import ModKit.Foo
> 
>   @exported public import ModKit.Foo
> 
> (This is sort of half-implemented already in a buggy `@_exported` attribute.)
> 
> Finally, the standard syntax for importing individual symbols can be used to 
> cherry-pick types to treat differently:
> 
>   // Most ModKit.Foo APIs are not importable...
>   import ModKit.Foo
> 
>   // ...but SomeEnum can be imported as public...
>   public import enum ModKit.Foo.SomeEnum
> 
>   // ...SomeClass can be imported as open...
>   open import class ModKit.Foo.SomeClass
> 
>   // And ImportantStruct will import whenever you import ModKit.
>   @exported public import struct ModKit.Foo.ImportantStruct
> 
> (This syntax should be enhanced to allow cherry-picked importing of global 
> functions, constants, and variables.)
> 
> If there are several different `import`s covering the same submodule or 
> submodule symbol, the most permissive one wins.
> 
> (In large projects, `public`, `open`, and `@exported` imports will most 
> likely all be put in a single Policy.swift file or something, but this is not 
> enforced by the language.)
> 
> A submodule may not import any direct parent module (parent, grandparent, 
> etc.), but may import any other submodule in the same module. This list shows 
> permitted imports for a project with four modules/submodules:
> 
>   ModKit
>   - ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Quux
>   - ModKit.Foo
>   - ModKit.Foo.Bar
> 
> However, submodules may not form circular dependencies through imports—if 
> `ModKit.Quux` imports `ModKit.Foo`, then `ModKit.Foo` cannot import 
> `ModKit.Quux`. The `#if canImport()` feature cannot be used to probe for 
> other submodules within the same top-level module you're in.
> 
> At the compiler driver level, a submodule is specified by giving a 
> `-module-name` parameter with a dot in it. When a file is compiled, only the 
> filenames of the other .swift files in the same module are specified, along 
> with .o files for any submodules; then all the .o files within that submodule 
> are linked into a single .o file for the whole submodule. So files in 
> `ModKit.Foo` would be compiled with only the .swift files in `ModKit.Foo` and 
> the .o file for `ModKit.Foo.Bar`; then all the `ModKit.Foo` .o files would be 
> linked into one .o file for the top-level `ModKit` to use. None of 
> `ModKit.Foo`'s .swift files would be included in the command line when 
> 

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Goffredo Marocchi via swift-evolution]

To those people I would say use final or let's change public to mean the 
current open and replace open with 'module'...

I liked open by default and this not needing open in the first place... you 
guys got me here ;).

Sent from my iPhone

> On 21 Feb 2017, at 07:02, David Hart via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I think this proposal will receive a lot of pushback and that the use case 
> for having a class that is subclassable inside its module but not 
> subclassable outside the module is more frequent than you think.
> 
>> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi all,
>> 
>> Here’s a draft proposal following 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html.
>> The idea is simplify Swift’s syntax by getting rid of the `open` access 
>> modifier.
>> 
>> A rendered version of the proposal is available here: 
>> https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
>> The raw version follows:
>> 
>> # Remove open Access Modifier
>> 
>> * Proposal: [SE-](-remove-open-access-modifier.md)
>> * Author: [Dimitri Racordon](https://github.com/kyouko-taiga), Joanna Carter
>> * Status: **Awaiting review**
>> * Review manager: TBD
>> 
>> ## Introduction
>> 
>> Swift allows classes, methods, properties and subscripts to be marked as 
>> `final`, hence disallowing their subclassing/overriding inside **and** 
>> outside of their defining module.
>> 
>> It also features two access levels `open`, which allows an entity to be 
>> accessed outside its defining module, and `public`, which gives the same 
>> access level the former **and** allows the entity to be 
>> subclassed/overridden.
>> 
>> There's a clear overlap between `open` and `public`, as they essentially 
>> represent the same access control within the boundaries of a module, and do 
>> not add any benefit from outside them, as `final` is sufficient to prohibit 
>> subclassing/overriding.
>> 
>> Swift-evolution thread: ['Public' class visibility 
>> specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html)
>> 
>> 
>> ## Motivation
>> 
>> Swift has currently 5 access levels, in the form of:
>> 
>> * `private`, restricting the use of an entity to its enclosing declaration;
>> * `fileprivate`, restricting the use of an entity to its defining source 
>> file:
>> * `internal`, restricting the use of an entity to its defining module;
>> * `public`, allowing the entity to be accessed anywhere;
>> * `open`, allowing the entity to be accessed anywhere **and** allowing the 
>> entity to be subclassed/overridden outside of their defining module.
>> 
>> From inside a module, `open` and `public` represent exactly the same access 
>> level (everything is visible **and** can be subclassed/overridden).
>> From outside a module, `public` is actually akin to `final`.
>> 
>> ```swift
>> // Module 1
>> // 
>> 
>> open class OpenClass {}
>> public class PublicClass {}
>> 
>> public final class PublicFinalClass {}
>> 
>> // The first two classes above have the same access level.
>> class derivedFromOpen: OpenClass {}
>> class derivedFromPublic: PublicClass {}
>> 
>> // Module 2
>> // 
>> 
>> class derivedFromOpenOutside: OpenClass {}
>> 
>> class derivedFromPublicOutside: PublicClass {}
>> // Error: Cannot inherit from non-open class ...
>> 
>> class derivedFromPublicFinalOutside: PublicFinalClass {}
>> // Error: Inheritance from a final class ...
>> ```
>> 
>> Hence, the sole use-case of using both `public` and `final` is for an entity 
>> that *inside* its defining module should not be subclassed/overridden.
>> 
>> ```swift
>> // Module 1
>> // 
>> 
>> class derivedFromPublicFinal : PublicFinalClass {}
>> // Error: Inheritance from a final class ...
>> ```
>> 
>> We believe this use case is rare and not worth the additional complexity of 
>> having an `open` access level in the language.
>> Besides, `open` is only applicable on classes and class members while the 
>> others can be used on other entities (protocols, structures, ...).
>> This asymmetry adds to the complexity of an `open` access level.
>> 
>> In order to simplify the syntax of Swift, we propose to **remove t

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

Sounds distressingly anti-modular!

Really, these kinds of hypotheticals can be addressed when the need arises.  
For now it's a hypothetical fear about a hypothetical issue that isn't 
expressible and highly discouraged by this system - why produce an inverted 
dependency when you could simply rebalance the module by moving the declaration 
into a more appropriate scope?  I can assure you, the proposal seeks 
compatibility with the existing access control modifiers, not to have to 
contort them to fit its own goals.

~Robert Widmann

2017/02/21 2:07、Jonathan Hull  のメッセージ:

> 
>> On Feb 20, 2017, at 10:51 PM, Robert Widmann
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> On Feb 20, 2017, at 6:04 PM, Chris Lattner  wrote:
>> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> It’s expected that if you need resilience, then you will throw an “open” 
>>> enum. Essentially, we pass resilience of typed throws on to those who will 
>>> hopefully establish resilience of enums.
>>> 
>>> If you prefer separate error types, then declare a base protocol for all 
>>> your error types and throw a protocol existential. You won’t even need 
>>> default case in switches, if closed protocols make it into the language.
>>> 
>>> I don’t like any solution that is based on comments. I think that compiler 
>>> should always ignore comments.
>>> 
>> I agree.  And in general, this sort of thing is exactly my core concern 
>> about adding typed throws to the language: I am completely certain that many 
>> programmers will add typed throws annotations because they're programmers 
>> and thus, well, probably a little obsessive/compulsive, and they're trying 
>> to precisely document the behavior of their function without necessarily 
>> thinking about the usefulness of that information for their clients and (if 
>> they're writing a library; and really you should almost always be writing 
>> code as if you're writing a library) whether they're actually willing to 
>> commit to that behavior in their interface.  For those programmers, typed 
>> throws is just going to box them in and force them into anti-patterns in the 
>> long run.
> 
> As you know, I still think that adding typed throws is the right thing to do. 
>  I understand your concern about “the feature could be misused” but the same 
> thing is true about many other language features.

That's fair, but I do think there's an important difference here.  The way I 
see it, typed-throws is really something of an expert feature, not because it's 
at all difficult to use, but the reverse: because it's easy to use without 
really thinking about the consequences.  (And the benefits are pretty subtle, 
too.)  I'm not saying that we should design it to be hard to use, but I think 
maybe it shouldn't immediately suggest itself, and it especially shouldn't come 
across as just a more specific version of throws.

> One thing you didn’t mention is that boxing thrown values in an existential 
> requires allocation in the general case.  This may be unacceptable for some 
> classes of Swift application (in the embedded / deep systems space) or simply 
> undesirable because of the performance implication.

So, the performance implication cuts both ways.  We can design the ABI for 
typed-throws so that, say, the callee initializes some buffer that's passed 
into it.  That's an ABI that will kill some potential allocations in deep 
systems code, no question about it.  But in non-deep-systems code, we generally 
expect that error types will be resilient, which means that there are non-zero 
dynamic costs for allocating space on the stack for the error.  (You can trade 
code size for performance, but the slow path is a function call to trigger the 
runtime layout of the type plus a couple of loads.) That space has to be 
allocated eagerly before the call, so it's paid even in the non-throwing path.  
And I can't think of anything we could do to shift that cost to the throw-site 
without either using a fixed-size buffer, requiring a second stack for the 
thread, or inventing some crazy CC where stack depth can change dynamically 
across a call.

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

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

[Russ Bishop via swift-evolution]

> On Feb 19, 2017, at 12:04 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> It’s expected that if you need resilience, then you will throw an “open” 
> enum. Essentially, we pass resilience of typed throws on to those who will 
> hopefully establish resilience of enums.
> 
You’ve just re-invented the error handling model we have today. 


> If you prefer separate error types, then declare a base protocol for all your 
> error types and throw a protocol existential. 
> 
And now we’ve re-invented Java’s checked exceptions “throws Exception”. 


To what end?

Russ


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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

It’s probably best we explain this motivation under “Alternatives Considered”. 
I forked and updated the gist—feel free to “pull” in the changes… copy 
and paste the document

https://gist.github.com/JadenGeller/c18b1be8e7b9fa3023e98b84fca423ca#multiple-declarations-instead-of-extensions
 


Cheers,
Jaden Geller

> On Feb 20, 2017, at 10:57 PM, Robert Widmann  wrote:
> 
> This was syntax I initially considered, but Jaden swayed me with the idea 
> that we already have an `extension` keyword so we may as well use it to match 
> the rest of the language.  Repeating the `module` declaration also lends 
> itself more to C++-style namespaces, which these are not.  I’m not saying 
> it’s out of the question, far from it. It is an alternative we will keep in 
> mind.
> 
> ~Robert Widmann
> 
>> On Feb 21, 2017, at 1:53 AM, Psycho Hedgehog via swift-evolution 
>> > wrote:
>> 
>> The one thing i don't understand is the point of using extensions to extend 
>> modules across multiple files, why not just allow declaring the submodule in 
>> multiple files?
>> 
>>> Le 20 févr. 2017 à 22:48, Jaden Geller via swift-evolution 
>>> > a écrit :
>>> 
>>> Oh, I see. You’re questioning the motivation of having scope-granularity 
>>> submodules at all! My misunderstanding.
>>> 
>>> I actually hadn’t considered this as added complexity. In my mind, a scoped 
>>> module declaration seems more Swifty than a file module declaration. It 
>>> builds on the existing syntax in Swift for defining other sorts of scopes, 
>>> e.g. types.
>>> 
>>> Cheers,
>>> Jaden Geller
>>> 
 On Feb 20, 2017, at 10:41 PM, Jonathan Hull via swift-evolution 
 > wrote:
 
 I think my question is: Why do we want to allow submodules that are 
 smaller than a file?  What does that give us to offset the added 
 complexity?
 
 Thanks,
 Jon
 
> On Feb 20, 2017, at 6:44 PM, Robert Widmann  > wrote:
> 
> 
>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull > > wrote:
>> 
>> What is the rational for having modules covering only part of a file?  
>> Wouldn’t it be less clutter to have an annotation which worked for the 
>> whole file.  At the very least it would be nice to have an option to 
>> spell it in a way that applies to the whole file.  Otherwise, everything 
>> will be indented another level.
> 
> That is a valid spelling (Rust, IIRC, allows that spelling), but one that 
> is easy to miss sitting in a file and makes it confusing to introduce 
> submodules.  If you include the annotation then define a submodule later 
> down in the file, suddenly you have to remember whether you annotated the 
> file or whether the submodule you’ve just written is going into the 
> top-level module.  See:
> 
> // -module-name=Foo
> // module Foo {
> module Bar; // Shorthand for “This file defines Foo.Bar”
> 
> /* Code */
> 
> // This defines “Foo.Bar.Baz”, but would you know that if it appeared 
> below the fold?
> module Baz {}
> //}
> 
> If anything, this can be added later if evolution converges on it.
> 
>> 
>> I would honestly love to see something which just maps modules to 
>> folders/groups for simplicity sake.
>> 
> 
> There is nothing about this scheme that prevents you from organizing your 
> code this way.  However, modulo that particular method of organization, 
> you don’t really gain much as a user of the language by imposing this 
> restriction.
> 
>> I haven’t thought about it too much yet, so I could easily be missing 
>> something obvious...
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> Good Evening All,
>>> 
>>> Jaden Geller and I have been considering a (sub)module system for Swift 
>>> that would complement the existing language but also provide sorely 
>>> needed modularity.  A draft of the proposal is attached to this email, 
>>> but it can also be read as a gist 
>>>  if 
>>> you desire.
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> Modular Swift
>>> 
>>> Proposal: SE- 
>>> Authors: Robert Widmann , Jaden Geller 
>>> 

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[Dimitri Racordon via swift-evolution]

Hi David,

Thanks for your feedback.
Do you have yourself an example in which a final entity would be clearly needed 
inside its module?

I have seen theoretical use-cases already, but haven’t encountered a 
“real-life” situation that’d need this pattern yet.

On 21 Feb 2017, at 08:02, David Hart 
<da...@hartbit.com<mailto:da...@hartbit.com>> wrote:

I think this proposal will receive a lot of pushback and that the use case for 
having a class that is subclassable inside its module but not subclassable 
outside the module is more frequent than you think.

On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

Hi all,

Here’s a draft proposal following 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html.
 The idea is simplify Swift’s syntax by getting rid of the `open` access 
modifier.

A rendered version of the proposal is available here: 
https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
The raw version follows:


# Remove open Access Modifier

* Proposal: [SE-](-remove-open-access-modifier.md)
* Author: [Dimitri Racordon](https://github.com/kyouko-taiga), Joanna Carter
* Status: **Awaiting review**
* Review manager: TBD

## Introduction

Swift allows classes, methods, properties and subscripts to be marked as 
`final`, hence disallowing their subclassing/overriding inside **and** outside 
of their defining module.

It also features two access levels `open`, which allows an entity to be 
accessed outside its defining module, and `public`, which gives the same access 
level the former **and** allows the entity to be subclassed/overridden.

There's a clear overlap between `open` and `public`, as they essentially 
represent the same access control within the boundaries of a module, and do not 
add any benefit from outside them, as `final` is sufficient to prohibit 
subclassing/overriding.

Swift-evolution thread: ['Public' class visibility 
specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html)


## Motivation

Swift has currently 5 access levels, in the form of:

* `private`, restricting the use of an entity to its enclosing declaration;
* `fileprivate`, restricting the use of an entity to its defining source file:
* `internal`, restricting the use of an entity to its defining module;
* `public`, allowing the entity to be accessed anywhere;
* `open`, allowing the entity to be accessed anywhere **and** allowing the 
entity to be subclassed/overridden outside of their defining module.

From inside a module, `open` and `public` represent exactly the same access 
level (everything is visible **and** can be subclassed/overridden).
From outside a module, `public` is actually akin to `final`.

```swift
// Module 1
// 

open class OpenClass {}
public class PublicClass {}

public final class PublicFinalClass {}

// The first two classes above have the same access level.
class derivedFromOpen: OpenClass {}
class derivedFromPublic: PublicClass {}

// Module 2
// 

class derivedFromOpenOutside: OpenClass {}

class derivedFromPublicOutside: PublicClass {}
// Error: Cannot inherit from non-open class ...

class derivedFromPublicFinalOutside: PublicFinalClass {}
// Error: Inheritance from a final class ...
```

Hence, the sole use-case of using both `public` and `final` is for an entity 
that *inside* its defining module should not be subclassed/overridden.

```swift
// Module 1
// 

class derivedFromPublicFinal : PublicFinalClass {}
// Error: Inheritance from a final class ...
```

We believe this use case is rare and not worth the additional complexity of 
having an `open` access level in the language.
Besides, `open` is only applicable on classes and class members while the 
others can be used on other entities (protocols, structures, ...).
This asymmetry adds to the complexity of an `open` access level.

In order to simplify the syntax of Swift, we propose to **remove the `open` 
access modifier**.

## Proposal

Remove the `open` access modifier from Swift.

## Source compatibility

This is a breaking change, as the `open` keyword would disappear from the 
language.
However, a fixit would be quite easy to put in place, simply replacing `open` 
with `public`.

## Alternative considered

Not removing the `open` access modifier from the language and keep the status 
quo.

___
swift-evolution mailing list
swift-evolution@swift.org<mailto: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][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 2:01 AM, Jonathan Hull  wrote:
> 
> 
>> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> More generally, we need to move access control away as far away from 
>> filesystems as possible.  One day, the compiler is going to get ported over 
>> to a platform with some bonkers rules that are going to turn around and bite 
>> us.
> 
> This is the key thing which I think is being debated right now.  Swift 2 
> defined the file as a unit of compilation and based its elegant system of 
> access modifiers on that.  With Swift 3 we have a mix of type/scope based 
> modifiers and file based modifiers… and it is super confusing to everyone 
> because we have mixed our metaphors.
> 
> As much as I want modules, I am now convinced that this proposal will only 
> make that situation worse.  We need to pick one way (file based) or the other 
> (scope based) and commit to it… but either way, it will require a larger 
> overhaul to make the system consistent/usable/teachable again.
> 
> As an analogy, it is like some people are trying to play rock music during a 
> classical music concert.  Both are great independently, and different people 
> may prefer one or the other… but trying to play them on top of one another 
> just results in noise.

Is there anything specifically about this proposal that turns you off, or is it 
access control as it stands today?

> 
> Thanks,
> Jon
> 

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

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

[David Hart via swift-evolution]

I think this proposal will receive a lot of pushback and that the use case for 
having a class that is subclassable inside its module but not subclassable 
outside the module is more frequent than you think.

> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Hi all,
> 
> Here’s a draft proposal following 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html>.
> The idea is simplify Swift’s syntax by getting rid of the `open` access 
> modifier.
> 
> A rendered version of the proposal is available here: 
> https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
>  
> <https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md>
> The raw version follows:
> 
> # Remove open Access Modifier
> 
> * Proposal: [SE-](-remove-open-access-modifier.md)
> * Author: [Dimitri Racordon](https://github.com/kyouko-taiga 
> <https://github.com/kyouko-taiga>), Joanna Carter
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Swift allows classes, methods, properties and subscripts to be marked as 
> `final`, hence disallowing their subclassing/overriding inside **and** 
> outside of their defining module.
> 
> It also features two access levels `open`, which allows an entity to be 
> accessed outside its defining module, and `public`, which gives the same 
> access level the former **and** allows the entity to be subclassed/overridden.
> 
> There's a clear overlap between `open` and `public`, as they essentially 
> represent the same access control within the boundaries of a module, and do 
> not add any benefit from outside them, as `final` is sufficient to prohibit 
> subclassing/overriding.
> 
> Swift-evolution thread: ['Public' class visibility 
> specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html>)
> 
> 
> ## Motivation
> 
> Swift has currently 5 access levels, in the form of:
> 
> * `private`, restricting the use of an entity to its enclosing declaration;
> * `fileprivate`, restricting the use of an entity to its defining source file:
> * `internal`, restricting the use of an entity to its defining module;
> * `public`, allowing the entity to be accessed anywhere;
> * `open`, allowing the entity to be accessed anywhere **and** allowing the 
> entity to be subclassed/overridden outside of their defining module.
> 
> From inside a module, `open` and `public` represent exactly the same access 
> level (everything is visible **and** can be subclassed/overridden).
> From outside a module, `public` is actually akin to `final`.
> 
> ```swift
> // Module 1
> // 
> 
> open class OpenClass {}
> public class PublicClass {}
> 
> public final class PublicFinalClass {}
> 
> // The first two classes above have the same access level.
> class derivedFromOpen: OpenClass {}
> class derivedFromPublic: PublicClass {}
> 
> // Module 2
> // 
> 
> class derivedFromOpenOutside: OpenClass {}
> 
> class derivedFromPublicOutside: PublicClass {}
> // Error: Cannot inherit from non-open class ...
> 
> class derivedFromPublicFinalOutside: PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> Hence, the sole use-case of using both `public` and `final` is for an entity 
> that *inside* its defining module should not be subclassed/overridden.
> 
> ```swift
> // Module 1
> // 
> 
> class derivedFromPublicFinal : PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> We believe this use case is rare and not worth the additional complexity of 
> having an `open` access level in the language.
> Besides, `open` is only applicable on classes and class members while the 
> others can be used on other entities (protocols, structures, ...).
> This asymmetry adds to the complexity of an `open` access level.
> 
> In order to simplify the syntax of Swift, we propose to **remove the `open` 
> access modifier**.
> 
> ## Proposal
> 
> Remove the `open` access modifier from Swift.
> 
> ## Source compatibility
> 
> This is a breaking change, as the `open` keyword would disappear from the 
> language.
> However, a fixit would be quite easy to put in place, simply replacing `open` 
> with `public`.
> 
> ## Alternative considered
> 
> Not removing the `open` access modifier from the language and keep the status 
> quo.
> 
> ___
> 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][Discussion] Modular Swift

[Jonathan Hull via swift-evolution]

> On Feb 20, 2017, at 10:46 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> More generally, we need to move access control away as far away from 
> filesystems as possible.  One day, the compiler is going to get ported over 
> to a platform with some bonkers rules that are going to turn around and bite 
> us.

This is the key thing which I think is being debated right now.  Swift 2 
defined the file as a unit of compilation and based its elegant system of 
access modifiers on that.  With Swift 3 we have a mix of type/scope based 
modifiers and file based modifiers… and it is super confusing to everyone 
because we have mixed our metaphors.

As much as I want modules, I am now convinced that this proposal will only make 
that situation worse.  We need to pick one way (file based) or the other (scope 
based) and commit to it… but either way, it will require a larger overhaul to 
make the system consistent/usable/teachable again.

As an analogy, it is like some people are trying to play rock music during a 
classical music concert.  Both are great independently, and different people 
may prefer one or the other… but trying to play them on top of one another just 
results in noise.

Thanks,
Jon

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

We avoid forcing users to organize code in such an opinionated manner just to 
please the compiler. Perhaps some submodules deserve a separate file, but I 
think that choice should not be forced by the language. I don’t have data on 
the popularity, but I personally very much dislike the similar restriction Java 
places on public classes and files.

Given that we want Swift to be a fantastic scripting language, I feel we ought 
not place artificial restrictions on code organization. Many scripts are a 
single file (for convenience) but may still benefit from the organization 
modules offer.

Best,
Jaden Geller  

> On Feb 20, 2017, at 10:51 PM, Jonathan Hull  wrote:
> 
> Part of it.  My concern is that the brackets will push everything in the file 
> to the right.
> 
> My question is: What do we get in return for that? (as opposed to a system 
> which acted on the whole file)
> 
> Thanks,
> Jon
> 
> 
>> On Feb 20, 2017, at 10:45 PM, Jaden Geller > > wrote:
>> 
>> Oh, you’re referring to the fact that a submodule under this proposal must 
>> be contained within braces? It would be purely additive to, in the future, 
>> annotate that the outer scope of a file is part of some given submodule.
>> 
>> Consider the following the following straw-man syntax that might be 
>> equivalent to `module Bar { func foo() { } }`:
>> ```
>> module Bar follows // <- at top of file, indicating rest of file is submodule
>> 
>> func foo() { }
>> ```
>> 
>> Does this address your question?
>> 
>> Thanks,
>> Jaden Geller
>> 
>>> On Feb 20, 2017, at 10:39 PM, Jonathan Hull >> > wrote:
>>> 
>>> 
 On Feb 20, 2017, at 6:42 PM, Jaden Geller > wrote:
 
 Jon,
 
 I think we might have miscommunicated. It is intended that outermost 
 module is implicit; no `module` declaration is required to wrap every 
 file. We tried to show this in the first code snippet.
 
 What do you mean “covering only part of a file”?
>>> 
>>> I am assuming that the ModuleName { … }  only affects things within the 
>>> brackets.  Thus it is possible for only part of a file to be within a 
>>> module.  What are the benefits of allowing this, and are they worth the 
>>> added complexity?
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 Cheers,
 Jaden Geller
 
> On Feb 20, 2017, at 6:36 PM, Jonathan Hull via swift-evolution 
> > wrote:
> 
> What is the rational for having modules covering only part of a file?  
> Wouldn’t it be less clutter to have an annotation which worked for the 
> whole file.  At the very least it would be nice to have an option to 
> spell it in a way that applies to the whole file.  Otherwise, everything 
> will be indented another level.
> 
> I would honestly love to see something which just maps modules to 
> folders/groups for simplicity sake.
> 
> I haven’t thought about it too much yet, so I could easily be missing 
> something obvious...
> 
> Thanks,
> Jon
>>> 
>> 
> 

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

[swift-evolution] [Draft] Fix Private Access Levels

[David Hart via swift-evolution]

Hello list,

Matthew Johnson and I have been putting our proposals together towards a joint 
“let’s fix private access levels” proposal. As the community seems quite 
divided on the issue, we offer two solutions in our proposal to let the 
community debate and to let the core team make the final decision.

I’d like to concentrate this round of feedback on the quality of the proposal, 
and not on the merits of Solution 1 or 2. thoughts?

https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/-fix-private-access-levels.md

David.

Fix Private Access Levels

Proposal: SE- 

Authors: David Hart , Matthew Johnson 

Review Manager: TBD
Status: TBD
 
Introduction

This proposal presents the problems the came with the the access level 
modifications in SE-0025 

 and presents two community driven solutions to fix them. As a consensus will 
not easily emerge, this proposal will allow a last round of voting and let the 
core team decide. Once that is done, this proposal will be ammended to describe 
the chosen solution.

 
Motivation

Since the release of Swift 3, the access level change of SE-0025 was met with 
dissatisfaction by a substantial proportion of the general Swift community. 
Before offering solutions, lets discuss how and why it can be viewed as actiely 
harmful, the new requirement for syntax/API changes.

 
Criticisms
 of SE-0025

There are two primary criticism that have been offered.

The first is that private is a "soft default" access modifier for restricting 
access within a file. Scoped access is not a good behavior for a "soft default" 
because it is extremely common to use several extensions within a file. A "soft 
default" (and therefore private) should work well with this idiom. It is fair 
to say that changing the behavior of private such that it does not work well 
with extensions meets the criteria of actively harmful in the sense that it 
subtly encourages overuse of scoped access control and discourages the more 
reasonable default by giving it the awkward name fileprivate.

The second is that Swift's system of access control is too complex. Many people 
feel like restricting access control to scopes less than a file is of dubious 
value and therefore wish to simplify Swift's access control story by removing 
scoped access. However, there are many others who like the ability to have the 
compiler verify tighter access levels and believe it helps make it easier to 
reason about code which is protecting invariants.

 
Detailed
 design

Both authors agree that the private keyword should be reverted back to its 
Swift 2 file-based meaning, resolving the first criticism. But the authors 
disagree on what should be done about the scoped access level and the following 
solutions represent the two main opinions in the community:

 
Solution
 1: Remove the scoped access level

Compared to a file-based access level, the scoped-based access level adds 
meaningful information by hiding implementation details which do not concern 
other types or extensions in the same file. But is that distinction between 
private and fileprivate actively used by the larger community of Swift 
developers? And if it were used pervasively, would it be worth the cognitive 
load and complexity of keeping two very similar access levels in the language? 
This solution argues that answer to both questions is no and that the scoped 
access level should be removed to resolve the complexity criticism.

This solution has the added advantage of leaving the most design breathing-room 
for future discussions about access levels in regards to submodules.

 
Solution
 2: Rename the scoped access level to scoped

It is difficult to make the case that a feature which a nontrivial number of 
Swift users find valuable and which is easy for teams to avoid is actively 
harmful. It seems like something that falls more into the category of a debate 
over style (which could be addressed by a linter). Should we remove a feature 
whose utility is a question of style, but is not actively harmful in the sense 
of causing programmer error? The second solution argues against it and 

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Dimitri Racordon via swift-evolution]

This was my first thought as well: imho it doesn't make sense to discard a good 
idea because of a vague hope that there might be something better (in, I'd 
expect, two or three years from now…).

I feel the same way.

Currently, Swift’s variadic parameters are just a way to call a function 
without brackets around its arguments. It is not useful and frankly a bit 
deceptive compared to what other languages proposes. Keeping them as-is until 
something that won’t happen before swift 5 at best is a pity.

I mostly design embedded domain specific languages, and this proposal enables 
very interesting perspective in that regard.

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

This was syntax I initially considered, but Jaden swayed me with the idea that 
we already have an `extension` keyword so we may as well use it to match the 
rest of the language.  Repeating the `module` declaration also lends itself 
more to C++-style namespaces, which these are not.  I’m not saying it’s out of 
the question, far from it. It is an alternative we will keep in mind.

~Robert Widmann

> On Feb 21, 2017, at 1:53 AM, Psycho Hedgehog via swift-evolution 
>  wrote:
> 
> The one thing i don't understand is the point of using extensions to extend 
> modules across multiple files, why not just allow declaring the submodule in 
> multiple files?
> 
>> Le 20 févr. 2017 à 22:48, Jaden Geller via swift-evolution 
>> > a écrit :
>> 
>> Oh, I see. You’re questioning the motivation of having scope-granularity 
>> submodules at all! My misunderstanding.
>> 
>> I actually hadn’t considered this as added complexity. In my mind, a scoped 
>> module declaration seems more Swifty than a file module declaration. It 
>> builds on the existing syntax in Swift for defining other sorts of scopes, 
>> e.g. types.
>> 
>> Cheers,
>> Jaden Geller
>> 
>>> On Feb 20, 2017, at 10:41 PM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> 
>>> I think my question is: Why do we want to allow submodules that are smaller 
>>> than a file?  What does that give us to offset the added complexity?
>>> 
>>> Thanks,
>>> Jon
>>> 
 On Feb 20, 2017, at 6:44 PM, Robert Widmann > wrote:
 
 
> On Feb 20, 2017, at 9:36 PM, Jonathan Hull  > wrote:
> 
> What is the rational for having modules covering only part of a file?  
> Wouldn’t it be less clutter to have an annotation which worked for the 
> whole file.  At the very least it would be nice to have an option to 
> spell it in a way that applies to the whole file.  Otherwise, everything 
> will be indented another level.
 
 That is a valid spelling (Rust, IIRC, allows that spelling), but one that 
 is easy to miss sitting in a file and makes it confusing to introduce 
 submodules.  If you include the annotation then define a submodule later 
 down in the file, suddenly you have to remember whether you annotated the 
 file or whether the submodule you’ve just written is going into the 
 top-level module.  See:
 
 // -module-name=Foo
 // module Foo {
 module Bar; // Shorthand for “This file defines Foo.Bar”
 
 /* Code */
 
 // This defines “Foo.Bar.Baz”, but would you know that if it appeared 
 below the fold?
 module Baz {}
 //}
 
 If anything, this can be added later if evolution converges on it.
 
> 
> I would honestly love to see something which just maps modules to 
> folders/groups for simplicity sake.
> 
 
 There is nothing about this scheme that prevents you from organizing your 
 code this way.  However, modulo that particular method of organization, 
 you don’t really gain much as a user of the language by imposing this 
 restriction.
 
> I haven’t thought about it too much yet, so I could easily be missing 
> something obvious...
> 
> Thanks,
> Jon
> 
> 
>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> Good Evening All,
>> 
>> Jaden Geller and I have been considering a (sub)module system for Swift 
>> that would complement the existing language but also provide sorely 
>> needed modularity.  A draft of the proposal is attached to this email, 
>> but it can also be read as a gist 
>>  if you 
>> desire.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> Modular Swift
>> 
>> Proposal: SE- 
>> Authors: Robert Widmann , Jaden Geller 
>> 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> Almost every major programming language supports some form of modular 
>> programming through constructs like (sub)modules, packages, or 
>> interfaces. Swift, though it provides top-level modules to organize code 
>> under, does not provide a complete implementation of any of these 
>> concepts, which has led instead to the proliferation of access control 
>> levels. This has not proven an effective way to decompose programs into 
>> manageable parts, and 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Psycho Hedgehog via swift-evolution]

The one thing i don't understand is the point of using extensions to extend 
modules across multiple files, why not just allow declaring the submodule in 
multiple files?

> Le 20 févr. 2017 à 22:48, Jaden Geller via swift-evolution 
>  a écrit :
> 
> Oh, I see. You’re questioning the motivation of having scope-granularity 
> submodules at all! My misunderstanding.
> 
> I actually hadn’t considered this as added complexity. In my mind, a scoped 
> module declaration seems more Swifty than a file module declaration. It 
> builds on the existing syntax in Swift for defining other sorts of scopes, 
> e.g. types.
> 
> Cheers,
> Jaden Geller
> 
>> On Feb 20, 2017, at 10:41 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> I think my question is: Why do we want to allow submodules that are smaller 
>> than a file?  What does that give us to offset the added complexity?
>> 
>> Thanks,
>> Jon
>> 
>>> On Feb 20, 2017, at 6:44 PM, Robert Widmann >> > wrote:
>>> 
>>> 
 On Feb 20, 2017, at 9:36 PM, Jonathan Hull > wrote:
 
 What is the rational for having modules covering only part of a file?  
 Wouldn’t it be less clutter to have an annotation which worked for the 
 whole file.  At the very least it would be nice to have an option to spell 
 it in a way that applies to the whole file.  Otherwise, everything will be 
 indented another level.
>>> 
>>> That is a valid spelling (Rust, IIRC, allows that spelling), but one that 
>>> is easy to miss sitting in a file and makes it confusing to introduce 
>>> submodules.  If you include the annotation then define a submodule later 
>>> down in the file, suddenly you have to remember whether you annotated the 
>>> file or whether the submodule you’ve just written is going into the 
>>> top-level module.  See:
>>> 
>>> // -module-name=Foo
>>> // module Foo {
>>> module Bar; // Shorthand for “This file defines Foo.Bar”
>>> 
>>> /* Code */
>>> 
>>> // This defines “Foo.Bar.Baz”, but would you know that if it appeared below 
>>> the fold?
>>> module Baz {}
>>> //}
>>> 
>>> If anything, this can be added later if evolution converges on it.
>>> 
 
 I would honestly love to see something which just maps modules to 
 folders/groups for simplicity sake.
 
>>> 
>>> There is nothing about this scheme that prevents you from organizing your 
>>> code this way.  However, modulo that particular method of organization, you 
>>> don’t really gain much as a user of the language by imposing this 
>>> restriction.
>>> 
 I haven’t thought about it too much yet, so I could easily be missing 
 something obvious...
 
 Thanks,
 Jon
 
 
> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
> Good Evening All,
> 
> Jaden Geller and I have been considering a (sub)module system for Swift 
> that would complement the existing language but also provide sorely 
> needed modularity.  A draft of the proposal is attached to this email, 
> but it can also be read as a gist 
>  if you 
> desire.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Modular Swift
> 
> Proposal: SE- 
> Authors: Robert Widmann , Jaden Geller 
> 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> Almost every major programming language supports some form of modular 
> programming through constructs like (sub)modules, packages, or 
> interfaces. Swift, though it provides top-level modules to organize code 
> under, does not provide a complete implementation of any of these 
> concepts, which has led instead to the proliferation of access control 
> levels. This has not proven an effective way to decompose programs into 
> manageable parts, and exposes the need for a real system of modules to 
> solve this modularity problem once and for all.
> 
> Separation of code into distinct islands of functionality should be a 
> first-class construct in the language, not dependent on external files 
> and tools or filesystems. To that end, we propose the introduction of a 
> lightweight module system for Swift.
> 
> Swift-evolution thread 
> 
>  
> Motivation
> 
> Swift has reached a point in its evolution where rich libraries and large 
> projects that take on many 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jonathan Hull via swift-evolution]

Part of it.  My concern is that the brackets will push everything in the file 
to the right.

My question is: What do we get in return for that? (as opposed to a system 
which acted on the whole file)

Thanks,
Jon


> On Feb 20, 2017, at 10:45 PM, Jaden Geller  wrote:
> 
> Oh, you’re referring to the fact that a submodule under this proposal must be 
> contained within braces? It would be purely additive to, in the future, 
> annotate that the outer scope of a file is part of some given submodule.
> 
> Consider the following the following straw-man syntax that might be 
> equivalent to `module Bar { func foo() { } }`:
> ```
> module Bar follows // <- at top of file, indicating rest of file is submodule
> 
> func foo() { }
> ```
> 
> Does this address your question?
> 
> Thanks,
> Jaden Geller
> 
>> On Feb 20, 2017, at 10:39 PM, Jonathan Hull > > wrote:
>> 
>> 
>>> On Feb 20, 2017, at 6:42 PM, Jaden Geller >> > wrote:
>>> 
>>> Jon,
>>> 
>>> I think we might have miscommunicated. It is intended that outermost module 
>>> is implicit; no `module` declaration is required to wrap every file. We 
>>> tried to show this in the first code snippet.
>>> 
>>> What do you mean “covering only part of a file”?
>> 
>> I am assuming that the ModuleName { … }  only affects things within the 
>> brackets.  Thus it is possible for only part of a file to be within a 
>> module.  What are the benefits of allowing this, and are they worth the 
>> added complexity?
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> Cheers,
>>> Jaden Geller
>>> 
 On Feb 20, 2017, at 6:36 PM, Jonathan Hull via swift-evolution 
 > wrote:
 
 What is the rational for having modules covering only part of a file?  
 Wouldn’t it be less clutter to have an annotation which worked for the 
 whole file.  At the very least it would be nice to have an option to spell 
 it in a way that applies to the whole file.  Otherwise, everything will be 
 indented another level.
 
 I would honestly love to see something which just maps modules to 
 folders/groups for simplicity sake.
 
 I haven’t thought about it too much yet, so I could easily be missing 
 something obvious...
 
 Thanks,
 Jon
>> 
> 

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 1:46 AM, Jonathan Hull  wrote:
> 
> 
>> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote:
>> 
>>> 
>>> 
>>> I would honestly love to see something which just maps modules to 
>>> folders/groups for simplicity sake.
>>> 
>> 
>> There is nothing about this scheme that prevents you from organizing your 
>> code this way.  However, modulo that particular method of organization, you 
>> don’t really gain much as a user of the language by imposing this 
>> restriction.
> 
> I think the big gain is that users of IDEs would just be able to graphically 
> organize modules in Xcode.  Non-IDE users could use the finder to organize 
> things into nested folders.  This maps pretty well with the way I organize my 
> code already (others may be different), so it doesn’t add much complexity.
> 

Xcode today is able to do this with nested classes and structures with the 
hierarchy navigator.  Non-IDE users can use grep or (hopefully) some 
syntax-aware plugin system to help them find these declarations.  Really, 
again, this is a design pattern and one that can be enforced by linters.  If we 
were to impose this restriction at the language level it ties this proposal 
down to file system structure and we are explicitly trying to avoid that.

> On a side note, I do think that people will quickly want a way to reference a 
> particular submodule boundary with access modifiers.  It may not be part of 
> this proposal, but it is somewhat inevitable.  We should consider that as we 
> consider this proposal…
> 

Modules are not types, access control makes no sense here.  APIs may be 
exported (or not) across module boundaries, but modules themselves are not 
arbitrary programming constructs nor do we consider them to carry semantic 
weight as in some other ML-likes.  A public module is no different from a 
private module if you can import it.  A private module is no different from a 
public one if you cannot.

> Thanks,
> Jon

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

Oh, I see. You’re questioning the motivation of having scope-granularity 
submodules at all! My misunderstanding.

I actually hadn’t considered this as added complexity. In my mind, a scoped 
module declaration seems more Swifty than a file module declaration. It builds 
on the existing syntax in Swift for defining other sorts of scopes, e.g. types.

Cheers,
Jaden Geller

> On Feb 20, 2017, at 10:41 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I think my question is: Why do we want to allow submodules that are smaller 
> than a file?  What does that give us to offset the added complexity?
> 
> Thanks,
> Jon
> 
>> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote:
>> 
>> 
>>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull >> > wrote:
>>> 
>>> What is the rational for having modules covering only part of a file?  
>>> Wouldn’t it be less clutter to have an annotation which worked for the 
>>> whole file.  At the very least it would be nice to have an option to spell 
>>> it in a way that applies to the whole file.  Otherwise, everything will be 
>>> indented another level.
>> 
>> That is a valid spelling (Rust, IIRC, allows that spelling), but one that is 
>> easy to miss sitting in a file and makes it confusing to introduce 
>> submodules.  If you include the annotation then define a submodule later 
>> down in the file, suddenly you have to remember whether you annotated the 
>> file or whether the submodule you’ve just written is going into the 
>> top-level module.  See:
>> 
>> // -module-name=Foo
>> // module Foo {
>> module Bar; // Shorthand for “This file defines Foo.Bar”
>> 
>> /* Code */
>> 
>> // This defines “Foo.Bar.Baz”, but would you know that if it appeared below 
>> the fold?
>> module Baz {}
>> //}
>> 
>> If anything, this can be added later if evolution converges on it.
>> 
>>> 
>>> I would honestly love to see something which just maps modules to 
>>> folders/groups for simplicity sake.
>>> 
>> 
>> There is nothing about this scheme that prevents you from organizing your 
>> code this way.  However, modulo that particular method of organization, you 
>> don’t really gain much as a user of the language by imposing this 
>> restriction.
>> 
>>> I haven’t thought about it too much yet, so I could easily be missing 
>>> something obvious...
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
 > wrote:
 
 Good Evening All,
 
 Jaden Geller and I have been considering a (sub)module system for Swift 
 that would complement the existing language but also provide sorely needed 
 modularity.  A draft of the proposal is attached to this email, but it can 
 also be read as a gist 
  if you 
 desire.
 
 Cheers,
 
 ~Robert Widmann
 
 Modular Swift
 
 Proposal: SE- 
 Authors: Robert Widmann , Jaden Geller 
 
 Review Manager: TBD
 Status: Awaiting review
  
 Introduction
 
 Almost every major programming language supports some form of modular 
 programming through constructs like (sub)modules, packages, or interfaces. 
 Swift, though it provides top-level modules to organize code under, does 
 not provide a complete implementation of any of these concepts, which has 
 led instead to the proliferation of access control levels. This has not 
 proven an effective way to decompose programs into manageable parts, and 
 exposes the need for a real system of modules to solve this modularity 
 problem once and for all.
 
 Separation of code into distinct islands of functionality should be a 
 first-class construct in the language, not dependent on external files and 
 tools or filesystems. To that end, we propose the introduction of a 
 lightweight module system for Swift.
 
 Swift-evolution thread 
 
  
 Motivation
 
 Swift has reached a point in its evolution where rich libraries and large 
 projects that take on many dependencies have matured significantly. To 
 accomodate the information-hiding and semantics-signalling needs of these 
 users at the time, Swift began its access control story with just three 
 access modifiers: public, private, and internal then grew fileprivate and 
 open as the need to express locality of implementation and 
 "subclassability" arose respectively. In doing so, Swift's access control 
 scheme has 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jonathan Hull via swift-evolution]

> On Feb 20, 2017, at 6:44 PM, Robert Widmann  wrote:
> 
>> 
>> 
>> I would honestly love to see something which just maps modules to 
>> folders/groups for simplicity sake.
>> 
> 
> There is nothing about this scheme that prevents you from organizing your 
> code this way.  However, modulo that particular method of organization, you 
> don’t really gain much as a user of the language by imposing this restriction.

I think the big gain is that users of IDEs would just be able to graphically 
organize modules in Xcode.  Non-IDE users could use the finder to organize 
things into nested folders.  This maps pretty well with the way I organize my 
code already (others may be different), so it doesn’t add much complexity.

On a side note, I do think that people will quickly want a way to reference a 
particular submodule boundary with access modifiers.  It may not be part of 
this proposal, but it is somewhat inevitable.  We should consider that as we 
consider this proposal…

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 20, 2017, at 11:39 PM, Matthew Johnson  wrote:
> 
> Thanks for bringing up submodules Robert.  I agree it's a good time to 
> discuss them.  
> 
> There seem to be two broad approaches to submodules.  One is more of a 
> physical / encapsulation based view and the other is more of a logical / 
> namespace based view.  This proposal falls into the latter group (Brent's 
> pitch falls into the former).
> 
> Before I offer feedback on this proposal I'm wondering if you can provide 
> some solid examples of what benefits you see in the ability of a single file 
> to participate in more than one submodule.  

A single file defining more than one submodule is like a single file defining 
more than one data structure/extension.  If you decide that particular 
functionality deserves to reside in separate areas of concern, but don’t wish 
to break it out into separate files for whatever reason, just don’t.  Can you 
be more specific about the kind of thing you’re looking for?

> And also, what problems do you foresee if a file were restricted to being in 
> a single submodule (or at the top level of the module)?

The top level case is called out in the proposal.  We felt that requiring a 
top-level module declaration in every file to opt-in would be a needless 
complication to the semantics and would introduce an identifier-addressing 
problem.  Specifically, because modules aren’t namespaces we don’t have a way 
to refer to the “anonymous/global" top-level namespace as in C++ with a bare 
::, so this would become ambiguous without additional syntax

// Explicit declaration of top-level module Foo
module Foo {
  // Decls...
}

// Where does this constant live?  How can I address it from within Foo?
// Why isn’t it just a part of Foo?
let string = “Hello World!”

For one-file-per-module, that kind of restriction represents a particular way 
of organizing code and is a design pattern that is supported under this 
proposal.  We just happen to not enforce that particular pattern, and feel that 
it is the job of a linter to do so.  Really, this kind of restriction is to 
ease the mental burden on compiler writers who use it to build compilation unit 
dependency graphs.  Swift already considers all files when building its modules 
because you can extend any type (and now, any module) from any one of them so 
it doesn’t buy us anything other than an arbitrary restriction.

More generally, we need to move access control away as far away from 
filesystems as possible.  One day, the compiler is going to get ported over to 
a platform with some bonkers rules that are going to turn around and bite us.

~ Robert Widmann

> 
> Sent from my iPad
> 
> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
>> Good Evening All,
>> 
>> Jaden Geller and I have been considering a (sub)module system for Swift that 
>> would complement the existing language but also provide sorely needed 
>> modularity.  A draft of the proposal is attached to this email, but it can 
>> also be read as a gist 
>>  if you 
>> desire.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> Modular Swift
>> 
>> Proposal: SE- 
>> Authors: Robert Widmann , Jaden Geller 
>> 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> Almost every major programming language supports some form of modular 
>> programming through constructs like (sub)modules, packages, or interfaces. 
>> Swift, though it provides top-level modules to organize code under, does not 
>> provide a complete implementation of any of these concepts, which has led 
>> instead to the proliferation of access control levels. This has not proven 
>> an effective way to decompose programs into manageable parts, and exposes 
>> the need for a real system of modules to solve this modularity problem once 
>> and for all.
>> 
>> Separation of code into distinct islands of functionality should be a 
>> first-class construct in the language, not dependent on external files and 
>> tools or filesystems. To that end, we propose the introduction of a 
>> lightweight module system for Swift.
>> 
>> Swift-evolution thread 
>>  
>> Motivation
>> 
>> Swift has reached a point in its evolution where rich libraries and large 
>> projects that take on many dependencies have matured significantly. To 
>> accomodate the information-hiding and semantics-signalling needs of these 
>> users at the time, Swift began its access control story with just three 
>> access modifiers: public, private, and internal then grew fileprivate and 
>> open as the need to express 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

Oh, you’re referring to the fact that a submodule under this proposal must be 
contained within braces? It would be purely additive to, in the future, 
annotate that the outer scope of a file is part of some given submodule.

Consider the following the following straw-man syntax that might be equivalent 
to `module Bar { func foo() { } }`:
```
module Bar follows // <- at top of file, indicating rest of file is submodule

func foo() { }
```

Does this address your question?

Thanks,
Jaden Geller

> On Feb 20, 2017, at 10:39 PM, Jonathan Hull  wrote:
> 
> 
>> On Feb 20, 2017, at 6:42 PM, Jaden Geller > > wrote:
>> 
>> Jon,
>> 
>> I think we might have miscommunicated. It is intended that outermost module 
>> is implicit; no `module` declaration is required to wrap every file. We 
>> tried to show this in the first code snippet.
>> 
>> What do you mean “covering only part of a file”?
> 
> I am assuming that the ModuleName { … }  only affects things within the 
> brackets.  Thus it is possible for only part of a file to be within a module. 
>  What are the benefits of allowing this, and are they worth the added 
> complexity?
> 
> Thanks,
> Jon
> 
> 
>> Cheers,
>> Jaden Geller
>> 
>>> On Feb 20, 2017, at 6:36 PM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> 
>>> What is the rational for having modules covering only part of a file?  
>>> Wouldn’t it be less clutter to have an annotation which worked for the 
>>> whole file.  At the very least it would be nice to have an option to spell 
>>> it in a way that applies to the whole file.  Otherwise, everything will be 
>>> indented another level.
>>> 
>>> I would honestly love to see something which just maps modules to 
>>> folders/groups for simplicity sake.
>>> 
>>> I haven’t thought about it too much yet, so I could easily be missing 
>>> something obvious...
>>> 
>>> Thanks,
>>> Jon
> 

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

The same benefits afforded by multiple extensions contained in the same file: 
sometimes you wish for your concerns not to overlap with one another, but feel 
that they do not necessarily warrant being split into separate files.  There 
really isn’t a reason we should enforce separation of submodules in the 
language if we can help it, it’s more the job of a linter.

~Robert Widmann

> On Feb 21, 2017, at 1:41 AM, Jonathan Hull  wrote:
> 
> I think my question is: Why do we want to allow submodules that are smaller 
> than a file?  What does that give us to offset the added complexity?
> 
> Thanks,
> Jon
> 
>> On Feb 20, 2017, at 6:44 PM, Robert Widmann > > wrote:
>> 
>> 
>>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull >> > wrote:
>>> 
>>> What is the rational for having modules covering only part of a file?  
>>> Wouldn’t it be less clutter to have an annotation which worked for the 
>>> whole file.  At the very least it would be nice to have an option to spell 
>>> it in a way that applies to the whole file.  Otherwise, everything will be 
>>> indented another level.
>> 
>> That is a valid spelling (Rust, IIRC, allows that spelling), but one that is 
>> easy to miss sitting in a file and makes it confusing to introduce 
>> submodules.  If you include the annotation then define a submodule later 
>> down in the file, suddenly you have to remember whether you annotated the 
>> file or whether the submodule you’ve just written is going into the 
>> top-level module.  See:
>> 
>> // -module-name=Foo
>> // module Foo {
>> module Bar; // Shorthand for “This file defines Foo.Bar”
>> 
>> /* Code */
>> 
>> // This defines “Foo.Bar.Baz”, but would you know that if it appeared below 
>> the fold?
>> module Baz {}
>> //}
>> 
>> If anything, this can be added later if evolution converges on it.
>> 
>>> 
>>> I would honestly love to see something which just maps modules to 
>>> folders/groups for simplicity sake.
>>> 
>> 
>> There is nothing about this scheme that prevents you from organizing your 
>> code this way.  However, modulo that particular method of organization, you 
>> don’t really gain much as a user of the language by imposing this 
>> restriction.
>> 
>>> I haven’t thought about it too much yet, so I could easily be missing 
>>> something obvious...
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
 > wrote:
 
 Good Evening All,
 
 Jaden Geller and I have been considering a (sub)module system for Swift 
 that would complement the existing language but also provide sorely needed 
 modularity.  A draft of the proposal is attached to this email, but it can 
 also be read as a gist 
  if you 
 desire.
 
 Cheers,
 
 ~Robert Widmann
 
 Modular Swift
 
 Proposal: SE- 
 Authors: Robert Widmann , Jaden Geller 
 
 Review Manager: TBD
 Status: Awaiting review
  
 Introduction
 
 Almost every major programming language supports some form of modular 
 programming through constructs like (sub)modules, packages, or interfaces. 
 Swift, though it provides top-level modules to organize code under, does 
 not provide a complete implementation of any of these concepts, which has 
 led instead to the proliferation of access control levels. This has not 
 proven an effective way to decompose programs into manageable parts, and 
 exposes the need for a real system of modules to solve this modularity 
 problem once and for all.
 
 Separation of code into distinct islands of functionality should be a 
 first-class construct in the language, not dependent on external files and 
 tools or filesystems. To that end, we propose the introduction of a 
 lightweight module system for Swift.
 
 Swift-evolution thread 
 
  
 Motivation
 
 Swift has reached a point in its evolution where rich libraries and large 
 projects that take on many dependencies have matured significantly. To 
 accomodate the information-hiding and semantics-signalling needs of these 
 users at the time, Swift began its access control story with just three 
 access modifiers: public, private, and internal then grew fileprivate and 
 open as the need to express locality of implementation and 
 "subclassability" arose respectively. In doing so, Swift's access control 
 scheme has become anti-modular.
 

[swift-evolution] [Proposal Draft] Remove open Access Modifier

[Dimitri Racordon via swift-evolution]

Hi all,

Here’s a draft proposal following 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html.
 The idea is simplify Swift’s syntax by getting rid of the `open` access 
modifier.

A rendered version of the proposal is available here: 
https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/-remove-open-access-modifier.md
The raw version follows:


# Remove open Access Modifier

* Proposal: [SE-](-remove-open-access-modifier.md)
* Author: [Dimitri Racordon](https://github.com/kyouko-taiga), Joanna Carter
* Status: **Awaiting review**
* Review manager: TBD

## Introduction

Swift allows classes, methods, properties and subscripts to be marked as 
`final`, hence disallowing their subclassing/overriding inside **and** outside 
of their defining module.

It also features two access levels `open`, which allows an entity to be 
accessed outside its defining module, and `public`, which gives the same access 
level the former **and** allows the entity to be subclassed/overridden.

There's a clear overlap between `open` and `public`, as they essentially 
represent the same access control within the boundaries of a module, and do not 
add any benefit from outside them, as `final` is sufficient to prohibit 
subclassing/overriding.

Swift-evolution thread: ['Public' class visibility 
specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html)


## Motivation

Swift has currently 5 access levels, in the form of:

* `private`, restricting the use of an entity to its enclosing declaration;
* `fileprivate`, restricting the use of an entity to its defining source file:
* `internal`, restricting the use of an entity to its defining module;
* `public`, allowing the entity to be accessed anywhere;
* `open`, allowing the entity to be accessed anywhere **and** allowing the 
entity to be subclassed/overridden outside of their defining module.

From inside a module, `open` and `public` represent exactly the same access 
level (everything is visible **and** can be subclassed/overridden).
From outside a module, `public` is actually akin to `final`.

```swift
// Module 1
// 

open class OpenClass {}
public class PublicClass {}

public final class PublicFinalClass {}

// The first two classes above have the same access level.
class derivedFromOpen: OpenClass {}
class derivedFromPublic: PublicClass {}

// Module 2
// 

class derivedFromOpenOutside: OpenClass {}

class derivedFromPublicOutside: PublicClass {}
// Error: Cannot inherit from non-open class ...

class derivedFromPublicFinalOutside: PublicFinalClass {}
// Error: Inheritance from a final class ...
```

Hence, the sole use-case of using both `public` and `final` is for an entity 
that *inside* its defining module should not be subclassed/overridden.

```swift
// Module 1
// 

class derivedFromPublicFinal : PublicFinalClass {}
// Error: Inheritance from a final class ...
```

We believe this use case is rare and not worth the additional complexity of 
having an `open` access level in the language.
Besides, `open` is only applicable on classes and class members while the 
others can be used on other entities (protocols, structures, ...).
This asymmetry adds to the complexity of an `open` access level.

In order to simplify the syntax of Swift, we propose to **remove the `open` 
access modifier**.

## Proposal

Remove the `open` access modifier from Swift.

## Source compatibility

This is a breaking change, as the `open` keyword would disappear from the 
language.
However, a fixit would be quite easy to put in place, simply replacing `open` 
with `public`.

## Alternative considered

Not removing the `open` access modifier from the language and keep the status 
quo.

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jonathan Hull via swift-evolution]

I think my question is: Why do we want to allow submodules that are smaller 
than a file?  What does that give us to offset the added complexity?

Thanks,
Jon

> On Feb 20, 2017, at 6:44 PM, Robert Widmann  wrote:
> 
> 
>> On Feb 20, 2017, at 9:36 PM, Jonathan Hull > > wrote:
>> 
>> What is the rational for having modules covering only part of a file?  
>> Wouldn’t it be less clutter to have an annotation which worked for the whole 
>> file.  At the very least it would be nice to have an option to spell it in a 
>> way that applies to the whole file.  Otherwise, everything will be indented 
>> another level.
> 
> That is a valid spelling (Rust, IIRC, allows that spelling), but one that is 
> easy to miss sitting in a file and makes it confusing to introduce 
> submodules.  If you include the annotation then define a submodule later down 
> in the file, suddenly you have to remember whether you annotated the file or 
> whether the submodule you’ve just written is going into the top-level module. 
>  See:
> 
> // -module-name=Foo
> // module Foo {
> module Bar; // Shorthand for “This file defines Foo.Bar”
> 
> /* Code */
> 
> // This defines “Foo.Bar.Baz”, but would you know that if it appeared below 
> the fold?
> module Baz {}
> //}
> 
> If anything, this can be added later if evolution converges on it.
> 
>> 
>> I would honestly love to see something which just maps modules to 
>> folders/groups for simplicity sake.
>> 
> 
> There is nothing about this scheme that prevents you from organizing your 
> code this way.  However, modulo that particular method of organization, you 
> don’t really gain much as a user of the language by imposing this restriction.
> 
>> I haven’t thought about it too much yet, so I could easily be missing 
>> something obvious...
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> Good Evening All,
>>> 
>>> Jaden Geller and I have been considering a (sub)module system for Swift 
>>> that would complement the existing language but also provide sorely needed 
>>> modularity.  A draft of the proposal is attached to this email, but it can 
>>> also be read as a gist 
>>>  if you 
>>> desire.
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> Modular Swift
>>> 
>>> Proposal: SE- 
>>> Authors: Robert Widmann , Jaden Geller 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting review
>>>  
>>> Introduction
>>> 
>>> Almost every major programming language supports some form of modular 
>>> programming through constructs like (sub)modules, packages, or interfaces. 
>>> Swift, though it provides top-level modules to organize code under, does 
>>> not provide a complete implementation of any of these concepts, which has 
>>> led instead to the proliferation of access control levels. This has not 
>>> proven an effective way to decompose programs into manageable parts, and 
>>> exposes the need for a real system of modules to solve this modularity 
>>> problem once and for all.
>>> 
>>> Separation of code into distinct islands of functionality should be a 
>>> first-class construct in the language, not dependent on external files and 
>>> tools or filesystems. To that end, we propose the introduction of a 
>>> lightweight module system for Swift.
>>> 
>>> Swift-evolution thread 
>>>  
>>> Motivation
>>> 
>>> Swift has reached a point in its evolution where rich libraries and large 
>>> projects that take on many dependencies have matured significantly. To 
>>> accomodate the information-hiding and semantics-signalling needs of these 
>>> users at the time, Swift began its access control story with just three 
>>> access modifiers: public, private, and internal then grew fileprivate and 
>>> open as the need to express locality of implementation and 
>>> "subclassability" arose respectively. In doing so, Swift's access control 
>>> scheme has become anti-modular.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> We propose the introduction of a lightweight module system for Swift. More 
>>> than simply namspaces, a module declaration interacts with Swift's access 
>>> control to provide an API boundary that allows better control over an 
>>> interface's design.
>>> 
>>>  
>>> Detailed
>>>  design
>>> 
>>>  
>>> Syntax
>>> 
>>> A module is a named 

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

[Tino Heth via swift-evolution]

Damn, there seems to be no better way to create reactions than saying something 
stupid ;-) - to bad the reactions tend to focus on the stupidity in this case...
It should have been "union" instead of "sum", so basically having Optional 
modeled as (T | Void)

> Enums in Swift *are* sum types. There are various ergonomic issues with their 
> usability, perhaps, but any implementation of sum types would be different 
> sugar over the same underlying semantic model.

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

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

[John McCall via swift-evolution]

> On Feb 20, 2017, at 4:15 PM, Joe Groff  wrote:
>> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution 
>> > wrote:
>>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> It’s expected that if you need resilience, then you will throw an “open” 
>>> enum. Essentially, we pass resilience of typed throws on to those who will 
>>> hopefully establish resilience of enums.
>>> 
>>> If you prefer separate error types, then declare a base protocol for all 
>>> your error types and throw a protocol existential. You won’t even need 
>>> default case in switches, if closed protocols make it into the language.
>>> 
>>> I don’t like any solution that is based on comments. I think that compiler 
>>> should always ignore comments.
>>> 
>> I agree.  And in general, this sort of thing is exactly my core concern 
>> about adding typed throws to the language: I am completely certain that many 
>> programmers will add typed throws annotations because they're programmers 
>> and thus, well, probably a little obsessive/compulsive, and they're trying 
>> to precisely document the behavior of their function without necessarily 
>> thinking about the usefulness of that information for their clients and (if 
>> they're writing a library; and really you should almost always be writing 
>> code as if you're writing a library) whether they're actually willing to 
>> commit to that behavior in their interface.  For those programmers, typed 
>> throws is just going to box them in and force them into anti-patterns in the 
>> long run.
>> 
>> In the vast majority of use-cases, clients are not going to exhaustively 
>> handle all errors — they will always have some generic fall-back.  That is 
>> not pessimism, it's actually the natural result of the complicated world we 
>> live in, where code can fail for a huge host of reasons and most callers 
>> won't have meaningful special-case behavior for all of them.  (On most 
>> operating systems, opening a file or a network connection can fail because 
>> you ran out of file descriptors.  You're seriously telling me that you're 
>> going to add a special case to your error logic for that?)  Go look at the 
>> actual error types that people use in most typed-throws situations and try 
>> to tell me I'm wrong — they probably have like twenty alternatives, and 
>> solidly a quarter or more of them will just be embedding some other 
>> arbitrarily-complex or stringly-typed error value.
> 
> I agree that overly specific API specs are a concern. There's still some 
> documentational benefit to a typed error enum, even if it ultimately ends up 
> containing a catch-all case, since it gives you the ability to also enumerate 
> some number of discrete, realistically handleable cases. Sure, your network 
> request running in an XPC service has infinitely many failure cases due to 
> resource constraints or IPC failure or network chaos, but there's usually 
> some number of domain-specific error cases  too.

I definitely agree with the documentational benefits of declaring interesting 
error cases, and I agree that most libraries will add new domain-specific 
errors, too.  I just don't see the actual benefit to either API authors or 
clients of saying "I will only throw errors that look like *this*" and then 
*this* turns out to be an enum with ten interesting cases, most of which don't 
apply to the specific operation, and a bunch of generic wrapping cases that 
communicate very little; especially not compared to saying "in this interesting 
case I'll throw a FooError.bar" in the documentation.  Especially since it's 
not obvious that *cases* are the right granularity for describing a specific 
kind of domain error, since a case can't be retroactively split into more- and 
less-informative sub-cases without adding language features that only I seem to 
be interested in. :)

> And if we compare the proposed "you get to specify one error enum type" model 
> to, say, Java or C++98's "you get to specify any number of error classes" 
> model, I think that helps steer people away from the most grievous API 
> mistakes in Java land, since instead of listing a closed set of concrete 
> error classes directly in your API signature, you'll list those error cases 
> in your enum definition, and in a resilient world, the enum will be "open" by 
> default to external users, preventing it from being a permanent liability 
> unless the user explicitly opted into closedness.

To be exact, resilience prevents it from being a permanent liability as long as 
you've thought ahead enough to use your own error type.

> In the discussions around Rust's error handling conventions, they recognized 
> this pattern of APIs either raising some number of layer-appropriate errors 
> or carrying forward the failure modes of the layers below them, and they 

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Russ Bishop via swift-evolution]

> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised 
> proposal in draft form.
> 
> It proposes a source-breaking change for rationalizing which characters are 
> permitted in identifiers and which in operators. It's justified for this 
> phase of Swift 4 because:
> 
> - Existing grammar, in permitting invisible characters without 
> security-minded restrictions, can be actively harmful.
> - A rationalized approach is superior to the current approach: by referencing 
> Unicode standards, Swift should be able to evolve in a backwards-compatible 
> way alongside Unicode, and will benefit from the significant expertise of 
> others outside the Swift community with respect to Unicode best practices.
> - The vast majority of existing code (including all of the standard library) 
> should require no migration work at all
> 
> What's changed since the last time:
> 
> - In an earlier draft, we proposed some radical changes to align with 
> available Unicode standards; in particular, since emoji represent a difficult 
> issue, and no recommendations about "operator identifiers" have surfaced from 
> Unicode, we proposed temporarily stripping them out. This was very poorly 
> received. This revision uses Unicode categories to identify nearly all emoji 
> and classify them as identifier characters (while excluding those that depict 
> operators such as !), and it uses Unicode categories to identify over 900 
> operators that nearly all pass the subjective test of "operator-likeness."
> 
> 

I was one of the people leading the charge for preserving Emoji support and I 
really like where this proposal landed. Thank you to all the authors for the 
hard work!


+1


Russ

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

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Matthew Johnson via swift-evolution]

Thanks for bringing up submodules Robert.  I agree it's a good time to discuss 
them.  

There seem to be two broad approaches to submodules.  One is more of a physical 
/ encapsulation based view and the other is more of a logical / namespace based 
view.  This proposal falls into the latter group (Brent's pitch falls into the 
former).

Before I offer feedback on this proposal I'm wondering if you can provide some 
solid examples of what benefits you see in the ability of a single file to 
participate in more than one submodule.  And also, what problems do you foresee 
if a file were restricted to being in a single submodule (or at the top level 
of the module)?

Sent from my iPad

> On Feb 20, 2017, at 7:56 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Good Evening All,
> 
> Jaden Geller and I have been considering a (sub)module system for Swift that 
> would complement the existing language but also provide sorely needed 
> modularity.  A draft of the proposal is attached to this email, but it can 
> also be read as a gist if you desire.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Modular Swift
> Proposal: SE-
> Authors: Robert Widmann, Jaden Geller
> Review Manager: TBD
> Status: Awaiting review
> Introduction
> 
> Almost every major programming language supports some form of modular 
> programming through constructs like (sub)modules, packages, or interfaces. 
> Swift, though it provides top-level modules to organize code under, does not 
> provide a complete implementation of any of these concepts, which has led 
> instead to the proliferation of access control levels. This has not proven an 
> effective way to decompose programs into manageable parts, and exposes the 
> need for a real system of modules to solve this modularity problem once and 
> for all.
> 
> Separation of code into distinct islands of functionality should be a 
> first-class construct in the language, not dependent on external files and 
> tools or filesystems. To that end, we propose the introduction of a 
> lightweight module system for Swift.
> 
> Swift-evolution thread
> 
> Motivation
> 
> Swift has reached a point in its evolution where rich libraries and large 
> projects that take on many dependencies have matured significantly. To 
> accomodate the information-hiding and semantics-signalling needs of these 
> users at the time, Swift began its access control story with just three 
> access modifiers: public, private, and internal then grew fileprivate and 
> open as the need to express locality of implementation and "subclassability" 
> arose respectively. In doing so, Swift's access control scheme has become 
> anti-modular.
> 
> Proposed solution
> 
> We propose the introduction of a lightweight module system for Swift. More 
> than simply namspaces, a module declaration interacts with Swift's access 
> control to provide an API boundary that allows better control over an 
> interface's design.
> 
> Detailed design
> 
> Syntax
> 
> A module is a named region that introduces a lexical scope into which 
> declarations may be nested. The name of the module can be used to access 
> these member declarations. A module, like other aggregate structures in 
> Swift, may be extended with new declarations over one or more translation 
> units (files).
> 
> We propose a new declaration kind, module-decl be added to the language. A 
> proposed grammar using the new modulekeyword is given below:
> 
> GRAMMAR OF A MODULE DECLARATION
> 
> module-declaration -> `module` module-identifier module-body
> module-name -> identifier
> module-body -> { module-members(opt) }
> module-members -> module-member module-members(opt)
> module-member -> declaration | compiler-control-statement
> GRAMMAR OF A DECLARATION
> 
> + declaration -> module-declaration
> General Semantics
> 
> Syntax and semantics for imports, as it already supports referencing 
> submodules imported from C and Objective-C modules, remains unchanged:
> 
> // The outermost module is given explicitly 
> // by passing `-module-name=Foo` or exists implicitly, as today.
> // module Foo {
> public class A {}
> 
> module Bar {
>   module Baz {
> public class C {}
>   }
> 
>   public class B {}
> }
> 
> let message = "Hello, Wisconsin!"
> // } // End declarations added to module Foo.
> To consume this interface:
> 
> // imports all of Foo, Foo.Bar, and Foo.Bar.Baz
> import Foo.Bar.Baz
> 
> // imports Foo.A as A
> import class Foo.A
> // imports Foo.Bar.B as B
> import class Foo.Bar.B
> // imports Foo.Bar.Baz.C as C
> import class Foo.Bar.Baz.C
> A module declaration may only appear as a top-level entity or as a member of 
> another module declaration. The following code is therefore invalid:
> 
> module Foo {
>   class Bar {
> module Baz {} // error: module declaration cannot be nested inside type 
> 'Bar'
>   }
> }
> To extend an existing module declaration, simply reference its module name in 
> an extension declaration. 
> 
> // In 

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

[David Waite via swift-evolution]

> On Feb 20, 2017, at 10:04 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
> Otherwise known in my language as :
> 
> public - anywhere
> internal - anywhere inside the module
> private - only inside current type
> extensible - in current file and in subtypes/extensions in other files
> 
> The only other option that might be useful is something like 'internal 
> extensible' to limit visibility for extensible members to the current module.
If a type is extensible by other modules at all, I prefer that to be spelled 
“public”.

> Sorry, I would still like to see a waterproof argument for what is presently 
> called fileprivate ; with the above scopes, I simply can't see the need. 
> Unless you can convince me, that is ;-)

 In C++ terms, it would be when I want some other class to have friend access 
to a function/data, but for it not to be arbitrarily accessible by subtypes

I believe the critical piece of designing access levels is for the levels to 
document the intent of the developer specifying the access level. Does 
“extensible” indicate that the designer of the library wanted a certain kind of 
access - or that the compiler maybe gave an error at some point when it was 
“private”?

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

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 20, 2017, at 7:36 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Okay, lots of people want to have some kind of submodule feature, so I'd like 
> to sketch one out so we can hopefully agree on what submodules might look 
> like.
> 
> ***
> 
> Any group of Swift files can be grouped together to form a submodule.

It isn't clear to me how you express that a particular group of files forms a 
submodule.  Can you elaborate?

> Submodules belong within a particular module, and have a dotted name: If 
> `ModKit` is a module, it might have a submodule called `ModKit.Foo`. 
> Submodules can be nested within one another: `ModKit.Foo.Bar` is a submodule 
> of `ModKit.Foo`, which is a submodule of `ModKit`.
> 
> No new access levels are necessary. `internal` APIs are only visible within 
> the submodule they're declared in; a module cannot see its submodules' 
> `internal` APIs, and a submodule cannot see its parent module's `internal` 
> APIs. If a submodule wants to expose some of its APIs to its parent or 
> sibling modules, it must mark them as `public` or `open`. Then they can 
> import the submodule to see its APIs:
> 
>import ModKit.Foo
> 
> By default, outside modules cannot import a submodule. But an import in the 
> parent module can be decorated by an access control keyword to allow that:
> 
>/// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs.
>open import ModKit.Foo
> 
>/// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs, 
>/// except `open` APIs are treated as `public`.
>public import ModKit.Foo
> 
> Imports may also be decorated by the `@exported` attribute, which exposes the 
> submodule's APIs as though they were parent module APIs:
> 
>@exported open import ModKit.Foo
> 
>@exported public import ModKit.Foo
> 
> (This is sort of half-implemented already in a buggy `@_exported` attribute.)
> 
> Finally, the standard syntax for importing individual symbols can be used to 
> cherry-pick types to treat differently:
> 
>// Most ModKit.Foo APIs are not importable...
>import ModKit.Foo
> 
>// ...but SomeEnum can be imported as public...
>public import enum ModKit.Foo.SomeEnum
> 
>// ...SomeClass can be imported as open...
>open import class ModKit.Foo.SomeClass
> 
>// And ImportantStruct will import whenever you import ModKit.
>@exported public import struct ModKit.Foo.ImportantStruct
> 
> (This syntax should be enhanced to allow cherry-picked importing of global 
> functions, constants, and variables.)
> 
> If there are several different `import`s covering the same submodule or 
> submodule symbol, the most permissive one wins.
> 
> (In large projects, `public`, `open`, and `@exported` imports will most 
> likely all be put in a single Policy.swift file or something, but this is not 
> enforced by the language.)
> 
> A submodule may not import any direct parent module (parent, grandparent, 
> etc.), but may import any other submodule in the same module. This list shows 
> permitted imports for a project with four modules/submodules:
> 
>ModKit
>- ModKit.Foo
>- ModKit.Foo.Bar
>- ModKit.Quux
>ModKit.Foo
>- ModKit.Foo.Bar
>- ModKit.Quux
>ModKit.Foo.Bar
>- ModKit.Quux
>ModKit.Quux
>- ModKit.Foo
>- ModKit.Foo.Bar
> 
> However, submodules may not form circular dependencies through imports—if 
> `ModKit.Quux` imports `ModKit.Foo`, then `ModKit.Foo` cannot import 
> `ModKit.Quux`. The `#if canImport()` feature cannot be used to probe for 
> other submodules within the same top-level module you're in.
> 
> At the compiler driver level, a submodule is specified by giving a 
> `-module-name` parameter with a dot in it. When a file is compiled, only the 
> filenames of the other .swift files in the same module are specified, along 
> with .o files for any submodules; then all the .o files within that submodule 
> are linked into a single .o file for the whole submodule. So files in 
> `ModKit.Foo` would be compiled with only the .swift files in `ModKit.Foo` and 
> the .o file for `ModKit.Foo.Bar`; then all the `ModKit.Foo` .o files would be 
> linked into one .o file for the top-level `ModKit` to use. None of 
> `ModKit.Foo`'s .swift files would be included in the command line when 
> compiling the top-level `ModKit` module.
> 
> (That bit is kind of speculative—particularly the idea of linking submodule 
> files into a single .o file—but I think something like what I'm describing 
> could work.)
> 
> Because the compiler driver is used to group submodules together, Xcode can 
> specify submodules in project file metadata and calculate a submodule 
> dependency graph, while SwiftPM can use folders and compile submodules 
> whenever the compiler emits an error indicating that a file tried to import a 
> nonexistent 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

To further clarify—I think it would be accurate to say that this proposal 
introduces 2 things:

1) submodules, without changing the existing module system
2) `public` keyword for re-exporting modules

It is both unnecessary and not allowed to name the outermost module in the 
file. The `module` keyword simply introduces submodules. Notice that this works 
well with the notion of progress disclosure.

> On Feb 20, 2017, at 6:42 PM, Jaden Geller  wrote:
> 
> Jon,
> 
> I think we might have miscommunicated. It is intended that outermost module 
> is implicit; no `module` declaration is required to wrap every file. We tried 
> to show this in the first code snippet.
> 
> What do you mean “covering only part of a file”?
> 
> Cheers,
> Jaden Geller
> 
>> On Feb 20, 2017, at 6:36 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> What is the rational for having modules covering only part of a file?  
>> Wouldn’t it be less clutter to have an annotation which worked for the whole 
>> file.  At the very least it would be nice to have an option to spell it in a 
>> way that applies to the whole file.  Otherwise, everything will be indented 
>> another level.
>> 
>> I would honestly love to see something which just maps modules to 
>> folders/groups for simplicity sake.
>> 
>> I haven’t thought about it too much yet, so I could easily be missing 
>> something obvious...
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> Good Evening All,
>>> 
>>> Jaden Geller and I have been considering a (sub)module system for Swift 
>>> that would complement the existing language but also provide sorely needed 
>>> modularity.  A draft of the proposal is attached to this email, but it can 
>>> also be read as a gist 
>>>  if you 
>>> desire.
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> Modular Swift
>>> 
>>> Proposal: SE- 
>>> Authors: Robert Widmann , Jaden Geller 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting review
>>>  
>>> Introduction
>>> 
>>> Almost every major programming language supports some form of modular 
>>> programming through constructs like (sub)modules, packages, or interfaces. 
>>> Swift, though it provides top-level modules to organize code under, does 
>>> not provide a complete implementation of any of these concepts, which has 
>>> led instead to the proliferation of access control levels. This has not 
>>> proven an effective way to decompose programs into manageable parts, and 
>>> exposes the need for a real system of modules to solve this modularity 
>>> problem once and for all.
>>> 
>>> Separation of code into distinct islands of functionality should be a 
>>> first-class construct in the language, not dependent on external files and 
>>> tools or filesystems. To that end, we propose the introduction of a 
>>> lightweight module system for Swift.
>>> 
>>> Swift-evolution thread 
>>>  
>>> Motivation
>>> 
>>> Swift has reached a point in its evolution where rich libraries and large 
>>> projects that take on many dependencies have matured significantly. To 
>>> accomodate the information-hiding and semantics-signalling needs of these 
>>> users at the time, Swift began its access control story with just three 
>>> access modifiers: public, private, and internal then grew fileprivate and 
>>> open as the need to express locality of implementation and 
>>> "subclassability" arose respectively. In doing so, Swift's access control 
>>> scheme has become anti-modular.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> We propose the introduction of a lightweight module system for Swift. More 
>>> than simply namspaces, a module declaration interacts with Swift's access 
>>> control to provide an API boundary that allows better control over an 
>>> interface's design.
>>> 
>>>  
>>> Detailed
>>>  design
>>> 
>>>  
>>> Syntax
>>> 
>>> A module is a named region that introduces a lexical scope into which 
>>> declarations may be nested. The name of the module can be used to access 
>>> these member declarations. A module, like other aggregate structures in 
>>> Swift, may be extended with new declarations over one or more translation 
>>> units (files).
>>> 
>>> We propose a new declaration kind, module-decl be added to the 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 20, 2017, at 9:36 PM, Jonathan Hull  wrote:
> 
> What is the rational for having modules covering only part of a file?  
> Wouldn’t it be less clutter to have an annotation which worked for the whole 
> file.  At the very least it would be nice to have an option to spell it in a 
> way that applies to the whole file.  Otherwise, everything will be indented 
> another level.

That is a valid spelling (Rust, IIRC, allows that spelling), but one that is 
easy to miss sitting in a file and makes it confusing to introduce submodules.  
If you include the annotation then define a submodule later down in the file, 
suddenly you have to remember whether you annotated the file or whether the 
submodule you’ve just written is going into the top-level module.  See:

// -module-name=Foo
// module Foo {
module Bar; // Shorthand for “This file defines Foo.Bar”

/* Code */

// This defines “Foo.Bar.Baz”, but would you know that if it appeared below the 
fold?
module Baz {}
//}

If anything, this can be added later if evolution converges on it.

> 
> I would honestly love to see something which just maps modules to 
> folders/groups for simplicity sake.
> 

There is nothing about this scheme that prevents you from organizing your code 
this way.  However, modulo that particular method of organization, you don’t 
really gain much as a user of the language by imposing this restriction.

> I haven’t thought about it too much yet, so I could easily be missing 
> something obvious...
> 
> Thanks,
> Jon
> 
> 
>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> Good Evening All,
>> 
>> Jaden Geller and I have been considering a (sub)module system for Swift that 
>> would complement the existing language but also provide sorely needed 
>> modularity.  A draft of the proposal is attached to this email, but it can 
>> also be read as a gist 
>>  if you 
>> desire.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> Modular Swift
>> 
>> Proposal: SE- 
>> Authors: Robert Widmann , Jaden Geller 
>> 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> Almost every major programming language supports some form of modular 
>> programming through constructs like (sub)modules, packages, or interfaces. 
>> Swift, though it provides top-level modules to organize code under, does not 
>> provide a complete implementation of any of these concepts, which has led 
>> instead to the proliferation of access control levels. This has not proven 
>> an effective way to decompose programs into manageable parts, and exposes 
>> the need for a real system of modules to solve this modularity problem once 
>> and for all.
>> 
>> Separation of code into distinct islands of functionality should be a 
>> first-class construct in the language, not dependent on external files and 
>> tools or filesystems. To that end, we propose the introduction of a 
>> lightweight module system for Swift.
>> 
>> Swift-evolution thread 
>>  
>> Motivation
>> 
>> Swift has reached a point in its evolution where rich libraries and large 
>> projects that take on many dependencies have matured significantly. To 
>> accomodate the information-hiding and semantics-signalling needs of these 
>> users at the time, Swift began its access control story with just three 
>> access modifiers: public, private, and internal then grew fileprivate and 
>> open as the need to express locality of implementation and "subclassability" 
>> arose respectively. In doing so, Swift's access control scheme has become 
>> anti-modular.
>> 
>>  
>> Proposed
>>  solution
>> 
>> We propose the introduction of a lightweight module system for Swift. More 
>> than simply namspaces, a module declaration interacts with Swift's access 
>> control to provide an API boundary that allows better control over an 
>> interface's design.
>> 
>>  
>> Detailed
>>  design
>> 
>>  
>> Syntax
>> 
>> A module is a named region that introduces a lexical scope into which 
>> declarations may be nested. The name of the module can be used to access 
>> these member declarations. A module, like other aggregate structures in 
>> Swift, may be extended with new declarations over one or more translation 
>> units (files).
>> 
>> We propose a new declaration kind, module-decl be added to the language. A 
>> proposed grammar using the new 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jaden Geller via swift-evolution]

Jon,

I think we might have miscommunicated. It is intended that outermost module is 
implicit; no `module` declaration is required to wrap every file. We tried to 
show this in the first code snippet.

What do you mean “covering only part of a file”?

Cheers,
Jaden Geller

> On Feb 20, 2017, at 6:36 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> What is the rational for having modules covering only part of a file?  
> Wouldn’t it be less clutter to have an annotation which worked for the whole 
> file.  At the very least it would be nice to have an option to spell it in a 
> way that applies to the whole file.  Otherwise, everything will be indented 
> another level.
> 
> I would honestly love to see something which just maps modules to 
> folders/groups for simplicity sake.
> 
> I haven’t thought about it too much yet, so I could easily be missing 
> something obvious...
> 
> Thanks,
> Jon
> 
> 
>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> Good Evening All,
>> 
>> Jaden Geller and I have been considering a (sub)module system for Swift that 
>> would complement the existing language but also provide sorely needed 
>> modularity.  A draft of the proposal is attached to this email, but it can 
>> also be read as a gist 
>>  if you 
>> desire.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> Modular Swift
>> 
>> Proposal: SE- 
>> Authors: Robert Widmann , Jaden Geller 
>> 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> Almost every major programming language supports some form of modular 
>> programming through constructs like (sub)modules, packages, or interfaces. 
>> Swift, though it provides top-level modules to organize code under, does not 
>> provide a complete implementation of any of these concepts, which has led 
>> instead to the proliferation of access control levels. This has not proven 
>> an effective way to decompose programs into manageable parts, and exposes 
>> the need for a real system of modules to solve this modularity problem once 
>> and for all.
>> 
>> Separation of code into distinct islands of functionality should be a 
>> first-class construct in the language, not dependent on external files and 
>> tools or filesystems. To that end, we propose the introduction of a 
>> lightweight module system for Swift.
>> 
>> Swift-evolution thread 
>>  
>> Motivation
>> 
>> Swift has reached a point in its evolution where rich libraries and large 
>> projects that take on many dependencies have matured significantly. To 
>> accomodate the information-hiding and semantics-signalling needs of these 
>> users at the time, Swift began its access control story with just three 
>> access modifiers: public, private, and internal then grew fileprivate and 
>> open as the need to express locality of implementation and "subclassability" 
>> arose respectively. In doing so, Swift's access control scheme has become 
>> anti-modular.
>> 
>>  
>> Proposed
>>  solution
>> 
>> We propose the introduction of a lightweight module system for Swift. More 
>> than simply namspaces, a module declaration interacts with Swift's access 
>> control to provide an API boundary that allows better control over an 
>> interface's design.
>> 
>>  
>> Detailed
>>  design
>> 
>>  
>> Syntax
>> 
>> A module is a named region that introduces a lexical scope into which 
>> declarations may be nested. The name of the module can be used to access 
>> these member declarations. A module, like other aggregate structures in 
>> Swift, may be extended with new declarations over one or more translation 
>> units (files).
>> 
>> We propose a new declaration kind, module-decl be added to the language. A 
>> proposed grammar using the new modulekeyword is given below:
>> 
>> GRAMMAR OF A MODULE DECLARATION
>> 
>> module-declaration -> `module` module-identifier module-body
>> module-name -> identifier
>> module-body -> { module-members(opt) }
>> module-members -> module-member module-members(opt)
>> module-member -> declaration | compiler-control-statement
>> GRAMMAR OF A DECLARATION
>> 
>> + declaration -> module-declaration
>>  
>> General
>>  Semantics
>> 
>> Syntax and semantics for imports, as it already supports referencing 
>> 

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

[Jonathan Hull via swift-evolution]

What is the rational for having modules covering only part of a file?  Wouldn’t 
it be less clutter to have an annotation which worked for the whole file.  At 
the very least it would be nice to have an option to spell it in a way that 
applies to the whole file.  Otherwise, everything will be indented another 
level.

I would honestly love to see something which just maps modules to 
folders/groups for simplicity sake.

I haven’t thought about it too much yet, so I could easily be missing something 
obvious...

Thanks,
Jon


> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Good Evening All,
> 
> Jaden Geller and I have been considering a (sub)module system for Swift that 
> would complement the existing language but also provide sorely needed 
> modularity.  A draft of the proposal is attached to this email, but it can 
> also be read as a gist 
>  if you 
> desire.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Modular Swift
> 
> Proposal: SE- 
> Authors: Robert Widmann , Jaden Geller 
> 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> Almost every major programming language supports some form of modular 
> programming through constructs like (sub)modules, packages, or interfaces. 
> Swift, though it provides top-level modules to organize code under, does not 
> provide a complete implementation of any of these concepts, which has led 
> instead to the proliferation of access control levels. This has not proven an 
> effective way to decompose programs into manageable parts, and exposes the 
> need for a real system of modules to solve this modularity problem once and 
> for all.
> 
> Separation of code into distinct islands of functionality should be a 
> first-class construct in the language, not dependent on external files and 
> tools or filesystems. To that end, we propose the introduction of a 
> lightweight module system for Swift.
> 
> Swift-evolution thread 
>  
> Motivation
> 
> Swift has reached a point in its evolution where rich libraries and large 
> projects that take on many dependencies have matured significantly. To 
> accomodate the information-hiding and semantics-signalling needs of these 
> users at the time, Swift began its access control story with just three 
> access modifiers: public, private, and internal then grew fileprivate and 
> open as the need to express locality of implementation and "subclassability" 
> arose respectively. In doing so, Swift's access control scheme has become 
> anti-modular.
> 
>  
> Proposed
>  solution
> 
> We propose the introduction of a lightweight module system for Swift. More 
> than simply namspaces, a module declaration interacts with Swift's access 
> control to provide an API boundary that allows better control over an 
> interface's design.
> 
>  
> Detailed
>  design
> 
>  
> Syntax
> 
> A module is a named region that introduces a lexical scope into which 
> declarations may be nested. The name of the module can be used to access 
> these member declarations. A module, like other aggregate structures in 
> Swift, may be extended with new declarations over one or more translation 
> units (files).
> 
> We propose a new declaration kind, module-decl be added to the language. A 
> proposed grammar using the new modulekeyword is given below:
> 
> GRAMMAR OF A MODULE DECLARATION
> 
> module-declaration -> `module` module-identifier module-body
> module-name -> identifier
> module-body -> { module-members(opt) }
> module-members -> module-member module-members(opt)
> module-member -> declaration | compiler-control-statement
> GRAMMAR OF A DECLARATION
> 
> + declaration -> module-declaration
>  
> General
>  Semantics
> 
> Syntax and semantics for imports, as it already supports referencing 
> submodules imported from C and Objective-C modules, remains unchanged:
> 
> // The outermost module is given explicitly 
> // by passing `-module-name=Foo` or exists implicitly, as today.
> // module Foo {
> public class A {}
> 
> module Bar {
>   module Baz {
> public class C {}
>   }
> 
>   public class B {}
> }
> 
> let message = "Hello, Wisconsin!"
> // } // End declarations added to module Foo.
> To consume this interface:
> 
> // imports all of Foo, Foo.Bar, and Foo.Bar.Baz
> import Foo.Bar.Baz
> 
> // imports Foo.A as A
> import 

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Karl Wagner via swift-evolution]

That’s an interesting proposal. Here are the issues I see:

- I don’t like nesting everything within a large “module” block. I would like a 
top-level “@module Foo” declaration for the entire file. Also, since any 
sub-modules would be nested within the implicit top-level module, I’d prefer 
the keyword “submodule”. Otherwise, what happens if I write:

module Foundation {
// Is this a module-extension? Can I insert new types or top-level functions in 
to Foundation?
// Am I creating a new top-level module named “Foundation”?
}

Looking at this thread:

- There are certainly issues with access control of submodules. OTOH, I don’t 
really like the idea that one incorrect import in one file can expose an entire 
submodule as part of your module’s API.

More generally:

- Access control of submodules seems like something which could benefit from a 
single source of truth.
- Can submodules have independent versions? Where would we declare them?

I wonder if we should have something like “module manifest” for all of a 
library’s public submodules, similar to SwiftPM's package manifest. So, 
strawman syntax…

Module(Foo, version: 1.2.2, description: “A library for foo-ing around with”, 
submodules: [
Module(Foo.Maths, version: 1.5.0, description: “A maths library supporting 
Foo”),
Module(Foo.Formatters, version: 1.5.0, description: “Formatters for Foo 
types”)
])

So, in this case we had a module Foo, then we updated FooMaths with some new 
APIs (say some new operations/types were added, and we updated FooFormatters 
accordingly). However, the API of Foo itself hasn’t changed; it’s the same as 
it was ages ago. Would that be possible?

> On 21 Feb 2017, at 02:47, Robert Widmann via swift-evolution 
>  wrote:
> 
> You’ll be delighted to know, then, that I’ve been thinking about this for a 
> few weeks now and have a draft proposal that will be submitted for discussion 
> shortly.  I believe this can be an additive feature and still preserve all 
> the goodness you would expect of a real module system.
> 
> ~Robert Widmann
> 
>> On Feb 20, 2017, at 8:36 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> Okay, lots of people want to have some kind of submodule feature, so I'd 
>> like to sketch one out so we can hopefully agree on what submodules might 
>> look like.
>> 
>> ***
>> 
>> Any group of Swift files can be grouped together to form a submodule. 
>> Submodules belong within a particular module, and have a dotted name: If 
>> `ModKit` is a module, it might have a submodule called `ModKit.Foo`. 
>> Submodules can be nested within one another: `ModKit.Foo.Bar` is a submodule 
>> of `ModKit.Foo`, which is a submodule of `ModKit`.
>> 
>> No new access levels are necessary. `internal` APIs are only visible within 
>> the submodule they're declared in; a module cannot see its submodules' 
>> `internal` APIs, and a submodule cannot see its parent module's `internal` 
>> APIs. If a submodule wants to expose some of its APIs to its parent or 
>> sibling modules, it must mark them as `public` or `open`. Then they can 
>> import the submodule to see its APIs:
>> 
>>  import ModKit.Foo
>> 
>> By default, outside modules cannot import a submodule. But an import in the 
>> parent module can be decorated by an access control keyword to allow that:
>> 
>>  /// Any module outside ModKit can import ModKit.Foo and access its 
>> `public` and `open` APIs.
>>  open import ModKit.Foo
>> 
>>  /// Any module outside ModKit can import ModKit.Foo and access its 
>> `public` and `open` APIs, 
>>  /// except `open` APIs are treated as `public`.
>>  public import ModKit.Foo
>> 
>> Imports may also be decorated by the `@exported` attribute, which exposes 
>> the submodule's APIs as though they were parent module APIs:
>> 
>>  @exported open import ModKit.Foo
>> 
>>  @exported public import ModKit.Foo
>> 
>> (This is sort of half-implemented already in a buggy `@_exported` attribute.)
>> 
>> Finally, the standard syntax for importing individual symbols can be used to 
>> cherry-pick types to treat differently:
>> 
>>  // Most ModKit.Foo APIs are not importable...
>>  import ModKit.Foo
>> 
>>  // ...but SomeEnum can be imported as public...
>>  public import enum ModKit.Foo.SomeEnum
>> 
>>  // ...SomeClass can be imported as open...
>>  open import class ModKit.Foo.SomeClass
>> 
>>  // And ImportantStruct will import whenever you import ModKit.
>>  @exported public import struct ModKit.Foo.ImportantStruct
>> 
>> (This syntax should be enhanced to allow cherry-picked importing of global 
>> functions, constants, and variables.)
>> 
>> If there are several different `import`s covering the same submodule or 
>> submodule symbol, the most permissive one wins.
>> 
>> (In large projects, `public`, `open`, and `@exported` imports will most 
>> likely all be put in a single Policy.swift file or something, but 

[swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

Good Evening All,

Jaden Geller and I have been considering a (sub)module system for Swift that 
would complement the existing language but also provide sorely needed 
modularity.  A draft of the proposal is attached to this email, but it can also 
be read as a gist 
 if you desire.

Cheers,

~Robert Widmann

Modular Swift

Proposal: SE- 
Authors: Robert Widmann , Jaden Geller 

Review Manager: TBD
Status: Awaiting review
 
Introduction

Almost every major programming language supports some form of modular 
programming through constructs like (sub)modules, packages, or interfaces. 
Swift, though it provides top-level modules to organize code under, does not 
provide a complete implementation of any of these concepts, which has led 
instead to the proliferation of access control levels. This has not proven an 
effective way to decompose programs into manageable parts, and exposes the need 
for a real system of modules to solve this modularity problem once and for all.

Separation of code into distinct islands of functionality should be a 
first-class construct in the language, not dependent on external files and 
tools or filesystems. To that end, we propose the introduction of a lightweight 
module system for Swift.

Swift-evolution thread 
 
Motivation

Swift has reached a point in its evolution where rich libraries and large 
projects that take on many dependencies have matured significantly. To 
accomodate the information-hiding and semantics-signalling needs of these users 
at the time, Swift began its access control story with just three access 
modifiers: public, private, and internal then grew fileprivate and open as the 
need to express locality of implementation and "subclassability" arose 
respectively. In doing so, Swift's access control scheme has become 
anti-modular.

 
Proposed
 solution

We propose the introduction of a lightweight module system for Swift. More than 
simply namspaces, a module declaration interacts with Swift's access control to 
provide an API boundary that allows better control over an interface's design.

 
Detailed
 design

 Syntax

A module is a named region that introduces a lexical scope into which 
declarations may be nested. The name of the module can be used to access these 
member declarations. A module, like other aggregate structures in Swift, may be 
extended with new declarations over one or more translation units (files).

We propose a new declaration kind, module-decl be added to the language. A 
proposed grammar using the new modulekeyword is given below:

GRAMMAR OF A MODULE DECLARATION

module-declaration -> `module` module-identifier module-body
module-name -> identifier
module-body -> { module-members(opt) }
module-members -> module-member module-members(opt)
module-member -> declaration | compiler-control-statement
GRAMMAR OF A DECLARATION

+ declaration -> module-declaration
 
General
 Semantics

Syntax and semantics for imports, as it already supports referencing submodules 
imported from C and Objective-C modules, remains unchanged:

// The outermost module is given explicitly 
// by passing `-module-name=Foo` or exists implicitly, as today.
// module Foo {
public class A {}

module Bar {
  module Baz {
public class C {}
  }

  public class B {}
}

let message = "Hello, Wisconsin!"
// } // End declarations added to module Foo.
To consume this interface:

// imports all of Foo, Foo.Bar, and Foo.Bar.Baz
import Foo.Bar.Baz

// imports Foo.A as A
import class Foo.A
// imports Foo.Bar.B as B
import class Foo.Bar.B
// imports Foo.Bar.Baz.C as C
import class Foo.Bar.Baz.C
A module declaration may only appear as a top-level entity or as a member of 
another module declaration. The following code is therefore invalid:

module Foo {
  class Bar {
module Baz {} // error: module declaration cannot be nested inside type 
'Bar'
  }
}
To extend an existing module declaration, simply reference its module name in 
an extension declaration. 

// In module 'Foo'
module Bar {
  public class A {}

  module Baz {}
}

extension Bar {
  public struct B {}
}

extension Bar.Baz {
  public enum C { case D }
}
 
Modules
 and Access Control

The semantics of some existing access control modifiers shall also be extended 
to support module 

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Xiaodi Wu via swift-evolution]

On Mon, Feb 20, 2017 at 12:29 PM, Alex Blewitt  wrote:

>
> On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised
> proposal in draft form.
>
> It proposes a source-breaking change for *rationalizing* which characters
> are permitted in identifiers and which in operators.
>
> What feedback would be* most helpful*:
>
> - "Hey, this approach is so much more *clumsy* than my superior, more
> elegant category-based approach to identifying [operators/emoji], which is
> [insert here]."
> - "Hey, I disagree with the detailed design because it's got a *major
> security hole*, which is [insert here]."
> - "Hey, your proposal would break my *real-world* Swift code, which
> requires that character [X] be an [identifier/operator]."
>
>
> I like the approach taken here, and it is a much better way of concluding
> the characters. I don't disagree with the design and don't have any example
> code that will be affected, but I do have some (minor) observations about
> the proposal.
>

Thanks Alex! I've updated the document accordingly. Here's the link:
https://github.com/xwu/swift-evolution/blob/d1643c5c451232a277fe77b22fb891cdae90dcb4/proposals/-refining-identifier-and-operator-symbology.md


> * The 'Dots' treatment feels like a special case in an otherwise good
> write-up of Unicode, seemingly to lean towards Dart's method chaining
> and/or cleanliness of implementation. It might be clearer to pull that out
> to its own proposal, either independent of or building upon the general
> Unicode changes?
>

Excellent point. I've removed mentions of method cascades. The rationale
for revising the "dots rule" is clarified in the context of alignment to
Unicode (or more accurately here, skating to where Unicode will be).

* The grammar changes for the operator head contain a number of (what seems
> like) hand-picked unicode symbols for increased compatibility with Swift 3
> (e.g. dagger and friends). Maybe these could be pulled out into their own
> group e.g. operator-head -> operator-head-swift3, to call out the reason
> for their hand-picked nature (and for later cleanup, should that be
> required).
>

Done.


> * The proposed solution tables (shall be an identifier/is an identifier)
> wasn't clear to me at first what the rows and columns were. Maybe calling
> these out as a bulleted list would be better:
>
> - Identifiers under Swift 3 and this proposal: 120,617 code points
> - Identifiers that would be added under this proposal: 699 emoji
> - Identifiers under Swift 3 that would no longer be an identifier:
> unassigned code points and 4,929 other code points
>
> Similarly, for operators:
>
> - Operators under Swift 3 and this proposal: 986 code points
> - Operators that would be added under this proposal: \
> - Operators under Swift 3 that would no longer be an identifier:
> unassigned code points and 2,024 other code points
>
> You could summarise that as a pseudo-diff --stat
>
> Identifiers
> + 699 emoji
>   120,617 code points
> - 4,929 code points and unassigned code points
>
> Operators
> + 1 code point \
>   986 code points
> - 2,024 code points
>
> Alternatively you could change the 'Is an identifier/operator' to 'Is a
> Swift 3 identifier' to make it clear that it's the Swift 3 header, but the
> tabular form is still not that clear to me.
>

I've converted this to bulleted lists like you suggest.


> Another stat that would be worth calling out: of the 2,042 code points
> that are no longer operators, what the overlap is with the 699 emoji that
> are added to the identifiers? If they were all of them then it would only
> be 1,325 operators that were no longer valid.
>

The answer to that is 98; the 601 are emoji sequences that weren't
permitted previously. I've incorporated this information into the text.


> To conclude: I like the look of the proposal from the block set
> definition, which will be better than hand-picking the character set as the
> grammar currently stands.
>
> Alex
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Dictionary Enhancements

[Brent Royal-Gordon via swift-evolution]

> On Feb 20, 2017, at 10:19 AM, Ben Cohen  wrote:
> 
> As it is right now, that wouldn’t distinguish it since Sequence.filter on 
> Dictionary can already take a (Key,Value)->Bool transformation since 
> (Key,Value) is the Element type:
> let d = [1:"1"]
> let f: (Int,String)->Bool = {_,_ in true }
> d.filter(f) // [(key: 1, value: "1")]

From what I understand, this is implicit tuple splatting and shouldn't be 
allowed anymore. Or am I wrong about that?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

[Joe Groff via swift-evolution]

> On Feb 20, 2017, at 1:53 PM, Matthew Johnson  wrote:
> 
>> 
>> On Feb 20, 2017, at 3:22 PM, Joe Groff > > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 1:04 PM, Matthew Johnson >> > wrote:
>>> 
 
 On Feb 20, 2017, at 2:38 PM, Joe Groff > wrote:
 
> 
> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution 
>> > wrote:
>> 
>> I'd like to discuss the possibility of treating the cases of a given 
>> enum as if they are subtypes of that enum. This seems like a natural 
>> thing to do because enum cases (especially when they have associated 
>> values) effectively define a closed set of subtypes.
>> 
>> Doing so would allow for constructions such as the following:
>> 
>> enum Foo {
>>   case a(name: String)
>> }
>> 
>> func isA(foo: Foo) -> Bool {
>>   // The old way:
>>   if case .a = foo { return true }
>>   return false
>>   // The new way:
>>   return foo is .a
>> }
>> 
>> func printNameIfFooIsA(foo: Foo) -> Bool {
>>   // The old way:
>>   if case let .a(name) = foo {
>> print(name)
>>   }
>>   // The new way (1):
>>   if let a = foo as? .a {
>> print(a.name )
>>   }
>>   // The new way (2):
>>   if let name = (foo as? .a)?.name {
>> print(name)
>>   }
>> }
>> 
>> Treating an enum's cases as its subtypes would make enums easier to work 
>> with because handling them would be syntactically the same as handling 
>> other types.
>> 
>> The pattern matching capabilities of enums wouldn't be affected by this 
>> proposal.
>> 
>> Multiple other proposals have already attempted to simplify enum 
>> handling (they have particularly focused on getting rid of "if case" and 
>> adding the ability to treat enum case tests as expressions), but none of 
>> the solutions presented in those proposals have worked out so far.
>> 
>> I believe that this could be the right solution to multiple enum-related 
>> problems that have been brought up repeatedly.
> 
> I would like to see enum cases treated as subtypes of the enum type.  
> This is an interesting way to refer to the type of a case.  Unfortunately 
> I don’t think it will work if we accept the proposal to give cases a 
> compound name.  If we do that the name of this case becomes `a(name:)` 
> which is not a valid type name.
 
 I think there are definitely places where having cases be a subtype of an 
 enum make sense, but I don't think it makes sense for *all* cases to be 
 subtypes. For example, with "biased" containers like Optional and Result, 
 it makes sense for the "right" side to be a subtype and the "wrong" side 
 to be explicitly constructed, IMO.  If the types of cases overlap, it 
 would also be *ambiguous* which case ought to be constructed when the 
 payload is converted to the enum type
>>> 
>>> Identical case types would definitely be a problem but I don’t think 
>>> overlapping case types are always a problem.  I imagine this conversion 
>>> working the same as any other ordinary overload resolution for ad-hoc 
>>> overloads.
>> 
>> Conversions happen at runtime too. `0 as Any as? Either` wouldn't 
>> have any way to tell what `Either` to form if both arms of the Either were 
>> subtype candidates. An Either in  context can end up being bound 
>> to Either at runtime and interacting with runtime casts that way.
> 
> Hmm.  This is unfortunate.
> 
> In cases where T and U overlap and form a linear hierarchy but are not 
> identical couldn’t the runtime determine the most direct path and choose that?
> 
> If the compiler prohibited cases with exactly the same types like 
> `Either` from being expressed statically how do these types end up 
> getting formed dynamically?  Is there any way those operations could be 
> failable?
> 
> 
>> 
>>> 
 —remember that enums are sums, not unions, and that's important for 
 composability and uniform behavior with generics. 
>>> 
>>> I’ve always thought of enums as nominal discriminated unions.  Maybe I’m 
>>> using the wrong terminology.  Can you elaborate on the difference between 
>>> sums and unions?  When you say union are you talking about the kind of 
>>> thing some people have brought up in the past where any members in common 
>>> are automatically made available on the union type?
>> 
>> Sums maintain structure whereas unions collapse it. As a sum, Optional 
>> 

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Robert Widmann via swift-evolution]

You’ll be delighted to know, then, that I’ve been thinking about this for a few 
weeks now and have a draft proposal that will be submitted for discussion 
shortly.  I believe this can be an additive feature and still preserve all the 
goodness you would expect of a real module system.

~Robert Widmann

> On Feb 20, 2017, at 8:36 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Okay, lots of people want to have some kind of submodule feature, so I'd like 
> to sketch one out so we can hopefully agree on what submodules might look 
> like.
> 
> ***
> 
> Any group of Swift files can be grouped together to form a submodule. 
> Submodules belong within a particular module, and have a dotted name: If 
> `ModKit` is a module, it might have a submodule called `ModKit.Foo`. 
> Submodules can be nested within one another: `ModKit.Foo.Bar` is a submodule 
> of `ModKit.Foo`, which is a submodule of `ModKit`.
> 
> No new access levels are necessary. `internal` APIs are only visible within 
> the submodule they're declared in; a module cannot see its submodules' 
> `internal` APIs, and a submodule cannot see its parent module's `internal` 
> APIs. If a submodule wants to expose some of its APIs to its parent or 
> sibling modules, it must mark them as `public` or `open`. Then they can 
> import the submodule to see its APIs:
> 
>   import ModKit.Foo
> 
> By default, outside modules cannot import a submodule. But an import in the 
> parent module can be decorated by an access control keyword to allow that:
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs.
>   open import ModKit.Foo
> 
>   /// Any module outside ModKit can import ModKit.Foo and access its 
> `public` and `open` APIs, 
>   /// except `open` APIs are treated as `public`.
>   public import ModKit.Foo
> 
> Imports may also be decorated by the `@exported` attribute, which exposes the 
> submodule's APIs as though they were parent module APIs:
> 
>   @exported open import ModKit.Foo
> 
>   @exported public import ModKit.Foo
> 
> (This is sort of half-implemented already in a buggy `@_exported` attribute.)
> 
> Finally, the standard syntax for importing individual symbols can be used to 
> cherry-pick types to treat differently:
> 
>   // Most ModKit.Foo APIs are not importable...
>   import ModKit.Foo
> 
>   // ...but SomeEnum can be imported as public...
>   public import enum ModKit.Foo.SomeEnum
> 
>   // ...SomeClass can be imported as open...
>   open import class ModKit.Foo.SomeClass
> 
>   // And ImportantStruct will import whenever you import ModKit.
>   @exported public import struct ModKit.Foo.ImportantStruct
> 
> (This syntax should be enhanced to allow cherry-picked importing of global 
> functions, constants, and variables.)
> 
> If there are several different `import`s covering the same submodule or 
> submodule symbol, the most permissive one wins.
> 
> (In large projects, `public`, `open`, and `@exported` imports will most 
> likely all be put in a single Policy.swift file or something, but this is not 
> enforced by the language.)
> 
> A submodule may not import any direct parent module (parent, grandparent, 
> etc.), but may import any other submodule in the same module. This list shows 
> permitted imports for a project with four modules/submodules:
> 
>   ModKit
>   - ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo
>   - ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Foo.Bar
>   - ModKit.Quux
>   ModKit.Quux
>   - ModKit.Foo
>   - ModKit.Foo.Bar
> 
> However, submodules may not form circular dependencies through imports—if 
> `ModKit.Quux` imports `ModKit.Foo`, then `ModKit.Foo` cannot import 
> `ModKit.Quux`. The `#if canImport()` feature cannot be used to probe for 
> other submodules within the same top-level module you're in.
> 
> At the compiler driver level, a submodule is specified by giving a 
> `-module-name` parameter with a dot in it. When a file is compiled, only the 
> filenames of the other .swift files in the same module are specified, along 
> with .o files for any submodules; then all the .o files within that submodule 
> are linked into a single .o file for the whole submodule. So files in 
> `ModKit.Foo` would be compiled with only the .swift files in `ModKit.Foo` and 
> the .o file for `ModKit.Foo.Bar`; then all the `ModKit.Foo` .o files would be 
> linked into one .o file for the top-level `ModKit` to use. None of 
> `ModKit.Foo`'s .swift files would be included in the command line when 
> compiling the top-level `ModKit` module.
> 
> (That bit is kind of speculative—particularly the idea of linking submodule 
> files into a single .o file—but I think something like what I'm describing 
> could work.)
> 
> Because the compiler driver is used to 

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Derrick Ho via swift-evolution]

Oh, I thought this would be another discussion about namespaces.
On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon 
> wrote:
> >
> > Okay, lots of people want to have some kind of submodule feature, so I'd
> like to sketch one out so we can hopefully agree on what submodules might
> look like.
>
> Ten seconds after sending this, I realized I forgot an important caveat: I
> don't expect this to be a feature of Swift 4, no matter how much we might
> want it. I just think that having a design in mind may help inform our
> thinking about access modifiers.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Let's talk about submodules

[Brent Royal-Gordon via swift-evolution]

> On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon  
> wrote:
> 
> Okay, lots of people want to have some kind of submodule feature, so I'd like 
> to sketch one out so we can hopefully agree on what submodules might look 
> like.

Ten seconds after sending this, I realized I forgot an important caveat: I 
don't expect this to be a feature of Swift 4, no matter how much we might want 
it. I just think that having a design in mind may help inform our thinking 
about access modifiers.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Pitch] Let's talk about submodules

[Brent Royal-Gordon via swift-evolution]

Okay, lots of people want to have some kind of submodule feature, so I'd like 
to sketch one out so we can hopefully agree on what submodules might look like.

***

Any group of Swift files can be grouped together to form a submodule. 
Submodules belong within a particular module, and have a dotted name: If 
`ModKit` is a module, it might have a submodule called `ModKit.Foo`. Submodules 
can be nested within one another: `ModKit.Foo.Bar` is a submodule of 
`ModKit.Foo`, which is a submodule of `ModKit`.

No new access levels are necessary. `internal` APIs are only visible within the 
submodule they're declared in; a module cannot see its submodules' `internal` 
APIs, and a submodule cannot see its parent module's `internal` APIs. If a 
submodule wants to expose some of its APIs to its parent or sibling modules, it 
must mark them as `public` or `open`. Then they can import the submodule to see 
its APIs:

import ModKit.Foo

By default, outside modules cannot import a submodule. But an import in the 
parent module can be decorated by an access control keyword to allow that:

/// Any module outside ModKit can import ModKit.Foo and access its 
`public` and `open` APIs.
open import ModKit.Foo

/// Any module outside ModKit can import ModKit.Foo and access its 
`public` and `open` APIs, 
/// except `open` APIs are treated as `public`.
public import ModKit.Foo

Imports may also be decorated by the `@exported` attribute, which exposes the 
submodule's APIs as though they were parent module APIs:

@exported open import ModKit.Foo

@exported public import ModKit.Foo

(This is sort of half-implemented already in a buggy `@_exported` attribute.)

Finally, the standard syntax for importing individual symbols can be used to 
cherry-pick types to treat differently:

// Most ModKit.Foo APIs are not importable...
import ModKit.Foo

// ...but SomeEnum can be imported as public...
public import enum ModKit.Foo.SomeEnum

// ...SomeClass can be imported as open...
open import class ModKit.Foo.SomeClass

// And ImportantStruct will import whenever you import ModKit.
@exported public import struct ModKit.Foo.ImportantStruct

(This syntax should be enhanced to allow cherry-picked importing of global 
functions, constants, and variables.)

If there are several different `import`s covering the same submodule or 
submodule symbol, the most permissive one wins.

(In large projects, `public`, `open`, and `@exported` imports will most likely 
all be put in a single Policy.swift file or something, but this is not enforced 
by the language.)

A submodule may not import any direct parent module (parent, grandparent, 
etc.), but may import any other submodule in the same module. This list shows 
permitted imports for a project with four modules/submodules:

ModKit
- ModKit.Foo
- ModKit.Foo.Bar
- ModKit.Quux
ModKit.Foo
- ModKit.Foo.Bar
- ModKit.Quux
ModKit.Foo.Bar
- ModKit.Quux
ModKit.Quux
- ModKit.Foo
- ModKit.Foo.Bar

However, submodules may not form circular dependencies through imports—if 
`ModKit.Quux` imports `ModKit.Foo`, then `ModKit.Foo` cannot import 
`ModKit.Quux`. The `#if canImport()` feature cannot be used to probe for other 
submodules within the same top-level module you're in.

At the compiler driver level, a submodule is specified by giving a 
`-module-name` parameter with a dot in it. When a file is compiled, only the 
filenames of the other .swift files in the same module are specified, along 
with .o files for any submodules; then all the .o files within that submodule 
are linked into a single .o file for the whole submodule. So files in 
`ModKit.Foo` would be compiled with only the .swift files in `ModKit.Foo` and 
the .o file for `ModKit.Foo.Bar`; then all the `ModKit.Foo` .o files would be 
linked into one .o file for the top-level `ModKit` to use. None of 
`ModKit.Foo`'s .swift files would be included in the command line when 
compiling the top-level `ModKit` module.

(That bit is kind of speculative—particularly the idea of linking submodule 
files into a single .o file—but I think something like what I'm describing 
could work.)

Because the compiler driver is used to group submodules together, Xcode can 
specify submodules in project file metadata and calculate a submodule 
dependency graph, while SwiftPM can use folders and compile submodules whenever 
the compiler emits an error indicating that a file tried to import a 
nonexistent submodule. Other build systems can do whatever best suits their 
style.

***

Thoughts?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] 'Public' class visibility specifiers

[Derrick Ho via swift-evolution]

I've thought about how to deal with override in a way that is consistent
with the language. Maybe something like this?

// publicly visible but can't be subclassed.
public private(subclass)

// publicly visible and may be subclasses within the module. The default
public internal(subclass)

// publicly visible and may be subclasses by all.
public public(subclass)

We also can not forget how it apples to methods

public private(override)
public internal(override)
public public(override)

On Mon, Feb 20, 2017 at 2:12 PM Joanna Carter via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Le 20 févr. 2017 à 19:18, Dimitri Racordon 
> a écrit :
> >
> > Sorry I pressed the wrong button, and the mail was sent right away.
> > I was about to add that I could give it a try, or offer my help.
>
> Since I still haven't worked out how to submit a proposal, if you know how
> to, maybe you should take the lead.
>
> If you want to contact me offline during the preparation, please feel free
>
> --
> Joanna Carter
> Carter Consulting
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Abe Schneider via swift-evolution]

> 
> Well I was rather thinking of making a Swift-only library (at least at first) 
> but that would also be available for other platforms e.g Linux or maybe some 
> day on Windows => also working with reduced performance without the 
> Accelerator Framework but leveraging it on Apple Platforms (and possibly 
> leveraging others on the other platforms). This said I am open to discussion 
> on this... but having a very nice syntax for swift and having an close to 
> one-to-one equivalent also for Objective-C will probably add quite some 
> difficulties.
> 

While still very much in its infancy, just to add the libraries out there, 
there is: https://github.com/abeschneider/stem 
 . However, the library currently suffers 
from design issues related to dispatching correctly from generic functions. 
That said, I was able to recreate a large part of the Numpy functionality while 
allowing the ability to leverage the Accelerator Framework and OpenCL/CUDA.

> > again, with the obvious implementation, this wastes space for temporaries 
> > and results in extraneous passes through the data. It is often *possible* 
> > to solve these issues (at least for some the most common cases) by 
> > producing proxy objects that can fuse loops, but that gets very messy very 
> > fast, and it’s ton of work to support all the interesting cases.
> 
> This is clear to me and to be honest with you I am not really sure of the 
> best strategy to make this. 

The most successful method I’ve seen for dealing with this is let the user 
write what is most natural first (allowing for temporaries) but provide a path 
to optimize (using in-place operations). While expression trees can automate 
this for the user, it also has the potential for being much more difficult to 
debug and may not be as optimal as a hand-crafted expression.

> 
> I don't think that the primary target for the library should be to deliver 
> the highest performance possible.
>   => People who do need that level of performance would still need to analyze 
> and optimize their code by themselves and/or directly call the Acceleration 
> Framework or other specialized libraries.
> 
> What I would like to reach instead is rather what I would call "the highest 
> usability possible with decent performance". Some programmers will be 
> satisfied with the level of performance and will enjoy the readability and 
> maintainability of the code based of the library, whereas other will go for 
> more performant libraries (and that is perfectly fine!). Actually, I would 
> even expect later that some of those who belong to the latter category will 
> start experimenting with the easy but less performant library (lets call it 
> here "easy maths library") and optimize their code based on a high 
> performance library only in a second step.

If you can define your operations at the right granularity you can write really 
optimized Accelerate/OpenCL/CUDA code for the low level parts and string it 
together with less optimize code.

> 
> My idea of a possibly pragmatic roadmap (which can be followed in that order) 
> to make such a library almost from scratch with the long-term goal of being 
> quite performant but primarily very easy to use could be:
> 
> 1) think about the integration to the language, the syntax, the high-level 
> user documentation, etc. and demonstrate all this based on a relatively low 
> performance implementation
> 
> 2) generate a collection a typical operations where the low-level libraries 
> offer very nice performance or where a clever handling of the temporary 
> variables is possible

For (1) and (2), it’s worth taking a look at what libraries exist already. 
People have spent a lot of time organizing and re-organizing these. While not 
perfect, Numpy has become one of the most successful matrix libraries out there.


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

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

I like how the Enum version looks

@objc enum Planet: String {}

But it looks odd for structs

@objc struct Planet: String {}

What do you think we should use?
On Mon, Feb 20, 2017 at 8:05 PM Derrick Ho  wrote:

> Swift Enum strings should not translate into objective c global static
> strings.
>
> As I wrote in my proposal
>
> (
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
> )
>
> , we need to support a failable initializer.
>
> I chose @objcstring to keep it consistent with how it would be used with
> struct for NS_EXTENSIBLE_STRING_ENUM. While an enum can inherit from
> String, a struct does not. So the evidence that this is meant to be used
> for strings is not there. That is why I suggest @objcstring to make that
> explicit and consistent between the two kinds.
>
>
>
> On Mon, Feb 20, 2017 at 7:33 PM Xiaodi Wu  wrote:
>
> Agree. If technical limitations do not prohibit it, Kevin's idea seems the
> more elegant.
>
>
> On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t think we need/want to add `@objcstring` or anything like that, but
> I do think we should let String enums be @objc (currently it’s int types
> only) and imported as const refs.
>
> // Already works
> @objc enum IntEnum: Int {
> case foo = 1
> case bar = 2
> }
>
> // "not an integer type"
> // Should be allowed.
> @objc enum StrEnum: String {
> case foo
> case bar = "baz"
> }
>
> Becomes
>
> // Current
> typedef NS_ENUM(NSInteger, IntEnum) {
> IntEnumFoo = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally initialized const in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
> ___
> 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] Treating an Enum's Cases as Its Subtypes

[Jonathan Hull via swift-evolution]

Just playing devil’s advocate for a second:
What if, instead of having an explicit annotation, we make a simple rule to 
break ambiguity.  That is, if the type is unambiguous, we use that, and if it 
is ambiguous, we use the first one (as defined by the creation/definition 
order). Then we have an explicit annotation to override that when it is wrong.

That said, I am on the fence about implicit conversion here.  I really like the 
‘is .a’ notation, but automatically promoting from String/Int/Etc… might be 
unexpected in the wrong context.  I do want conversion in some cases, but as 
Joe says, there might be other cases where I would want to require explicit 
opt-in of some sort to enable implicit conversion.  I could see that opt-in 
potentially being on the whole enum though (like ‘indirect’).

I am on the fence though… I could be convinced.



> On Feb 20, 2017, at 12:38 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution 
>>> > wrote:
>>> 
>>> I'd like to discuss the possibility of treating the cases of a given enum 
>>> as if they are subtypes of that enum. This seems like a natural thing to do 
>>> because enum cases (especially when they have associated values) 
>>> effectively define a closed set of subtypes.
>>> 
>>> Doing so would allow for constructions such as the following:
>>> 
>>> enum Foo {
>>>   case a(name: String)
>>> }
>>> 
>>> func isA(foo: Foo) -> Bool {
>>>   // The old way:
>>>   if case .a = foo { return true }
>>>   return false
>>>   // The new way:
>>>   return foo is .a
>>> }
>>> 
>>> func printNameIfFooIsA(foo: Foo) -> Bool {
>>>   // The old way:
>>>   if case let .a(name) = foo {
>>> print(name)
>>>   }
>>>   // The new way (1):
>>>   if let a = foo as? .a {
>>> print(a.name )
>>>   }
>>>   // The new way (2):
>>>   if let name = (foo as? .a)?.name {
>>> print(name)
>>>   }
>>> }
>>> 
>>> Treating an enum's cases as its subtypes would make enums easier to work 
>>> with because handling them would be syntactically the same as handling 
>>> other types.
>>> 
>>> The pattern matching capabilities of enums wouldn't be affected by this 
>>> proposal.
>>> 
>>> Multiple other proposals have already attempted to simplify enum handling 
>>> (they have particularly focused on getting rid of "if case" and adding the 
>>> ability to treat enum case tests as expressions), but none of the solutions 
>>> presented in those proposals have worked out so far.
>>> 
>>> I believe that this could be the right solution to multiple enum-related 
>>> problems that have been brought up repeatedly.
>> 
>> I would like to see enum cases treated as subtypes of the enum type.  This 
>> is an interesting way to refer to the type of a case.  Unfortunately I don’t 
>> think it will work if we accept the proposal to give cases a compound name.  
>> If we do that the name of this case becomes `a(name:)` which is not a valid 
>> type name.
> 
> I think there are definitely places where having cases be a subtype of an 
> enum make sense, but I don't think it makes sense for *all* cases to be 
> subtypes. For example, with "biased" containers like Optional and Result, it 
> makes sense for the "right" side to be a subtype and the "wrong" side to be 
> explicitly constructed, IMO. If the types of cases overlap, it would also be 
> *ambiguous* which case ought to be constructed when the payload is converted 
> to the enum type—remember that enums are sums, not unions, and that's 
> important for composability and uniform behavior with generics. I would be 
> fine allowing enum subtyping with some opt-in attribute, e.g.:
> 
> enum Optional {
>   sub case some(wrapped)
>   case none
> }
> 
> enum Result {
>   sub case ok(wrapped)
>   case error(Error) // not a subtype
> }
> 
> enum JSON {
>   // OK for these to all be sub-cases, since they don't overlap
>   sub case string(String), number(Double), array([JSON]), object([String: 
> JSON]), null
> }
> 
> enum Either {
>   // Error: sub cases potentially overlap
>   sub case left(T), right(U)
> }
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Compile-time generic specialization

[Abe Schneider via swift-evolution]

Sorry, I forgot to copy in its definition:

typealias T = Tensor

As a quick sanity check I changed all `T.` syntax to `Tensor` and got the 
same behavior.

Thanks!

> On Feb 20, 2017, at 3:58 PM, David Sweeris  wrote:
> 
> 
> On Feb 20, 2017, at 12:23, Abe Schneider via swift-evolution 
> > wrote:
> 
>> However, if I define an operation to on the Tensor:
>> 
>> class SomeOp {
>> typealias StorageType = S
>> var output:Tensor
>> 
>> init() {
>> output = Tensor(size: 10)
>> }
>> 
>> func apply() -> Tensor {
>> let result = T.cos(output)
>> return result
>> }
>> }
>> 
>> let op1 = SomeOp()
>> let result3 = op1.apply() // calls default `cos` instead of FloatStorage 
>> version
>> 
>> 
>> 
>> So one question I have is why doesn’t the correct version of `cos` get 
>> called? Before it was because there wasn’t a vtable available to figure out 
>> which function to call. However, in this case since the function was defined 
>> in the class, I would assume there would be (I also tried variants of this 
>> with an accompanying protocol and non-static versions of the function).
>> 
>> 
>> I can get `SomeOp` to work correctly if I create specializations of the 
>> class:
>> 
>> extension SomeOp where S:FloatStorage {
>> func apply() -> Tensor {
>> let result = T.cos(output)
>> return result
>> }
>> }
>> 
>> extension SomeOp where S:IntStorage {
>> func apply() -> Tensor {
>> let result = T.cos(output)
>> return result
>> }
>> }
>> 
>> 
>> However, this doesn’t seem like a good design to me, as it requires copying 
>> the same code for each StorageType introduced.
> 
> Where is T defined? What happens if you replace "T" with "Tensor"?
> 
> - Dave Sweeris 

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

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

Swift Enum strings should not translate into objective c global static
strings.

As I wrote in my proposal

(
https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
)

, we need to support a failable initializer.

I chose @objcstring to keep it consistent with how it would be used with
struct for NS_EXTENSIBLE_STRING_ENUM. While an enum can inherit from
String, a struct does not. So the evidence that this is meant to be used
for strings is not there. That is why I suggest @objcstring to make that
explicit and consistent between the two kinds.



On Mon, Feb 20, 2017 at 7:33 PM Xiaodi Wu  wrote:

> Agree. If technical limitations do not prohibit it, Kevin's idea seems the
> more elegant.
>
>
> On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t think we need/want to add `@objcstring` or anything like that, but
> I do think we should let String enums be @objc (currently it’s int types
> only) and imported as const refs.
>
> // Already works
> @objc enum IntEnum: Int {
> case foo = 1
> case bar = 2
> }
>
> // "not an integer type"
> // Should be allowed.
> @objc enum StrEnum: String {
> case foo
> case bar = "baz"
> }
>
> Becomes
>
> // Current
> typedef NS_ENUM(NSInteger, IntEnum) {
> IntEnumFoo = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally initialized const in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 6:54 PM, Michel Fortin  wrote:
> 
>> 
>> Le 20 févr. 2017 à 18:02, Matthew Johnson  a écrit :
>> 
>> 
>>> On Feb 20, 2017, at 4:50 PM, Michel Fortin  wrote:
>>> 
 Le 20 févr. 2017 à 14:45, Matthew Johnson  a écrit 
 :
 
> 
> On Feb 20, 2017, at 1:42 PM, Michel Fortin  
> wrote:
> 
>> Le 20 févr. 2017 à 14:23, Charles Srstka  a 
>> écrit :
>> 
>> I’m not sure how I feel about that, since it hamstrings the ability to 
>> improve APIs in a lot of ways without breaking backwards compatibility. 
>> A quick example off the top of my head would be all the Cocoa APIs that 
>> started out having ivars representing paths backed by simple getter 
>> methods, and were later refactored to be URL-based, but with the 
>> original path properties become computed properties pointing to the 
>> URL’s “path” property. With this, properties would not be able to be 
>> refactored in this way unless the library developer had previously 
>> declared the “path” property as private(set), which is unlikely for a 
>> property that was not intended to be changed after the class was 
>> initialized.
> 
> Version 1:
> 
>   public class A {
>   public let path: String
>   }
> 
> Version 2:
> 
>   public class A {
>   public pure var path: String { return url.path }
>   public let path: URL
>   }
> 
> This is assuming `let` is implicitly pure. It probably should not be. Or 
> at least it should not when crossing module boundaries. Note that 
> internal to the module it wouldn't violate any contract to allow pure 
> code access to `let` variables.
> 
> Which makes me think of an idea: internal to the module, `pure` could be 
> inferred for everything. Only the published APIs would require the 
> annotations, and only if you want `pure` to be part of the API contract. 
> Attaching `pure` to an internal function could still be useful for your 
> own reasoning though.
 
 That’s a very interesting approach that could lighten the syntactic load.  
 We could strategically annotate our code where we want purity verified, 
 but otherwise omit the annotation for members that don’t need to be 
 visible outside the module.  This approach works especially well for 
 closures.  I like it a lot!
>>> 
>>> There is an important limitation to this though: a class method that mutate 
>>> something in the class is never going to be implicitly pure (per the rules 
>>> of purity for instance methods). For that the compiler would have to prove 
>>> the method is only called from unique references, and that'd be a bit weird 
>>> (add a method call somewhere and suddenly the function becomes impure).
>> 
>> That seems totally fine to me.
>> 
>>> 
>>> There's also an issue with diagnostics: say you have func1 that calls func2 
>>> that calls func3. Func1 is `pure`, the other two are pure only implicitly. 
>>> Then you change something in func3, and suddenly func1 complains that it 
>>> can't call impure func2 and you are left wondering why because you haven't 
>>> changed anything in func2. Perhaps the compiler could dig in the call tree 
>>> to find the impure operation and tell you, but that's starting to look like 
>>> the awful diagnostic messages for C++ templates.
>>> 
>>> So now I'm starting to think this idea of inferring purity was perhaps a 
>>> bit reckless.
>> 
>> It all depends on how people use it (that’s why I mentioned strategic 
>> annotations), but yeah it could be ugly.  I wonder if there is a reasonable 
>> way to bound the inference to keep error messages tractable.  For example, 
>> you mentioned inference within a module.  If that’s too broad a scope for 
>> inference, maybe within a file would be ok and annotation would be required 
>> for anything with `internal` or greater visibility.  This would still 
>> address closures which would be cool and outside of crazy large files it 
>> wouldn’t be too bad to track down the meaning of an error.
> 
> If a closure can be inferred pure, then it should be pure. We already infer 
> `throws` and return types for closures, so inferring `pure` is natural. But 
> for functions declared with a full signature, I'm hesitant to allow them to 
> be inferred.
> 
> Now that I think of it, overrides could be another source of problem with 
> inference: add an impure override and the method in the base class can no 
> longer be inferred as pure. So it can't apply to any non-final class property 
> or function.

Yeah, I’m ok with requiring annotation if inference is going to be hairy or 
confusing.

> 
> -- 
> Michel Fortin
> https://michelf.ca 
___

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

[Sean Heber via swift-evolution]

It might have been suggested (this discussion is huge), but I think private 
could just be defined more or less like a combination of Swift 3 fileprivate 
and private with one little twist - it is also accessible from extensions in 
other files internal to the defining module.

Module 1 File A.swift:

public class Foo {
  private var property: Int
}

class Bar {
  // a Foo's property could be accessible inside here
}

extension Foo {
  // property is accessible 
}


Module 1 File B.swift:

// a Foo's property is NOT accessible 

extension Foo {
  // property is accessible in internal extension
}


Module 2 File C.swift:

// a Foo's property is NOT accessible

extension Foo {
  // property is STILL NOT accessible here
}


l8r
Sean

Sent from my iPad

> On Feb 20, 2017, at 6:22 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 21 Feb 2017, at 01:00, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> I'm terribly sorry to be _that guy_, but I have to interject that 
>> `private(file)` was discussed extensively during review for SE-0025, that 
>> the full scheme laid out in the first message of this thread was given 
>> consideration, and that the core team took these suggestions into account 
>> before accepting and implementing `fileprivate`.
>> 
>> Now, it has been said that real-world experience opens the door to 
>> reconsidering the substantive content of SE-0025 (as in, whether "new" 
>> private should exist at all). It has also long been said that a superior 
>> name would be considered instead of `fileprivate` if someone came up with 
>> one. But clearly, if hundreds of messages advocating for `private(file)` did 
>> not cause the core team to consider it to be a superior name, it is 
>> exceedingly poor form to keep bringing it up again. It's already exhausting 
>> to bikeshed upcoming features, but this shed has already shipped.
>> 
> 
> We are seeing lots of topics about access control in general. It’s clear 
> people aren’t completely satisfied, but I don’t have a clear, coherent 
> picture of what people dislike the most.
> 
> Personally, I just don’t like fileprivate, just like I didn’t like it’s ol’ 
> pap, file-scoped “private”. Especially now we don’t have header files, I 
> sometimes want to restrict access of a member to certain other types without 
> making them exposed throughout the entire module (so the rest of my internal 
> code is written in the closest thing to the client’s experience). At the same 
> time, sticking everything in to one enormous file can sometimes be hard to 
> manage - I end up with quarter-screens full of whitespace to act as visual 
> separators.
> 
> I don’t know exactly what to suggest, but I feel we need to organise and 
> answer the general grievances about access control and update the FAQ.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michel Fortin via swift-evolution]

> Le 20 févr. 2017 à 18:02, Matthew Johnson  a écrit :
> 
> 
>> On Feb 20, 2017, at 4:50 PM, Michel Fortin  wrote:
>> 
>>> Le 20 févr. 2017 à 14:45, Matthew Johnson  a écrit :
>>> 
 
 On Feb 20, 2017, at 1:42 PM, Michel Fortin  
 wrote:
 
> Le 20 févr. 2017 à 14:23, Charles Srstka  a 
> écrit :
> 
> I’m not sure how I feel about that, since it hamstrings the ability to 
> improve APIs in a lot of ways without breaking backwards compatibility. A 
> quick example off the top of my head would be all the Cocoa APIs that 
> started out having ivars representing paths backed by simple getter 
> methods, and were later refactored to be URL-based, but with the original 
> path properties become computed properties pointing to the URL’s “path” 
> property. With this, properties would not be able to be refactored in 
> this way unless the library developer had previously declared the “path” 
> property as private(set), which is unlikely for a property that was not 
> intended to be changed after the class was initialized.
 
 Version 1:
 
public class A {
public let path: String
}
 
 Version 2:
 
public class A {
public pure var path: String { return url.path }
public let path: URL
}
 
 This is assuming `let` is implicitly pure. It probably should not be. Or 
 at least it should not when crossing module boundaries. Note that internal 
 to the module it wouldn't violate any contract to allow pure code access 
 to `let` variables.
 
 Which makes me think of an idea: internal to the module, `pure` could be 
 inferred for everything. Only the published APIs would require the 
 annotations, and only if you want `pure` to be part of the API contract. 
 Attaching `pure` to an internal function could still be useful for your 
 own reasoning though.
>>> 
>>> That’s a very interesting approach that could lighten the syntactic load.  
>>> We could strategically annotate our code where we want purity verified, but 
>>> otherwise omit the annotation for members that don’t need to be visible 
>>> outside the module.  This approach works especially well for closures.  I 
>>> like it a lot!
>> 
>> There is an important limitation to this though: a class method that mutate 
>> something in the class is never going to be implicitly pure (per the rules 
>> of purity for instance methods). For that the compiler would have to prove 
>> the method is only called from unique references, and that'd be a bit weird 
>> (add a method call somewhere and suddenly the function becomes impure).
> 
> That seems totally fine to me.
> 
>> 
>> There's also an issue with diagnostics: say you have func1 that calls func2 
>> that calls func3. Func1 is `pure`, the other two are pure only implicitly. 
>> Then you change something in func3, and suddenly func1 complains that it 
>> can't call impure func2 and you are left wondering why because you haven't 
>> changed anything in func2. Perhaps the compiler could dig in the call tree 
>> to find the impure operation and tell you, but that's starting to look like 
>> the awful diagnostic messages for C++ templates.
>> 
>> So now I'm starting to think this idea of inferring purity was perhaps a bit 
>> reckless.
> 
> It all depends on how people use it (that’s why I mentioned strategic 
> annotations), but yeah it could be ugly.  I wonder if there is a reasonable 
> way to bound the inference to keep error messages tractable.  For example, 
> you mentioned inference within a module.  If that’s too broad a scope for 
> inference, maybe within a file would be ok and annotation would be required 
> for anything with `internal` or greater visibility.  This would still address 
> closures which would be cool and outside of crazy large files it wouldn’t be 
> too bad to track down the meaning of an error.

If a closure can be inferred pure, then it should be pure. We already infer 
`throws` and return types for closures, so inferring `pure` is natural. But for 
functions declared with a full signature, I'm hesitant to allow them to be 
inferred.

Now that I think of it, overrides could be another source of problem with 
inference: add an impure override and the method in the base class can no 
longer be inferred as pure. So it can't apply to any non-final class property 
or function.


-- 
Michel Fortin
https://michelf.ca

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

[Michel Fortin via swift-evolution]

> Le 20 févr. 2017 à 17:56, David Sweeris  a écrit :
> 
> Could we only infer purity for one “level”? As a technical limitation rather 
> than part of the language spec, to be removed at some later date when we have 
> time to implement the diagnostic logic? So in your example, the purity of 
> func2 or func3 could be inferred, but the other would have to be annotated.

This is not about the diagnostic logic. It's simply that the diagnostic 
messages will almost always be overwhelming by necessity of having enough 
information to properly debug the problem.

For instance, you add a `print("debug info: blah")` in a few places, one of 
them being `func3`, and suddenly functions all over your code base start 
screaming they can no longer compile. None of these errors occur where you made 
a change, you have to follow the "call stack" in the compiler logs to find why 
the assumption about purity doesn't hold anymore. Example:

error: func1 cannot be pure because it calls func2 which isn't pure.
note: func2 isn't pure because it calls func3 which isn't pure.
note: func3 isn't pure because it calls Swift.print which isn't pure
error: foo cannot be pure because it calls bar which isn't pure.
note: bar isn't pure because it calls baz which isn't pure.
note: baz isn't pure because it calls raa which isn't pure.
note: raa isn't pure because it calls func3 which isn't pure.
note: func3 isn't pure because it calls Swift.print which isn't pure
error: wee cannot be pure because it calls ery which isn't pure.
note: ery isn't pure because it calls tyi which isn't pure.
note: tyi isn't pure because it calls func3 which isn't pure.
note: func3 isn't pure because it calls Swift.print which isn't pure

This isn't a good user experience. I've done enough C++ template debugging to 
know how confusing this can be.

While if you write `pure` in front of every function as you edit those 
functions, this doesn't happen. Errors aren't spread all over the call tree and 
are easier to link to specific edits.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Xiaodi Wu via swift-evolution]

Agree. If technical limitations do not prohibit it, Kevin's idea seems the
more elegant.


On Mon, Feb 20, 2017 at 6:28 PM, Kevin Nattinger via swift-evolution <
swift-evolution@swift.org> wrote:

> I don’t think we need/want to add `@objcstring` or anything like that, but
> I do think we should let String enums be @objc (currently it’s int types
> only) and imported as const refs.
>
> // Already works
> @objc enum IntEnum: Int {
> case foo = 1
> case bar = 2
> }
>
> // "not an integer type"
> // Should be allowed.
> @objc enum StrEnum: String {
> case foo
> case bar = "baz"
> }
>
> Becomes
>
> // Current
> typedef NS_ENUM(NSInteger, IntEnum) {
> IntEnumFoo = 1,
> IntEnumBar = 2
> };
>
> // Proposed (static or extern, depending on implementation)
> NSString *const StrEnumFoo = @“foo";
> NSString *const StrEnumBar = @“baz";
>
> In fact, I’d go a step further and say any RawRepresentable enum as a
> globally initialized const in objc should be allowed the same treatment.
> Though the only other type that comes to mind is float/double.
>
> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift should not forsake objective-c.  At least not when it comes enum
> strings.  Although swift enums are suppose to be swift only, I think we
> should add a new attribute to slightly relax that.  I think a good
> attribute would be @objcstring.
>
> By adding @objcstring, an objective-c exclusive class will be generated.
>
> @objcstring
> enum Planet {
>   case Jupiter
> }
>
> I have written up a proposal with more details on what it would look for
> objective-c.
>
> https://github.com/wh1pch81n/swift-evolution/blob/swift-
> enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>
> If no one objects to this proposal I'll submit it.
>
> **notes: I am reviving this discussion so that I may submit this for Swift
> 4 stage 2
> ___
> 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] Strings in Swift 4

[Ben Cohen via swift-evolution]

Hi Ted,

While Character is the Element type for String, it would be unsuitable for a 
String’s implementation to actually use Character for storage. Character is 
fairly large (currently 9 bytes), very little of which is used for most values. 
For unusual graphemes that require more storage, it allocates more memory on 
the heap. By contrast, String’s actual storage is a buffer of 1- or 2-byte 
elements, and all graphemes (what we expose as Characters) are held in that 
contiguous memory no matter how many code points they comprise. When you 
iterate over the string, the graphemes are unpacked into a Character on the 
fly. This gives you an user interface of a collection that superficially 
appears to resemble [Character], but this does not mean that this would be a 
workable implementation.

> On Feb 20, 2017, at 12:59 PM, Ted F.A. van Gaalen  
> wrote:
> 
> Hi Ben, Dave (you should not read this now, you’re on vacation :o)  & Others
> 
> As described in the Swift Standard Library API Reference:
> 
> The Character type represents a character made up of one or more Unicode 
> scalar values, 
> grouped by a Unicode boundary algorithm. Generally, a Character instance 
> matches what 
> the reader of a string will perceive as a single character. The number of 
> visible characters is 
> generally the most natural way to count the length of a string.
> The smallest discrete unit we (app programmers) are mostly working with is 
> this
> perceived visible character, what else? 
> 
> If that is the case, my reasoning is, that Strings (could / should? ) be 
> relatively simple, 
> because most, if not all, complexity of Unicode is confined within the 
> Character object and
> completely hidden**  for the average application programmer, who normally 
> only needs
> to work with Strings which contains these visible Characters, right? 
> It doesn’t then make no difference at all “what’ is in” the Character, 
> (excellent implementation btw) 
> (Unicode, ASCCII, EBCDIC, Elvish, KlingonIV, IntergalacticV.2, whatever)
> because we rely in sublime oblivion for the visually representation of 
> whatever is in
> the Character on miraculous font processors hidden in the dark depths of the 
> OS. 
> 
> Then, in this perspective, my question is: why is String not implemented as 
> directly based upon an array [Character]  ? In that case one can refer to the 
> Characters of the
> String directly, not only for direct subscripting and other String 
> functionality in an efficient way. 
> (i do hava scope of independent Swift here, that is interaction with 
> libraries should be 
> solved by the compiler, so as not to be restricted by legacy ObjC etc. 
> 
> **   (expect if one needs to do e.g. access individual elements and/or 
> compose graphics directly?
>   but for  this purpose the Character’s properties are accessible) 
> 
> For the sake of convenience, based upon the above reasoning,  I now “emulate" 
> this in 
> a string extension, thereby ignoring the rare cases that a visible character 
> could be based 
> upon more than a single Character (extended grapheme cluster)  If that would 
> occur, 
> thye should be merged into one extended grapheme cluster, a single Character 
> that is. 
> 
> //: Playground - implement direct subscripting using a Character array
> // of course, when the String is defined as an array of Characters, directly
> // accessible it would be more efficient as in these extension functions. 
> extension String
> {
> var count: Int
> {
> get
> {
> return self.characters.count
> }
> }
> 
> subscript (n: Int) -> String
> {
> return String(Array(self.characters)[n])
> }
> 
> subscript (r: Range) -> String
> {
> return String(Array(self.characters)[r])
> }
> 
> subscript (r: ClosedRange) -> String
> {
> return String(Array(self.characters)[r])
> }
> }
> 
> func test()
> {
> let zoo = "Koala , Snail , Penguin , Dromedary "
> print("zoo has \(zoo.count) characters (discrete extended graphemes):")
> for i in 0.. {
> print(i,zoo[i],separator: "=", terminator:" ")
> }
> print("\n")
> print(zoo[0..<7])
> print(zoo[9..<16])
> print(zoo[18...26])
> print(zoo[29...39])
> print("images:" + zoo[6] + zoo[15] + zoo[26] + zoo[39])
> }
> 
> test()
> 
> this works as intended  and generates the following output:  
> 
> zoo has 40 characters (discrete extended graphemes):
> 0=K 1=o 2=a 3=l 4=a 5=  6= 7=, 8=  9=S 10=n 11=a 12=i 13=l 14=  15= 16=, 
> 17=  
> 18=P 19=e 20=n 21=g 22=u 23=i 24=n 25=  26= 27=, 28=  29=D 30=r 31=o 32=m 
> 33=e 34=d 35=a 36=r 37=y 38=  39= 
> 
> Koala 
> Snail 
> Penguin 
> Dromedary 
> images:
> 
> I don’t know how (in) efficient this method is. 
> but in many cases this is not so important as e.g. with numerical computation.
> 
> I still fail to understand why direct subscripting 

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

[Kevin Nattinger via swift-evolution]

I don’t think we need/want to add `@objcstring` or anything like that, but I do 
think we should let String enums be @objc (currently it’s int types only) and 
imported as const refs.

// Already works
@objc enum IntEnum: Int {
case foo = 1
case bar = 2
}

// "not an integer type"
// Should be allowed.
@objc enum StrEnum: String {
case foo
case bar = "baz"
}

Becomes

// Current
typedef NS_ENUM(NSInteger, IntEnum) {
IntEnumFoo = 1,
IntEnumBar = 2
};

// Proposed (static or extern, depending on implementation)
NSString *const StrEnumFoo = @“foo";
NSString *const StrEnumBar = @“baz";

In fact, I’d go a step further and say any RawRepresentable enum as a globally 
initialized const in objc should be allowed the same treatment. Though the only 
other type that comes to mind is float/double.

> On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> Swift should not forsake objective-c.  At least not when it comes enum 
> strings.  Although swift enums are suppose to be swift only, I think we 
> should add a new attribute to slightly relax that.  I think a good attribute 
> would be @objcstring.
> 
> By adding @objcstring, an objective-c exclusive class will be generated.
> 
> @objcstring
> enum Planet {
>   case Jupiter
> }
> 
> I have written up a proposal with more details on what it would look for 
> objective-c.
> 
> https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md
>  
> 
> 
> If no one objects to this proposal I'll submit it.
> 
> **notes: I am reviving this discussion so that I may submit this for Swift 4 
> stage 2
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

[Karl Wagner via swift-evolution]

> On 21 Feb 2017, at 01:00, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I'm terribly sorry to be _that guy_, but I have to interject that 
> `private(file)` was discussed extensively during review for SE-0025, that the 
> full scheme laid out in the first message of this thread was given 
> consideration, and that the core team took these suggestions into account 
> before accepting and implementing `fileprivate`.
> 
> Now, it has been said that real-world experience opens the door to 
> reconsidering the substantive content of SE-0025 (as in, whether "new" 
> private should exist at all). It has also long been said that a superior name 
> would be considered instead of `fileprivate` if someone came up with one. But 
> clearly, if hundreds of messages advocating for `private(file)` did not cause 
> the core team to consider it to be a superior name, it is exceedingly poor 
> form to keep bringing it up again. It's already exhausting to bikeshed 
> upcoming features, but this shed has already shipped.
> 

We are seeing lots of topics about access control in general. It’s clear people 
aren’t completely satisfied, but I don’t have a clear, coherent picture of what 
people dislike the most.

Personally, I just don’t like fileprivate, just like I didn’t like it’s ol’ 
pap, file-scoped “private”. Especially now we don’t have header files, I 
sometimes want to restrict access of a member to certain other types without 
making them exposed throughout the entire module (so the rest of my internal 
code is written in the closest thing to the client’s experience). At the same 
time, sticking everything in to one enormous file can sometimes be hard to 
manage - I end up with quarter-screens full of whitespace to act as visual 
separators.

I don’t know exactly what to suggest, but I feel we need to organise and answer 
the general grievances about access control and update the FAQ.

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

[swift-evolution] [pitch] Make swift enum string available to Objc

[Derrick Ho via swift-evolution]

Swift should not forsake objective-c.  At least not when it comes enum
strings.  Although swift enums are suppose to be swift only, I think we
should add a new attribute to slightly relax that.  I think a good
attribute would be @objcstring.

By adding @objcstring, an objective-c exclusive class will be generated.

@objcstring
enum Planet {
  case Jupiter
}

I have written up a proposal with more details on what it would look for
objective-c.

https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/proposals/-Swift-enum-strings-ported-to-Objective-c.md

If no one objects to this proposal I'll submit it.

**notes: I am reviving this discussion so that I may submit this for Swift
4 stage 2
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] fileprivate vs. private(file)

[Xiaodi Wu via swift-evolution]

I'm terribly sorry to be _that guy_, but I have to interject that
`private(file)` was discussed extensively during review for SE-0025, that
the full scheme laid out in the first message of this thread was given
consideration, and that the core team took these suggestions into account
before accepting and implementing `fileprivate`.

Now, it has been said that real-world experience opens the door to
reconsidering the substantive content of SE-0025 (as in, whether "new"
private should exist at all). It has also long been said that a superior
name would be considered instead of `fileprivate` if someone came up with
one. But clearly, if hundreds of messages advocating for `private(file)`
did not cause the core team to consider it to be a superior name, it is
exceedingly poor form to keep bringing it up again. It's already exhausting
to bikeshed upcoming features, but this shed has already shipped.


On Mon, Feb 20, 2017 at 11:14 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 20 Feb 2017, at 15:25, Ross O'Brien 
> wrote:
> Does 'private(module, type)' grant get-set access to external subclasses,
> or get-only?
>
>
> Without a specific set condition it'd be both get and set for both. So you
> might need to do for example:
>
> private(module, set:type) func someMethod() { … }
>
>
> Though this may be assuming that set always implies get; I'm not sure if
> there's a need for set-only access restrictions, as any example I can think
> of that might need it can be handled by a method specifically for that
> purpose.
>
> If I write 'private(file, type)' is the property accessible only to types
> within the module, or outside as well?
>
>
> The property would be accessible anywhere in the same file, as well as
> accessible to any sub-class both in the module and externally.
>
> Are you asking whether it'd be possible to restrict the external access of
> type? This might be an argument for allowing the type parameter on both
> private and public perhaps? So if you want external access to sub-classes
> you'd do:
>
> public(type) func someMethod() { … }
>
> Whereas for internal access you'd do:
>
> public(file, type) func someMethod() { … }
>
> Or are there still cases that aren't covered? It's possible it's a bad
> example of something that can be added to the parameterised form in future,
> and maybe it is something that does still require its own keyword?
>
> ___
> 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] Typed throws

[Anton Zhilin via swift-evolution]

2017-02-21 1:21 GMT+03:00 Matthew Johnson :
>
> Thanks for the links.  I scanned through them somewhat quickly and didn’t
> see anything that specifically said `Never` should conform to all
> protocols.  Did you see that specifically?  I only saw mentions of it being
> a bottom type and therefore a subtype of all types, which I think is a bit
> different.
>
> I think a big part of the confusion here revolves around the distinction
> between a type `T` being a subtype of another type `U` and `Type` being
> a subtype of `Type` (using the syntax in your metatype refactoring
> proposal).  I’m not an expert in this area, but I suspect that `Never` can
> be a subtype of all existential types but without requiring it to actually
> *conform* to all protocols.  Any non-instance protocol requirements are not
> available on existentials (afaik).
>

I didn't fully understand about metatypes, but otherwise yes indeed.

Yes, I understood the example and it’s a good one.  What I’m wondering is
> what benefit you actually get from this.  There are two places where this
> default initializer could be used:
>
> 1. In `seq` itself.  But it seems highly dubious to throw an error you
> know nothing about.  Why does `seq` need the ability to construct an error
> of the same type as a function given to it without knowing anything more
> about that error type.  Is there a use case for this?
> 2. In callers of `seq`.  Why would the caller care if the error type that
> `seq` can throw has a default initializer?  Is there a use case for this?
>
> In other words, why do you want to specify that the type of error that
> might be thrown must have a default initializer?  I can’t think of any
> possible circumstance where this would be valuable.
>
> The same question can be asked of any other static requirements.  What are
> the use cases?  These seem highly theoretical to me.  Maybe I’m missing
> something, but if so I would like to see an example of how it is *used*,
> not just how you would need to write an extra overload without `rethrows`.
>

Seems highly theoretical to me as well.

There is a potentially more practical benefit of keeping rethrows.  If a
> function is declared with `rethrows` we know that the function itself does
> not throw.  It only throws if one of its arguments throw when it invokes
> them.  This is a subtle but important difference.  For example, users
> calling a rethrowing function know that *they* have control over whether or
> not the call *actually* throws.  The caller might pass a couple of
> functions that *can* throw but in this particular case are known not to
> throw.  That could influence how the caller handles errors in the
> surrounding scope.
>

Agreed. Now I lean towards leaving the proposal as is.

2017-02-21 1:21 GMT+03:00 Matthew Johnson :

>
> On Feb 20, 2017, at 11:14 AM, Anton Zhilin  wrote:
>
> 2017-02-20 18:23 GMT+03:00 Matthew Johnson :
>
>
>
>> On Feb 20, 2017, at 3:58 AM, Anton Zhilin  wrote:
>>
>> But that raises another concern. In a previous discussion, it was taken
>> for granted that Never should conform to all protocols
>>
>> Do you have a pointer to this discussion?  I must have missed it.
>>
>
>
> Here
> 
> is the discussion where the idea of “empty” type originated.
> Some messages on the topic ended up being there
> .
>
> This  is the
> earliest mention of usage of this empty type for rethrows I could find.
> Some related messages are here
> 
> as well.
>
> We called this type NoReturn and meant it to be the *bottom type*, i.e.
> subtype of all types, meaning that if you have an instance of NoReturn—which
> can only happen in unreachable sections of code—then you can convert it to
> any type. It should have worked like this:
>
> func fatalError() -> Never
>
> func divide(a: Int, b: Int) -> Int {
> if b == 0 {
> let n: Never = fatalError()
> return n as Int
> }
> return a / b
> }
>
> I pushed the idea of replacing rethrows with Never, inspired by Haskell.
> Although Haskell doesn’t have static function requirements and initializer
> requirements.
>
>
> Thanks for the links.  I scanned through them somewhat quickly and didn’t
> see anything that specifically said `Never` should conform to all
> protocols.  Did you see that specifically?  I only saw mentions of it being
> a bottom type and therefore a subtype of all types, which I think is a bit
> different.
>
> I think a big part of the confusion here revolves around the distinction
> between a type `T` being a subtype of another type `U` and `Type` being
> a subtype of `Type` (using the 

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

[Xiaodi Wu via swift-evolution]

That is certainly a pragmatic solution. However, it would seem to me that
it defeats the raison d'etre for the proposal. As I understand it, the
whole idea here is that enum associated values work like argument lists,
but the syntax is subtly different. Therefore, let's make the rules the
same.

If we have to introduce new keywords to make that workable, then instead of
simplifying and streamlining the language we've just added more rules to
it. In some ways, that's taking us to a very different end result. Given
recent discussion on this list over concerns that too much syntactic sugar
is being proposed that weigh down the language, we should be wary of this.


On Mon, Feb 20, 2017 at 1:53 PM, Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 18, 2017, at 6:16 AM, David Rönnqvist via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> 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.
>
>
> I disagree. It is simple enough to use different base names if you don’t
> want the cases to match. An example of why it should not be an error: I
> intend to for errors with same base names to be handled in the same way and
> I don’t want to enumerate all the similar cases and change code every time
> I add a new way to construct an error. I understand that other people want
> the equivalent of function overloading. Code that needs to access values
> must deal with unique cases, so type safety is assured in any case.
>
> Java enums have arguments and match on “base names” (they are quite
> different, but the precedent exists) and I don’t think that matching on the
> base name would be confusing. I also do not believe that it is worth adding
> this feature if all cases are completely unique.The pain of forcing a
> (probably small) subset of developers to use unique names is preferable to
> complicating the language for no functional benefit, in my opinion.
>
>
> A possible compromise: specify that all base names should be matched with
> a new keyword (or?) Here the keyword ```all``` is used to match all base
> names.
>
> ```
> enum MyError : Error
> {
> case e( a: String )
> case e( a: Int )
> }
>
> func handleError( error: MyError )
> {
> switch error {
> case all .e :
> break
> }
> }
> ```
>
>
>
>
> - 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 <
> 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
>
>
> 

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

[Nicolas Fezans via swift-evolution]

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

Yes, I do not expect this to come very quickly either but if no one gets
started, that is going to last for even longer ;-)

> or the cleaner, with a little sugar:
>
> zip3(A,B,C).map { 3 * $0.0 * $0.1 / ($0.2 ^ 4) }

OK I guess I should have put a few regular matrix multiplications in the
middle to prevent from having such relatively straightforward solutions
(the thread was originally of element-wise but we now are clearly talking
about way more than that). Anyway, it is not worth opening a debate on the
example.

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

Well I was rather thinking of making a Swift-only library (at least at
first) but that would also be available for other platforms e.g Linux or
maybe some day on Windows => also working with reduced performance without
the Accelerator Framework but leveraging it on Apple Platforms (and
possibly leveraging others on the other platforms). This said I am open to
discussion on this... but having a very nice syntax for swift and having an
close to one-to-one equivalent also for Objective-C will probably add quite
some difficulties.

> Consider your example:
>
> 3.0 .* A .* B ./ (C.^ 4.0)
>
> with the most obvious implementation, this generates four calls to vector
functions:
>
> - multiply array by scalar (tmp0 <— 3 .* A)
> - elementwise multiplication (tmp1 <— tmp0 .* B)
> - elementwise exponentiation (tmp2 <— C .^ 4)
> - elementwise division (result <— tmp1 ./ tmp2)
>
> again, with the obvious implementation, this wastes space for temporaries
and results in extraneous passes through the data. It is often *possible*
to solve these issues (at least for some the most common cases) by
producing proxy objects that can fuse loops, but that gets very messy very
fast, and it’s ton of work to support all the interesting cases.

This is clear to me and to be honest with you I am not really sure of the
best strategy to make this.

I don't think that the primary target for the library should be to deliver
the highest performance possible.
  => People who do need that level of performance would still need to
analyze and optimize their code by themselves and/or directly call the
Acceleration Framework or other specialized libraries.

What I would like to reach instead is rather what I would call "the highest
usability possible with decent performance". Some programmers will be
satisfied with the level of performance and will enjoy the readability and
maintainability of the code based of the library, whereas other will go for
more performant libraries (and that is perfectly fine!). Actually, I would
even expect later that some of those who belong to the latter category will
start experimenting with the easy but less performant library (lets call it
here "easy maths library") and optimize their code based on a high
performance library only in a second step.

My idea of a possibly pragmatic roadmap (which can be followed in that
order) to make such a library almost from scratch with the long-term goal
of being quite performant but primarily very easy to use could be:

1) think about the integration to the language, the syntax, the high-level
user documentation, etc. and demonstrate all this based on a relatively low
performance implementation

2) generate a collection a typical operations where the low-level libraries
offer very nice performance or where a clever handling of the temporary
variables is possible

3) implement these cases as specialized functions

4) "somehow" (I am clearly not a compiler guy) teach the compiler how to
analyze a generic expression that is based the defined object to find (if
possible) some identical but more performant substitutes for the "dumb"
successive calls of each operator function causing the generation of all
these possibly unnecessary temporaries.



This roadmap and especially having point #1 at the beginning does not
really follow the citation made earlier in the discussion by Xiaodi Wu on
the _method_ proposed by the core team:
> "... And members of the core team have supported that idea. However, they
have stated that the _method_ to accomplish this is to actually implement a
math library, get people to use it, and then propose its integration."

The main advantage I see for the "easy maths" library as I would like to
propose/contribute to is the easiness of use through a well thought
integration to the swift language... I don't really see people adopting it
massively if it is neither very performant nor very easy to use and this is
the reason why I think that point #1 is a good place to start (as long as
at least an working implementation is available behind each of the
functionalities offered). Even if later on, the whole low-level
implementations 

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

[Karl Wagner via swift-evolution]

> On 19 Feb 2017, at 21:04, Anton Zhilin  wrote:
> 
> It’s expected that if you need resilience, then you will throw an “open” 
> enum. Essentially, we pass resilience of typed throws on to those who will 
> hopefully establish resilience of enums.
> 
> If you prefer separate error types, then declare a base protocol for all your 
> error types and throw a protocol existential. You won’t even need default 
> case in switches, if closed protocols make it into the language.
> 
> I don’t like any solution that is based on comments. I think that compiler 
> should always ignore comments.
> 
> 

Open enums can only add cases, not remove them. That means that new versions of 
a function will similarly only be able to add errors, and won’t be able to 
communicate that certain errors are no longer thrown. Protocols aren’t a 
solution, because you will need to write verbose conformances for all of your 
Error types.

Let me put this in another (perhaps more palatable) way. Forget comments, let’s 
say its part of some hidden metadata:

- The compiler lists every error which can be thrown by a function (it’s easily 
able to do that)
- Rather than making this part of the signature, the signature only says 
“throws an Error” and the actual Error list is written somewhere in the module 
as documentation/metadata.

Here’s why it’s so good:

- It’s completely free (you don’t write anything). The compiler generates 
everything for you.
- It’s **completely optional**: it won’t make your structure your Errors in a 
way that's less usable in a type-system sense for clients who don’t care about 
exhaustive catching.
- Exhaustive catching within your own module for free (you can omit a 
catch-all, the compiler won’t complain)

It’s good for resiliency, too:

- Non-resilient functions always reserve the right to throw new Errors in later 
versions. No system will get exhaustive catching for them anyway.
- If you stop throwing a specific Error, nothing breaks - it simply vanishes 
from the documentation/metadata. The compiler can simply warn about the 
redundant catch.
- Resilient (@versioned) functions can still offer exhaustive catching if we 
want to offer that. We might decide to make that opt-in/opt-out, because it 
would mean they would be limited to removing Errors, and never adding new ones.
—> As with any ABI promise, we will trap or it will be UB if you break the 
contract. We couldn’t validate it when compiling, but theoretically a validator 
could be built which compared two library versions.

- Karl

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

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

[Chris Lattner via swift-evolution]

> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution 
> > wrote:
> 
>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> It’s expected that if you need resilience, then you will throw an “open” 
>> enum. Essentially, we pass resilience of typed throws on to those who will 
>> hopefully establish resilience of enums.
>> 
>> If you prefer separate error types, then declare a base protocol for all 
>> your error types and throw a protocol existential. You won’t even need 
>> default case in switches, if closed protocols make it into the language.
>> 
>> I don’t like any solution that is based on comments. I think that compiler 
>> should always ignore comments.
>> 
> I agree.  And in general, this sort of thing is exactly my core concern about 
> adding typed throws to the language: I am completely certain that many 
> programmers will add typed throws annotations because they're programmers and 
> thus, well, probably a little obsessive/compulsive, and they're trying to 
> precisely document the behavior of their function without necessarily 
> thinking about the usefulness of that information for their clients and (if 
> they're writing a library; and really you should almost always be writing 
> code as if you're writing a library) whether they're actually willing to 
> commit to that behavior in their interface.  For those programmers, typed 
> throws is just going to box them in and force them into anti-patterns in the 
> long run.

As you know, I still think that adding typed throws is the right thing to do.  
I understand your concern about “the feature could be misused” but the same 
thing is true about many other language features.

One thing you didn’t mention is that boxing thrown values in an existential 
requires allocation in the general case.  This may be unacceptable for some 
classes of Swift application (in the embedded / deep systems space) or simply 
undesirable because of the performance implication.

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

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 4:50 PM, Michel Fortin  > wrote:
> 
>> Le 20 févr. 2017 à 14:45, Matthew Johnson > > a écrit :
>> 
>>> 
>>> On Feb 20, 2017, at 1:42 PM, Michel Fortin >> > wrote:
>>> 
 Le 20 févr. 2017 à 14:23, Charles Srstka > a écrit :
 
 I’m not sure how I feel about that, since it hamstrings the ability to 
 improve APIs in a lot of ways without breaking backwards compatibility. A 
 quick example off the top of my head would be all the Cocoa APIs that 
 started out having ivars representing paths backed by simple getter 
 methods, and were later refactored to be URL-based, but with the original 
 path properties become computed properties pointing to the URL’s “path” 
 property. With this, properties would not be able to be refactored in this 
 way unless the library developer had previously declared the “path” 
 property as private(set), which is unlikely for a property that was not 
 intended to be changed after the class was initialized.
>>> 
>>> Version 1:
>>> 
>>> public class A {
>>> public let path: String
>>> }
>>> 
>>> Version 2:
>>> 
>>> public class A {
>>> public pure var path: String { return url.path }
>>> public let path: URL
>>> }
>>> 
>>> This is assuming `let` is implicitly pure. It probably should not be. Or at 
>>> least it should not when crossing module boundaries. Note that internal to 
>>> the module it wouldn't violate any contract to allow pure code access to 
>>> `let` variables.
>>> 
>>> Which makes me think of an idea: internal to the module, `pure` could be 
>>> inferred for everything. Only the published APIs would require the 
>>> annotations, and only if you want `pure` to be part of the API contract. 
>>> Attaching `pure` to an internal function could still be useful for your own 
>>> reasoning though.
>> 
>> That’s a very interesting approach that could lighten the syntactic load.  
>> We could strategically annotate our code where we want purity verified, but 
>> otherwise omit the annotation for members that don’t need to be visible 
>> outside the module.  This approach works especially well for closures.  I 
>> like it a lot!
> 
> There is an important limitation to this though: a class method that mutate 
> something in the class is never going to be implicitly pure (per the rules of 
> purity for instance methods). For that the compiler would have to prove the 
> method is only called from unique references, and that'd be a bit weird (add 
> a method call somewhere and suddenly the function becomes impure).

That seems totally fine to me.

> 
> There's also an issue with diagnostics: say you have func1 that calls func2 
> that calls func3. Func1 is `pure`, the other two are pure only implicitly. 
> Then you change something in func3, and suddenly func1 complains that it 
> can't call impure func2 and you are left wondering why because you haven't 
> changed anything in func2. Perhaps the compiler could dig in the call tree to 
> find the impure operation and tell you, but that's starting to look like the 
> awful diagnostic messages for C++ templates.
> 
> So now I'm starting to think this idea of inferring purity was perhaps a bit 
> reckless.

It all depends on how people use it (that’s why I mentioned strategic 
annotations), but yeah it could be ugly.  I wonder if there is a reasonable way 
to bound the inference to keep error messages tractable.  For example, you 
mentioned inference within a module.  If that’s too broad a scope for 
inference, maybe within a file would be ok and annotation would be required for 
anything with `internal` or greater visibility.  This would still address 
closures which would be cool and outside of crazy large files it wouldn’t be 
too bad to track down the meaning of an error.

> 
> -- 
> Michel Fortin
> https://michelf.ca 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution 
>  wrote:
> 
>> Le 20 févr. 2017 à 14:45, Matthew Johnson  a écrit :
>> 
>>> 
>>> On Feb 20, 2017, at 1:42 PM, Michel Fortin  wrote:
>>> 
 Le 20 févr. 2017 à 14:23, Charles Srstka  a 
 écrit :
 
 I’m not sure how I feel about that, since it hamstrings the ability to 
 improve APIs in a lot of ways without breaking backwards compatibility. A 
 quick example off the top of my head would be all the Cocoa APIs that 
 started out having ivars representing paths backed by simple getter 
 methods, and were later refactored to be URL-based, but with the original 
 path properties become computed properties pointing to the URL’s “path” 
 property. With this, properties would not be able to be refactored in this 
 way unless the library developer had previously declared the “path” 
 property as private(set), which is unlikely for a property that was not 
 intended to be changed after the class was initialized.
>>> 
>>> Version 1:
>>> 
>>> public class A {
>>> public let path: String
>>> }
>>> 
>>> Version 2:
>>> 
>>> public class A {
>>> public pure var path: String { return url.path }
>>> public let path: URL
>>> }
>>> 
>>> This is assuming `let` is implicitly pure. It probably should not be. Or at 
>>> least it should not when crossing module boundaries. Note that internal to 
>>> the module it wouldn't violate any contract to allow pure code access to 
>>> `let` variables.
>>> 
>>> Which makes me think of an idea: internal to the module, `pure` could be 
>>> inferred for everything. Only the published APIs would require the 
>>> annotations, and only if you want `pure` to be part of the API contract. 
>>> Attaching `pure` to an internal function could still be useful for your own 
>>> reasoning though.
>> 
>> That’s a very interesting approach that could lighten the syntactic load.  
>> We could strategically annotate our code where we want purity verified, but 
>> otherwise omit the annotation for members that don’t need to be visible 
>> outside the module.  This approach works especially well for closures.  I 
>> like it a lot!
> 
> There is an important limitation to this though: a class method that mutate 
> something in the class is never going to be implicitly pure (per the rules of 
> purity for instance methods). For that the compiler would have to prove the 
> method is only called from unique references, and that'd be a bit weird (add 
> a method call somewhere and suddenly the function becomes impure).
> 
> There's also an issue with diagnostics: say you have func1 that calls func2 
> that calls func3. Func1 is `pure`, the other two are pure only implicitly. 
> Then you change something in func3, and suddenly func1 complains that it 
> can't call impure func2 and you are left wondering why because you haven't 
> changed anything in func2. Perhaps the compiler could dig in the call tree to 
> find the impure operation and tell you, but that's starting to look like the 
> awful diagnostic messages for C++ templates.

Could we only infer purity for one “level”? As a technical limitation rather 
than part of the language spec, to be removed at some later date when we have 
time to implement the diagnostic logic? So in your example, the purity of func2 
or func3 could be inferred, but the other would have to be annotated.

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

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

[Michel Fortin via swift-evolution]

> Le 20 févr. 2017 à 14:45, Matthew Johnson  a écrit :
> 
>> 
>> On Feb 20, 2017, at 1:42 PM, Michel Fortin  wrote:
>> 
>>> Le 20 févr. 2017 à 14:23, Charles Srstka  a écrit 
>>> :
>>> 
>>> I’m not sure how I feel about that, since it hamstrings the ability to 
>>> improve APIs in a lot of ways without breaking backwards compatibility. A 
>>> quick example off the top of my head would be all the Cocoa APIs that 
>>> started out having ivars representing paths backed by simple getter 
>>> methods, and were later refactored to be URL-based, but with the original 
>>> path properties become computed properties pointing to the URL’s “path” 
>>> property. With this, properties would not be able to be refactored in this 
>>> way unless the library developer had previously declared the “path” 
>>> property as private(set), which is unlikely for a property that was not 
>>> intended to be changed after the class was initialized.
>> 
>> Version 1:
>> 
>>  public class A {
>>  public let path: String
>>  }
>> 
>> Version 2:
>> 
>>  public class A {
>>  public pure var path: String { return url.path }
>>  public let path: URL
>>  }
>> 
>> This is assuming `let` is implicitly pure. It probably should not be. Or at 
>> least it should not when crossing module boundaries. Note that internal to 
>> the module it wouldn't violate any contract to allow pure code access to 
>> `let` variables.
>> 
>> Which makes me think of an idea: internal to the module, `pure` could be 
>> inferred for everything. Only the published APIs would require the 
>> annotations, and only if you want `pure` to be part of the API contract. 
>> Attaching `pure` to an internal function could still be useful for your own 
>> reasoning though.
> 
> That’s a very interesting approach that could lighten the syntactic load.  We 
> could strategically annotate our code where we want purity verified, but 
> otherwise omit the annotation for members that don’t need to be visible 
> outside the module.  This approach works especially well for closures.  I 
> like it a lot!

There is an important limitation to this though: a class method that mutate 
something in the class is never going to be implicitly pure (per the rules of 
purity for instance methods). For that the compiler would have to prove the 
method is only called from unique references, and that'd be a bit weird (add a 
method call somewhere and suddenly the function becomes impure).

There's also an issue with diagnostics: say you have func1 that calls func2 
that calls func3. Func1 is `pure`, the other two are pure only implicitly. Then 
you change something in func3, and suddenly func1 complains that it can't call 
impure func2 and you are left wondering why because you haven't changed 
anything in func2. Perhaps the compiler could dig in the call tree to find the 
impure operation and tell you, but that's starting to look like the awful 
diagnostic messages for C++ templates.

So now I'm starting to think this idea of inferring purity was perhaps a bit 
reckless.

-- 
Michel Fortin
https://michelf.ca

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

> On Feb 20, 2017, at 11:14 AM, Anton Zhilin  wrote:
> 
> 2017-02-20 18:23 GMT+03:00 Matthew Johnson  >:
> 
> 
> 
> 
>> On Feb 20, 2017, at 3:58 AM, Anton Zhilin > > wrote:
>> But that raises another concern. In a previous discussion, it was taken for 
>> granted that Never should conform to all protocols
>> 
> 
> Do you have a pointer to this discussion?  I must have missed it.
> 
> 
> Here 
> 
>  is the discussion where the idea of “empty” type originated.
> Some messages on the topic ended up being there 
> .
> 
> This  is the 
> earliest mention of usage of this empty type for rethrows I could find.
> Some related messages are here 
> 
>  as well.
> 
> 
> We called this type NoReturn and meant it to be the bottom type, i.e. subtype 
> of all types, meaning that if you have an instance of NoReturn—which can only 
> happen in unreachable sections of code—then you can convert it to any type. 
> It should have worked like this:
> 
> func fatalError() -> Never
> 
> func divide(a: Int, b: Int) -> Int {
> if b == 0 {
> let n: Never = fatalError()
> return n as Int
> }
> return a / b
> }
> I pushed the idea of replacing rethrows with Never, inspired by Haskell. 
> Although Haskell doesn’t have static function requirements and initializer 
> requirements.
> 
> 

Thanks for the links.  I scanned through them somewhat quickly and didn’t see 
anything that specifically said `Never` should conform to all protocols.  Did 
you see that specifically?  I only saw mentions of it being a bottom type and 
therefore a subtype of all types, which I think is a bit different.

I think a big part of the confusion here revolves around the distinction 
between a type `T` being a subtype of another type `U` and `Type` being a 
subtype of `Type` (using the syntax in your metatype refactoring proposal).  
I’m not an expert in this area, but I suspect that `Never` can be a subtype of 
all existential types but without requiring it to actually *conform* to all 
protocols.  Any non-instance protocol requirements are not available on 
existentials (afaik).

> 
> 
>> , because if one obtains an instance of Never (and they won’t), then 
>> everything is possible. But now we say that Never can’t conform to Default, 
>> because this would break its very invariant. Also it can’t conform to any 
>> protocol with static members or initializers.
>> 
> 
> It seems highly problematic to me to say that never conforms to any protocol 
> with non-instance requirements.
> 
> 
> Here is an example with instance requirements only:
> 
> protocol MakesPizza {
> func cook() -> Pizza
> }
> extension Never : MakesPizza {
> func cook() -> Pizza {
> // this method will never be called anyway
> burnThisComputer()
> }
> }
> 
> let maestroLaPizza = isHeAtWork ? validMaestro : (fatalError("something went 
> wrong") as MakesPizza)
> maestroLaPizza.cook()
> In this way, Never can conform to any protocol with only instance 
> requirements.
> 
Sure.

> 
> 
>> But then basically, Never trick can’t be used when we request anything more 
>> than Error from generic error type (with static members or initializers). So 
>> this approach turns out to be more limiting than rethrows.
>> 
> 
> Can you elaborate here?  If you require a function to throw an error type 
> that has non-instance requirements then you would necessarily be restricting 
> callers to provide a throwing function.  It is not possible to express such a 
> function with `rethrows`.  You can’t talk about the error type at all.  If 
> you could talk about the error type and were able to constrain it in this way 
> `rethrows` would necessarily have to exhibit the same behavior as the generic 
> version.  The behavior arises out of the constraint you are applying, not the 
> mechanism by which you forward the type.
> 
> 
> With rethrows approach:
> 
> protocol BaseError : Error {
> init()
> }
> 
> func seq(f: () throws(E1) -> (), g: () throws(E2) -> ()) 
> rethrows(BaseError)
>  where E1: BaseError, E2: BaseError { ... }
> With Never approach, we have to create two separate functions for the same 
> effect, because Never does not fit in BaseError:
> 
> func seq(f: () throws(E1) -> (), g: () throws(E2) -> ()) 
> throws(BaseError)
>  where E1: BaseError, E2: BaseError {
> // It never actually throws E1() or E2() itself, but this fact can't be 
> reflected in the signature
> }
> 
> func seq(f: () -> (), g: () -> ()) {
> // repeat the body
> }
> That’s where loss of information (which I 

Re: [swift-evolution] [Manifesto] Ownership

[John McCall via swift-evolution]

> On Feb 20, 2017, at 4:55 PM, Florent Bruneau  
> wrote:
> 
> 
>> Le 20 févr. 2017 à 18:22, John McCall  a écrit :
>> 
>>> 
>>> On Feb 20, 2017, at 3:40 AM, Florent Bruneau  
>>> wrote:
>>> 
>>> Hi John,
>>> 
>>> I've spent 3 hours reading the manifesto and its really very interesting. 
>>> Despite the completeness of the included discussion, I have a few 
>>> comments/concerns.
>>> 
>>> 
>>> The first one is about the use a Copyable protocol whose conformance must 
>>> be explicit in the module of the definition of the type. Since copyability 
>>> shouldn't be modified outside the module that define a type, using a 
>>> protocol seems a bit weird since AFAIK no other protocol has this kind of 
>>> constraints. I do understand this enables some idiomatic constructs (like 
>>> you example where Array conforms to Copyable whenever its elements are 
>>> copyable), but on the other hand this looks a bit confusing to me. I don't 
>>> have a better solution, thought.
>> 
>> On the one hand, I agree that it's not quite a normal protocol.  On the 
>> other hand... it's a capability of a type, which is the sort of thing we 
>> normally express with a protocol.  And because it's not just a single bit — 
>> because a generic type can conditionally have that capability — if we made 
>> it not a protocol, we'd just have to re-invent a new mechanism to declare 
>> that, which would effectively be exactly like the protocol mechanism.
>> 
>> I think it's much simpler to say that certain protocols are "policy" 
>> protocols which are solely up to the author of the type to decide, and that 
>> external, "retroactive" conformance is only allowed for non-policy protocols.
> 
> OK. You got me convinced this is probably the most consistent approach. Do 
> you envision any other policy protocol?

Not right away, but it's possible that eventually we might want equivalents to 
some of the other magic protocols in Rust, like Send (which IIRC promises that 
shared references are thread-safe; that's a similar sort of fundamental 
property).

>>> Secondly, in your discussion about variable independence, you talk about 
>>> logical dependence: variables that are part of the same container. However, 
>>> whenever this is some concurrency involved, there is also some kind of 
>>> physical dependence. If you have two values stored physically in memory in 
>>> the same cache line, and you may want to modify both independently and 
>>> concurrently (one thread modifies the first value, the second modifies the 
>>> other one), you have some false sharing which impacts the performance since 
>>> the actual writes get sequentialized at CPU level. Is there any plan to 
>>> take this kind of dependencies into account?
>> 
>> Well, for one, CPUs may get cleverer here over time.  So I would be 
>> uncomfortable with cementing this too much in the language.
> 
> I don't think this will dramatically improve over time. Moreover, 
> spatial/physical dependencies may not be specific to cache lines. Another 
> example would be two boolean packed into two bits. Those variables are not 
> independent because writing into one of them requires loading and writing 
> both of them (unless you exclusively use atomic operations).

Correct.  This design doesn't *completely* give up on allowing bit-packing in 
classes, but it does make it much harder.  That was considered. :)

>> The bigger issue is that we don't have a mechanism for positively declaring 
>> that two variables will be accessed from different threads.  It would be 
>> disastrous to over-interpret the *possibility* of concurrent access on 
>> different class properties as a statement of *probability* of concurrent 
>> access — because the only option there would be, what, to put each property 
>> on its own cache line?  And cache line sizes change, so this is not 
>> statically knowable.
> 
> This indeed wouldn't be statically checkable, but this could be (maybe as an 
> opt-in?) dynamically checked.

Yes, we could certainly do layout dynamically based on the actual cache-line 
size.  But I hope we can agree that putting every class property on its own 
cache line by default is not actually acceptable. :)

>> I think it's fine for us to design the implementation around the idea that 
>> it's not necessarily a good idea to access different properties concurrently 
>> — that's true semantically, not just for performance, because obviously that 
>> kind of concurrent access to a class takes a lot more care and attention to 
>> get right — and leave it up to the programmer to respond.
>> 
>> Allowing some sort of intelligent layout to prevent cache-line collisions 
>> would certainly be a secondary goal of a concurrency design, though.
> 
> OK
> 
>> 
>>> Thirdly, I'm a bit worried about the runtime impact of the dynamic 
>>> enforcement of the law of exclusivity. It seems to me that in many use 
>>> cases we will fall 

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

[Michael Ilseman via swift-evolution]

> On Feb 20, 2017, at 9:09 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 20 Feb 2017, at 12:22, Lauri Lehmijoki via swift-evolution 
>> > wrote:
>> 
>> I'm developing an application where we use RxSwift heavily. RxSwift is a 
>> stream library. Consequently, closures that we pass to its combinators often 
>> live infinitely (this is because one can use RxSwift to represent infinitely 
>> long sequences in time). 
> 
> I used RxSwift extensively and that’s not what I have experienced. I have 
> streams with lifetimes dependent on the lifetime of the DisposeBag they are 
> added to, which is itself linked to the lifetime of the current View 
> Controller or View Model. And that very closely resembles the way closures 
> work in the Cocoa APIs (UIAlertAction handlers, etc…). I don’t think RxSwift 
> is at odds.
> 
>> Closures with infinite lifespan have implications for the question "what is 
>> the best reference capture mode for closures". My experience is that in 
>> RxSwift applications, the current default (strong) is almost always 
>> suboptimal. It leads to difficult-to-detect memory leaks and introduces a 
>> "gotcha" factor to programmers who are new to Swift. I'd prefer the default 
>> to be weak capture.
>> 
>> So, I'd like to ask you two things:
>> 
>> A) By default, why the Swift closure captures values strongly?
> 
> If the default were weak, it would litter closures with ?
> If the default were unowned, your programs would crash without you 
> understanding.
> I think its a sensible default.
> 
>> B) Should we add a compiler option that, when turned on, would emit a 
>> warning if a closure strongly captures a class instance?
> 
> Perhaps we can improve the situation, but I’m not sure that is the solution. 
> Sometimes I want my references to be strongly captured and I don’t want a 
> warning to pollute by build output.
> 

In general, these should not be warnings as Swift tries to avoid effective 
language dialects through warnings. But, this would be an awesome lint rule!

>> Regards
>> Lauri
>> ___
>> 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] [Manifesto] Ownership

[Florent Bruneau via swift-evolution]

> Le 20 févr. 2017 à 18:22, John McCall  a écrit :
> 
>> 
>> On Feb 20, 2017, at 3:40 AM, Florent Bruneau  
>> wrote:
>> 
>> Hi John,
>> 
>> I've spent 3 hours reading the manifesto and its really very interesting. 
>> Despite the completeness of the included discussion, I have a few 
>> comments/concerns.
>> 
>> 
>> The first one is about the use a Copyable protocol whose conformance must be 
>> explicit in the module of the definition of the type. Since copyability 
>> shouldn't be modified outside the module that define a type, using a 
>> protocol seems a bit weird since AFAIK no other protocol has this kind of 
>> constraints. I do understand this enables some idiomatic constructs (like 
>> you example where Array conforms to Copyable whenever its elements are 
>> copyable), but on the other hand this looks a bit confusing to me. I don't 
>> have a better solution, thought.
> 
> On the one hand, I agree that it's not quite a normal protocol.  On the other 
> hand... it's a capability of a type, which is the sort of thing we normally 
> express with a protocol.  And because it's not just a single bit — because a 
> generic type can conditionally have that capability — if we made it not a 
> protocol, we'd just have to re-invent a new mechanism to declare that, which 
> would effectively be exactly like the protocol mechanism.
> 
> I think it's much simpler to say that certain protocols are "policy" 
> protocols which are solely up to the author of the type to decide, and that 
> external, "retroactive" conformance is only allowed for non-policy protocols.

OK. You got me convinced this is probably the most consistent approach. Do you 
envision any other policy protocol?

>> Secondly, in your discussion about variable independence, you talk about 
>> logical dependence: variables that are part of the same container. However, 
>> whenever this is some concurrency involved, there is also some kind of 
>> physical dependence. If you have two values stored physically in memory in 
>> the same cache line, and you may want to modify both independently and 
>> concurrently (one thread modifies the first value, the second modifies the 
>> other one), you have some false sharing which impacts the performance since 
>> the actual writes get sequentialized at CPU level. Is there any plan to take 
>> this kind of dependencies into account?
> 
> Well, for one, CPUs may get cleverer here over time.  So I would be 
> uncomfortable with cementing this too much in the language.

I don't think this will dramatically improve over time. Moreover, 
spatial/physical dependencies may not be specific to cache lines. Another 
example would be two boolean packed into two bits. Those variables are not 
independent because writing into one of them requires loading and writing both 
of them (unless you exclusively use atomic operations).

> The bigger issue is that we don't have a mechanism for positively declaring 
> that two variables will be accessed from different threads.  It would be 
> disastrous to over-interpret the *possibility* of concurrent access on 
> different class properties as a statement of *probability* of concurrent 
> access — because the only option there would be, what, to put each property 
> on its own cache line?  And cache line sizes change, so this is not 
> statically knowable.

This indeed wouldn't be statically checkable, but this could be (maybe as an 
opt-in?) dynamically checked.

> I think it's fine for us to design the implementation around the idea that 
> it's not necessarily a good idea to access different properties concurrently 
> — that's true semantically, not just for performance, because obviously that 
> kind of concurrent access to a class takes a lot more care and attention to 
> get right — and leave it up to the programmer to respond.
> 
> Allowing some sort of intelligent layout to prevent cache-line collisions 
> would certainly be a secondary goal of a concurrency design, though.

OK

> 
>> Thirdly, I'm a bit worried about the runtime impact of the dynamic 
>> enforcement of the law of exclusivity. It seems to me that in many use cases 
>> we will fall back to the dynamic enforcement because of the language is too 
>> dynamic to allow static enforcement. As discussed in the manifesto, it's not 
>> desirable (not doable) to put the full concept of ownership and lifetime in 
>> the type system. However, I cannot see how interaction between objects will 
>> work in the current approach. Let suppose I have a concurrent application 
>> that have a shared ressource that can be used by various workers. Workers 
>> can be either structures/classes or closures.
>> 
>> ```swift
>> struct Ressource {
>>/* content is unimportant here */
>> }
>> 
>> class Worker {
>>shared ressource: Ressource
>> 
>>init(ressource: shared Ressource) {
>>self.ressource = ressource
>>}
>> 
>>/* ... */
>> }
>> 
>> let ressource = 

Re: [swift-evolution] [Manifesto] Ownership

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 3:38 PM, John McCall  wrote:
> 
>> On Feb 20, 2017, at 4:26 PM, Matthew Johnson > > wrote:
>>> On Feb 19, 2017, at 11:24 PM, John McCall >> > wrote:
>>> 
 On Feb 18, 2017, at 11:08 AM, Matthew Johnson > wrote:
 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?
>>> 
>>> Yes; a generator yielding a shared reference would be used for non-mutating 
>>> iteration.
>>> 
 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?
>>> 
>>> My intuition is the use cases for this that I'm aware of are really a 
>>> mis-use of values.  You might design an API that way in C++, where 
>>> destructors are really the only language mechanism for injecting code into 
>>> a function "later", but in Swift I think you would want to use either (1) a 
>>> generalized accessor (if the protected resource could meaningfully be 
>>> described as a single value) or (2) a callback that explicitly scopes what 
>>> happens with the resource.
>>> 
>>> So e.g. if you wanted a Rust-style mutex API, you could do it like so:
>>> 
>>> moveonly struct Locked {
>>>   var unlockedMemory: T { // probably not the best name
>>> read {
>>>   mutex.acquire()
>>>   defer { mutex.release() } // There are reasons why I think this needs 
>>> to be in a defer, but we can talk about them when we get to the detailed 
>>> proposals for co-routines.  I'm still looking for a better language design.
>>>   yield actualMemory // Recall that 'read' yields a shared value, so 
>>> this doesn't implicitly copy.
>>> }
>>> nonmutating modify { // 'nonmutating' is a misnomer, but it's an 
>>> existing misnomer.  Setters are 'mutating' methods by default and normally 
>>> demand exclusive access to self, but we don't need that here because we're 
>>> dynamically enforcing exclusive access to the memory, so all we need is 
>>> shared access, and this is how we express that.
>>>   mutex.acquire()
>>>   defer { mutex.release() }
>>>   yield 
>>> }
>>>   }
>>> 
>>>   private var mutex: Mutex
>>>   private mutable var actualMemory: T // Make this variable mutable even 
>>> within nonmutating methods; whether that makes sense is the programmer's 
>>> problem.  I didn't cover this in the proposal, because it's speculative, 
>>> but it's useful for things like our nonmutating modify.  Lots of open 
>>> questions here.
>>> }
>> 
>> I like this approach.  It scopes access to the resource as necessary without 
>> requiring nesting.
>> 
>>> 
>>> Or if you wanted a more C-like mutex API, you'd do it like so:
>>> 
>>> moveonly struct Mutex {
>>>   func withLock(_ function: () throws -> T) rethrows -> T {
>>> acquire()
>>> defer { release() }
>>> return try function()
>>>   }
>>> }
>>> 
>>> But I just don't see the motivation to try to do this by making a function 
>>> return a C++-style lock guard.
>>> 
>>> Do you have a use case which clearly benefits from an exact scoping and 
>>> really needs to be an independent value?
>> 
>> To be honest, I don’t know.  The primary thing I am looking for is a way to 
>> encapsulate the scoping of a resource without requiring the introduction of 
>> a new lexical scope like is required in your second example.
> 
> Yes, I agree that the nesting isn't ideal.  In particular, it's awkward to 
> get values out of the scope.
> 
>> The first approach you show above using generalized accessors may well be 
>> able to cover our needs.  Thanks for taking time to show the example!
> 
> Okay, glad to hear it.  If you *do* find something which really benefits from 
> an RAII-style value, please let me know; I'm certainly open to the idea.

Will do.  I’ll keep this in the back of my mind and we’ll see if anything 
bubbles to the surface! :)

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

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 3:22 PM, Joe Groff  wrote:
> 
>> 
>> On Feb 20, 2017, at 1:04 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 2:38 PM, Joe Groff >> > wrote:
>>> 
 
 On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution 
> > wrote:
> 
> I'd like to discuss the possibility of treating the cases of a given enum 
> as if they are subtypes of that enum. This seems like a natural thing to 
> do because enum cases (especially when they have associated values) 
> effectively define a closed set of subtypes.
> 
> Doing so would allow for constructions such as the following:
> 
> enum Foo {
>   case a(name: String)
> }
> 
> func isA(foo: Foo) -> Bool {
>   // The old way:
>   if case .a = foo { return true }
>   return false
>   // The new way:
>   return foo is .a
> }
> 
> func printNameIfFooIsA(foo: Foo) -> Bool {
>   // The old way:
>   if case let .a(name) = foo {
> print(name)
>   }
>   // The new way (1):
>   if let a = foo as? .a {
> print(a.name )
>   }
>   // The new way (2):
>   if let name = (foo as? .a)?.name {
> print(name)
>   }
> }
> 
> Treating an enum's cases as its subtypes would make enums easier to work 
> with because handling them would be syntactically the same as handling 
> other types.
> 
> The pattern matching capabilities of enums wouldn't be affected by this 
> proposal.
> 
> Multiple other proposals have already attempted to simplify enum handling 
> (they have particularly focused on getting rid of "if case" and adding 
> the ability to treat enum case tests as expressions), but none of the 
> solutions presented in those proposals have worked out so far.
> 
> I believe that this could be the right solution to multiple enum-related 
> problems that have been brought up repeatedly.
 
 I would like to see enum cases treated as subtypes of the enum type.  This 
 is an interesting way to refer to the type of a case.  Unfortunately I 
 don’t think it will work if we accept the proposal to give cases a 
 compound name.  If we do that the name of this case becomes `a(name:)` 
 which is not a valid type name.
>>> 
>>> I think there are definitely places where having cases be a subtype of an 
>>> enum make sense, but I don't think it makes sense for *all* cases to be 
>>> subtypes. For example, with "biased" containers like Optional and Result, 
>>> it makes sense for the "right" side to be a subtype and the "wrong" side to 
>>> be explicitly constructed, IMO.  If the types of cases overlap, it would 
>>> also be *ambiguous* which case ought to be constructed when the payload is 
>>> converted to the enum type
>> 
>> Identical case types would definitely be a problem but I don’t think 
>> overlapping case types are always a problem.  I imagine this conversion 
>> working the same as any other ordinary overload resolution for ad-hoc 
>> overloads.
> 
> Conversions happen at runtime too. `0 as Any as? Either` wouldn't 
> have any way to tell what `Either` to form if both arms of the Either were 
> subtype candidates. An Either in  context can end up being bound 
> to Either at runtime and interacting with runtime casts that way.

Hmm.  This is unfortunate.

In cases where T and U overlap and form a linear hierarchy but are not 
identical couldn’t the runtime determine the most direct path and choose that?

If the compiler prohibited cases with exactly the same types like `Either` from being expressed statically how do these types end up getting formed 
dynamically?  Is there any way those operations could be failable?


> 
>> 
>>> —remember that enums are sums, not unions, and that's important for 
>>> composability and uniform behavior with generics. 
>> 
>> I’ve always thought of enums as nominal discriminated unions.  Maybe I’m 
>> using the wrong terminology.  Can you elaborate on the difference between 
>> sums and unions?  When you say union are you talking about the kind of thing 
>> some people have brought up in the past where any members in common are 
>> automatically made available on the union type?
> 
> Sums maintain structure whereas unions collapse it. As a sum, Optional 
> maintains its shape even when T = Optional. If it were a union, T u Nil u 
> Nil would collapse to T u Nil, losing the distinction between the inner and 
> outer nil and leading to problems in APIs that use the outer nil to 
> communicate 

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

[John McCall via swift-evolution]

> On Feb 20, 2017, at 3:46 PM, Karl Wagner  wrote:
>> On 20 Feb 2017, at 18:57, John McCall > > wrote:
>> 
>>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> It’s expected that if you need resilience, then you will throw an “open” 
>>> enum. Essentially, we pass resilience of typed throws on to those who will 
>>> hopefully establish resilience of enums.
>>> 
>>> If you prefer separate error types, then declare a base protocol for all 
>>> your error types and throw a protocol existential. You won’t even need 
>>> default case in switches, if closed protocols make it into the language.
>>> 
>>> I don’t like any solution that is based on comments. I think that compiler 
>>> should always ignore comments.
>>> 
>> I agree.  And in general, this sort of thing is exactly my core concern 
>> about adding typed throws to the language: I am completely certain that many 
>> programmers will add typed throws annotations because they're programmers 
>> and thus, well, probably a little obsessive/compulsive, and they're trying 
>> to precisely document the behavior of their function without necessarily 
>> thinking about the usefulness of that information for their clients and (if 
>> they're writing a library; and really you should almost always be writing 
>> code as if you're writing a library) whether they're actually willing to 
>> commit to that behavior in their interface.  For those programmers, typed 
>> throws is just going to box them in and force them into anti-patterns in the 
>> long run.
>> 
>> In the vast majority of use-cases, clients are not going to exhaustively 
>> handle all errors — they will always have some generic fall-back.  That is 
>> not pessimism, it's actually the natural result of the complicated world we 
>> live in, where code can fail for a huge host of reasons and most callers 
>> won't have meaningful special-case behavior for all of them.  (On most 
>> operating systems, opening a file or a network connection can fail because 
>> you ran out of file descriptors.  You're seriously telling me that you're 
>> going to add a special case to your error logic for that?)  Go look at the 
>> actual error types that people use in most typed-throws situations and try 
>> to tell me I'm wrong — they probably have like twenty alternatives, and 
>> solidly a quarter or more of them will just be embedding some other 
>> arbitrarily-complex or stringly-typed error value.
>> 
>> The real use case for typed throws is when you have something like a parser 
>> library that really does only fail in a fixed number of semantically 
>> distinct ways, and you both (1) actually care about enforcing that in the 
>> implementation and making sure that other errors are handled internally and 
>> (2) you really do expect clients to exhaustively switch over the error at 
>> some point.  That's important.  But I continue to think that if adding 
>> better support for that use case misleads other programmers into thinking 
>> they should use typed throws, we will have made the language worse overall.
>> 
>> John.
>> 
>> 
>> 
>>> 2017-02-18 18:27 GMT+03:00 Karl Wagner >> >:
>>> 
>>> 
>>> 
>>> 
>>> 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 

Re: [swift-evolution] Sequence/Collection Enhancements

[Ben Cohen via swift-evolution]

> On Feb 20, 2017, at 7:38 AM, Ole Begemann  wrote:
> 
>> 
>> On 17 Feb 2017, at 01:39, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Hi swift-evolution,
>> 
>> Following up on Ted’s post regarding the opening up of stage 2, I’m starting 
>> a thread to discuss additive algorithms for Sequence and Collection.
>> 
>> Here is a list of commonly requested algorithms to operate on Sequence or 
>> Collection:
>> 
>> In-place transformations:
>> transform elements in a MutableCollection using a closure i.e. in-place map
>> remove(where:) that takes a predicate i.e. in-place filter
>> remove(indices:) that takes a Sequence of Index
> Is it possible to implement this (efficiently) with 
> RangeReplaceableCollection's current feature set?

In-place, I don’t think so, because of the shuffling-down-being-O(n) problem. 

It is possible with a combo of MutableCollection and 
RangeReplaceableCollection, because MutableCollection implies constant-time 
mutation of a single element:

extension MutableCollection where Self: RangeReplaceableCollection {
mutating func remove(where predicate: (Iterator.Element) -> Bool) {
guard var i = index(where: predicate) else { return }
var j = index(after: i)
while j != endIndex {
let e = self[j]
if !predicate(e) {
// here's where you need MutableCollection...
self[i] = e
formIndex(after: )
}
formIndex(after: )
}
// and this is the part you need RRC for...
removeSubrange(i.. Since replaceSubrange(_:with:) potentially invalidates indices, you can't 
> call it repeatedly and expect that the passed-in indices are still valid.
> 
> I suppose it's possible to create a new empty collection, then iterate over 
> the existing collection's indices and append each element that doesn't match 
> one of the indices to be removed, but that sounds a bit awkward to me. Is 
> there a better solution?
> 
>> bulk operations (replace, remove, insert) on RangeReplaceableCollection for 
>> a Sequence of subranges
> This relates to my question above. Is there a better way to implement this 
> than creating an new empty collection and iterating over the existing 
> elements, replacing/skipping/inserting at the passed-in subranges?

In-place operations avoid having to allocate/free a whole new buffer, avoid 
copying the initial prefix of retained elements unnecessarily (a big deal if 
you are removing a small proportion of the whole, especially if you sometimes 
remove none), and also enable customized efficient implementations for specific 
types. Collections that didn’t implement them could just get a default that 
builds up from scratch like you describe.

If we had multi-range bulk remove, you could also implement remove(where:) 
using it, at the cost of having to do it in two passes.

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

Re: [swift-evolution] [Manifesto] Ownership

[John McCall via swift-evolution]

> On Feb 20, 2017, at 4:26 PM, Matthew Johnson  wrote:
>> On Feb 19, 2017, at 11:24 PM, John McCall > > wrote:
>> 
>>> On Feb 18, 2017, at 11:08 AM, Matthew Johnson >> > wrote:
>>> 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?
>> 
>> Yes; a generator yielding a shared reference would be used for non-mutating 
>> iteration.
>> 
>>> 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?
>> 
>> My intuition is the use cases for this that I'm aware of are really a 
>> mis-use of values.  You might design an API that way in C++, where 
>> destructors are really the only language mechanism for injecting code into a 
>> function "later", but in Swift I think you would want to use either (1) a 
>> generalized accessor (if the protected resource could meaningfully be 
>> described as a single value) or (2) a callback that explicitly scopes what 
>> happens with the resource.
>> 
>> So e.g. if you wanted a Rust-style mutex API, you could do it like so:
>> 
>> moveonly struct Locked {
>>   var unlockedMemory: T { // probably not the best name
>> read {
>>   mutex.acquire()
>>   defer { mutex.release() } // There are reasons why I think this needs 
>> to be in a defer, but we can talk about them when we get to the detailed 
>> proposals for co-routines.  I'm still looking for a better language design.
>>   yield actualMemory // Recall that 'read' yields a shared value, so 
>> this doesn't implicitly copy.
>> }
>> nonmutating modify { // 'nonmutating' is a misnomer, but it's an 
>> existing misnomer.  Setters are 'mutating' methods by default and normally 
>> demand exclusive access to self, but we don't need that here because we're 
>> dynamically enforcing exclusive access to the memory, so all we need is 
>> shared access, and this is how we express that.
>>   mutex.acquire()
>>   defer { mutex.release() }
>>   yield 
>> }
>>   }
>> 
>>   private var mutex: Mutex
>>   private mutable var actualMemory: T // Make this variable mutable even 
>> within nonmutating methods; whether that makes sense is the programmer's 
>> problem.  I didn't cover this in the proposal, because it's speculative, but 
>> it's useful for things like our nonmutating modify.  Lots of open questions 
>> here.
>> }
> 
> I like this approach.  It scopes access to the resource as necessary without 
> requiring nesting.
> 
>> 
>> Or if you wanted a more C-like mutex API, you'd do it like so:
>> 
>> moveonly struct Mutex {
>>   func withLock(_ function: () throws -> T) rethrows -> T {
>> acquire()
>> defer { release() }
>> return try function()
>>   }
>> }
>> 
>> But I just don't see the motivation to try to do this by making a function 
>> return a C++-style lock guard.
>> 
>> Do you have a use case which clearly benefits from an exact scoping and 
>> really needs to be an independent value?
> 
> To be honest, I don’t know.  The primary thing I am looking for is a way to 
> encapsulate the scoping of a resource without requiring the introduction of a 
> new lexical scope like is required in your second example.

Yes, I agree that the nesting isn't ideal.  In particular, it's awkward to get 
values out of the scope.

> The first approach you show above using generalized accessors may well be 
> able to cover our needs.  Thanks for taking time to show the example!

Okay, glad to hear it.  If you *do* find something which really benefits from 
an RAII-style value, please let me know; I'm certainly open to the idea.

John.

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

Re: [swift-evolution] [Manifesto] Ownership

[Matthew Johnson via swift-evolution]

> On Feb 19, 2017, at 11:24 PM, John McCall  wrote:
> 
>> On Feb 18, 2017, at 11:08 AM, Matthew Johnson > > wrote:
>> 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?
> 
> Yes; a generator yielding a shared reference would be used for non-mutating 
> iteration.
> 
>> 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?
> 
> My intuition is the use cases for this that I'm aware of are really a mis-use 
> of values.  You might design an API that way in C++, where destructors are 
> really the only language mechanism for injecting code into a function 
> "later", but in Swift I think you would want to use either (1) a generalized 
> accessor (if the protected resource could meaningfully be described as a 
> single value) or (2) a callback that explicitly scopes what happens with the 
> resource.
> 
> So e.g. if you wanted a Rust-style mutex API, you could do it like so:
> 
> moveonly struct Locked {
>   var unlockedMemory: T { // probably not the best name
> read {
>   mutex.acquire()
>   defer { mutex.release() } // There are reasons why I think this needs 
> to be in a defer, but we can talk about them when we get to the detailed 
> proposals for co-routines.  I'm still looking for a better language design.
>   yield actualMemory // Recall that 'read' yields a shared value, so this 
> doesn't implicitly copy.
> }
> nonmutating modify { // 'nonmutating' is a misnomer, but it's an existing 
> misnomer.  Setters are 'mutating' methods by default and normally demand 
> exclusive access to self, but we don't need that here because we're 
> dynamically enforcing exclusive access to the memory, so all we need is 
> shared access, and this is how we express that.
>   mutex.acquire()
>   defer { mutex.release() }
>   yield 
> }
>   }
> 
>   private var mutex: Mutex
>   private mutable var actualMemory: T // Make this variable mutable even 
> within nonmutating methods; whether that makes sense is the programmer's 
> problem.  I didn't cover this in the proposal, because it's speculative, but 
> it's useful for things like our nonmutating modify.  Lots of open questions 
> here.
> }

I like this approach.  It scopes access to the resource as necessary without 
requiring nesting.

> 
> Or if you wanted a more C-like mutex API, you'd do it like so:
> 
> moveonly struct Mutex {
>   func withLock(_ function: () throws -> T) rethrows -> T {
> acquire()
> defer { release() }
> return try function()
>   }
> }
> 
> But I just don't see the motivation to try to do this by making a function 
> return a C++-style lock guard.
> 
> Do you have a use case which clearly benefits from an exact scoping and 
> really needs to be an independent value?

To be honest, I don’t know.  The primary thing I am looking for is a way to 
encapsulate the scoping of a resource without requiring the introduction of a 
new lexical scope like is required in your second example.

The first approach you show above using generalized accessors may well be able 
to cover our needs.  Thanks for taking time to show the example!

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

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

[Joe Groff via swift-evolution]

> On Feb 20, 2017, at 1:04 PM, Matthew Johnson  wrote:
> 
>> 
>> On Feb 20, 2017, at 2:38 PM, Joe Groff > > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 
 On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution 
 > wrote:
 
 I'd like to discuss the possibility of treating the cases of a given enum 
 as if they are subtypes of that enum. This seems like a natural thing to 
 do because enum cases (especially when they have associated values) 
 effectively define a closed set of subtypes.
 
 Doing so would allow for constructions such as the following:
 
 enum Foo {
   case a(name: String)
 }
 
 func isA(foo: Foo) -> Bool {
   // The old way:
   if case .a = foo { return true }
   return false
   // The new way:
   return foo is .a
 }
 
 func printNameIfFooIsA(foo: Foo) -> Bool {
   // The old way:
   if case let .a(name) = foo {
 print(name)
   }
   // The new way (1):
   if let a = foo as? .a {
 print(a.name )
   }
   // The new way (2):
   if let name = (foo as? .a)?.name {
 print(name)
   }
 }
 
 Treating an enum's cases as its subtypes would make enums easier to work 
 with because handling them would be syntactically the same as handling 
 other types.
 
 The pattern matching capabilities of enums wouldn't be affected by this 
 proposal.
 
 Multiple other proposals have already attempted to simplify enum handling 
 (they have particularly focused on getting rid of "if case" and adding the 
 ability to treat enum case tests as expressions), but none of the 
 solutions presented in those proposals have worked out so far.
 
 I believe that this could be the right solution to multiple enum-related 
 problems that have been brought up repeatedly.
>>> 
>>> I would like to see enum cases treated as subtypes of the enum type.  This 
>>> is an interesting way to refer to the type of a case.  Unfortunately I 
>>> don’t think it will work if we accept the proposal to give cases a compound 
>>> name.  If we do that the name of this case becomes `a(name:)` which is not 
>>> a valid type name.
>> 
>> I think there are definitely places where having cases be a subtype of an 
>> enum make sense, but I don't think it makes sense for *all* cases to be 
>> subtypes. For example, with "biased" containers like Optional and Result, it 
>> makes sense for the "right" side to be a subtype and the "wrong" side to be 
>> explicitly constructed, IMO.  If the types of cases overlap, it would also 
>> be *ambiguous* which case ought to be constructed when the payload is 
>> converted to the enum type
> 
> Identical case types would definitely be a problem but I don’t think 
> overlapping case types are always a problem.  I imagine this conversion 
> working the same as any other ordinary overload resolution for ad-hoc 
> overloads.

Conversions happen at runtime too. `0 as Any as? Either` wouldn't 
have any way to tell what `Either` to form if both arms of the Either were 
subtype candidates. An Either in  context can end up being bound to 
Either at runtime and interacting with runtime casts that way.

> 
>> —remember that enums are sums, not unions, and that's important for 
>> composability and uniform behavior with generics. 
> 
> I’ve always thought of enums as nominal discriminated unions.  Maybe I’m 
> using the wrong terminology.  Can you elaborate on the difference between 
> sums and unions?  When you say union are you talking about the kind of thing 
> some people have brought up in the past where any members in common are 
> automatically made available on the union type?

Sums maintain structure whereas unions collapse it. As a sum, Optional 
maintains its shape even when T = Optional. If it were a union, T u Nil u 
Nil would collapse to T u Nil, losing the distinction between the inner and 
outer nil and leading to problems in APIs that use the outer nil to communicate 
meaning about some outer structure, such as asking for the `first` element of a 
collection of Optionals.

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Ben, Dave (you should not read this now, you’re on vacation :o)  & Others

As described in the Swift Standard Library API Reference:

The Character type represents a character made up of one or more Unicode scalar 
values, 
grouped by a Unicode boundary algorithm. Generally, a Character instance 
matches what 
the reader of a string will perceive as a single character. The number of 
visible characters is 
generally the most natural way to count the length of a string.
The smallest discrete unit we (app programmers) are mostly working with is this
perceived visible character, what else? 

If that is the case, my reasoning is, that Strings (could / should? ) be 
relatively simple, 
because most, if not all, complexity of Unicode is confined within the 
Character object and
completely hidden**  for the average application programmer, who normally only 
needs
to work with Strings which contains these visible Characters, right? 
It doesn’t then make no difference at all “what’ is in” the Character, 
(excellent implementation btw) 
(Unicode, ASCCII, EBCDIC, Elvish, KlingonIV, IntergalacticV.2, whatever)
because we rely in sublime oblivion for the visually representation of whatever 
is in
the Character on miraculous font processors hidden in the dark depths of the 
OS. 

Then, in this perspective, my question is: why is String not implemented as 
directly based upon an array [Character]  ? In that case one can refer to the 
Characters of the
String directly, not only for direct subscripting and other String 
functionality in an efficient way. 
(i do hava scope of independent Swift here, that is interaction with libraries 
should be 
solved by the compiler, so as not to be restricted by legacy ObjC etc. 

**   (expect if one needs to do e.g. access individual elements and/or compose 
graphics directly?
  but for  this purpose the Character’s properties are accessible) 

For the sake of convenience, based upon the above reasoning,  I now “emulate" 
this in 
a string extension, thereby ignoring the rare cases that a visible character 
could be based 
upon more than a single Character (extended grapheme cluster)  If that would 
occur, 
thye should be merged into one extended grapheme cluster, a single Character 
that is. 

//: Playground - implement direct subscripting using a Character array
// of course, when the String is defined as an array of Characters, directly
// accessible it would be more efficient as in these extension functions. 
extension String
{
var count: Int
{
get
{
return self.characters.count
}
}

subscript (n: Int) -> String
{
return String(Array(self.characters)[n])
}

subscript (r: Range) -> String
{
return String(Array(self.characters)[r])
}

subscript (r: ClosedRange) -> String
{
return String(Array(self.characters)[r])
}
}

func test()
{
let zoo = "Koala , Snail , Penguin , Dromedary "
print("zoo has \(zoo.count) characters (discrete extended graphemes):")
for i in 0..___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> It’s expected that if you need resilience, then you will throw an “open” 
>> enum. Essentially, we pass resilience of typed throws on to those who will 
>> hopefully establish resilience of enums.
>> 
>> If you prefer separate error types, then declare a base protocol for all 
>> your error types and throw a protocol existential. You won’t even need 
>> default case in switches, if closed protocols make it into the language.
>> 
>> I don’t like any solution that is based on comments. I think that compiler 
>> should always ignore comments.
>> 
> I agree.  And in general, this sort of thing is exactly my core concern about 
> adding typed throws to the language: I am completely certain that many 
> programmers will add typed throws annotations because they're programmers and 
> thus, well, probably a little obsessive/compulsive, and they're trying to 
> precisely document the behavior of their function without necessarily 
> thinking about the usefulness of that information for their clients and (if 
> they're writing a library; and really you should almost always be writing 
> code as if you're writing a library) whether they're actually willing to 
> commit to that behavior in their interface.  For those programmers, typed 
> throws is just going to box them in and force them into anti-patterns in the 
> long run.
> 
> In the vast majority of use-cases, clients are not going to exhaustively 
> handle all errors — they will always have some generic fall-back.  That is 
> not pessimism, it's actually the natural result of the complicated world we 
> live in, where code can fail for a huge host of reasons and most callers 
> won't have meaningful special-case behavior for all of them.  (On most 
> operating systems, opening a file or a network connection can fail because 
> you ran out of file descriptors.  You're seriously telling me that you're 
> going to add a special case to your error logic for that?)  Go look at the 
> actual error types that people use in most typed-throws situations and try to 
> tell me I'm wrong — they probably have like twenty alternatives, and solidly 
> a quarter or more of them will just be embedding some other 
> arbitrarily-complex or stringly-typed error value.

I agree that overly specific API specs are a concern. There's still some 
documentational benefit to a typed error enum, even if it ultimately ends up 
containing a catch-all case, since it gives you the ability to also enumerate 
some number of discrete, realistically handleable cases. Sure, your network 
request running in an XPC service has infinitely many failure cases due to 
resource constraints or IPC failure or network chaos, but there's usually some 
number of domain-specific error cases  too. And if we compare the proposed "you 
get to specify one error enum type" model to, say, Java or C++98's "you get to 
specify any number of error classes" model, I think that helps steer people 
away from the most grievous API mistakes in Java land, since instead of listing 
a closed set of concrete error classes directly in your API signature, you'll 
list those error cases in your enum definition, and in a resilient world, the 
enum will be "open" by default to external users, preventing it from being a 
permanent liability unless the user explicitly opted into closedness.

In the discussions around Rust's error handling conventions, they recognized 
this pattern of APIs either raising some number of layer-appropriate errors or 
carrying forward the failure modes of the layers below them, and they developed 
a convention for errors wrapping other errors. It would be reasonable to say we 
should do the same thing as part of the typed errors design. If we were to 
generalize enum subtyping beyond Optional, that might be one way to go about 
it, letting an enum wrap its underlying layers' failure cases as subtypes.

-Joe

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

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 2:38 PM, Joe Groff  wrote:
> 
>> 
>> On Feb 20, 2017, at 7:32 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 12:40 AM, Niels Andriesse via swift-evolution 
>>> > wrote:
>>> 
>>> I'd like to discuss the possibility of treating the cases of a given enum 
>>> as if they are subtypes of that enum. This seems like a natural thing to do 
>>> because enum cases (especially when they have associated values) 
>>> effectively define a closed set of subtypes.
>>> 
>>> Doing so would allow for constructions such as the following:
>>> 
>>> enum Foo {
>>>   case a(name: String)
>>> }
>>> 
>>> func isA(foo: Foo) -> Bool {
>>>   // The old way:
>>>   if case .a = foo { return true }
>>>   return false
>>>   // The new way:
>>>   return foo is .a
>>> }
>>> 
>>> func printNameIfFooIsA(foo: Foo) -> Bool {
>>>   // The old way:
>>>   if case let .a(name) = foo {
>>> print(name)
>>>   }
>>>   // The new way (1):
>>>   if let a = foo as? .a {
>>> print(a.name )
>>>   }
>>>   // The new way (2):
>>>   if let name = (foo as? .a)?.name {
>>> print(name)
>>>   }
>>> }
>>> 
>>> Treating an enum's cases as its subtypes would make enums easier to work 
>>> with because handling them would be syntactically the same as handling 
>>> other types.
>>> 
>>> The pattern matching capabilities of enums wouldn't be affected by this 
>>> proposal.
>>> 
>>> Multiple other proposals have already attempted to simplify enum handling 
>>> (they have particularly focused on getting rid of "if case" and adding the 
>>> ability to treat enum case tests as expressions), but none of the solutions 
>>> presented in those proposals have worked out so far.
>>> 
>>> I believe that this could be the right solution to multiple enum-related 
>>> problems that have been brought up repeatedly.
>> 
>> I would like to see enum cases treated as subtypes of the enum type.  This 
>> is an interesting way to refer to the type of a case.  Unfortunately I don’t 
>> think it will work if we accept the proposal to give cases a compound name.  
>> If we do that the name of this case becomes `a(name:)` which is not a valid 
>> type name.
> 
> I think there are definitely places where having cases be a subtype of an 
> enum make sense, but I don't think it makes sense for *all* cases to be 
> subtypes. For example, with "biased" containers like Optional and Result, it 
> makes sense for the "right" side to be a subtype and the "wrong" side to be 
> explicitly constructed, IMO.  If the types of cases overlap, it would also be 
> *ambiguous* which case ought to be constructed when the payload is converted 
> to the enum type

Identical case types would definitely be a problem but I don’t think 
overlapping case types are always a problem.  I imagine this conversion working 
the same as any other ordinary overload resolution for ad-hoc overloads.

For example let’s assume the numeric types have the desired subtype 
relationships and I have the following enum for which the cases are subtypes of 
the enum itself and are given the types of the associated value payloads.  This 
example uses the syntax I used in my value subtyping manifesto for anonymous 
cases that are subtypes of the enum:

enum FixedInt {
   case -> Int8
   case -> Int16
   case -> Int32
   case -> Int64
}

let fixedInt = Int8(42)   // resolves to `FixedInt.int8(42)`

Now imagine `FixedInt` does not include the `Int8` case:

let fixedInt = Int8(42)   // resolves to `FixedInt.int16(42)`

I don’t see how this is different than:

func foo(_ int8: Int8) {}
func foo(_ int16: Int16) {}
func foo(_ int16: Int16) {}
func foo(_ int16: Int16) {}

foo(Int16(42))

As long as value subtyping follows the same overload resolution rules that are 
used for classes and protocol existentials the right thing happens.

If there is no case with the exact type is getting converted the nearest 
ancestor type is preferred.  In the case of a non-linear type hierarchy (as we 
already have in protocols) if the overloads available to choose from do not 
form a strictly linear order *then* we do have ambiguity.  In that case it 
would need to be resolve manually by explicitly specifying which case is 
intended.

This doesn’t seem like a problem to me - just ordinary overload resolution.


> —remember that enums are sums, not unions, and that's important for 
> composability and uniform behavior with generics.

I’ve always thought of enums as nominal discriminated unions.  Maybe I’m using 
the wrong terminology.  Can you elaborate on the difference between sums and 
unions?  When you say union are you talking about the kind of thing some people 
have brought up in the past where any members in common are automatically made 
available on the union type?

> I would be fine allowing enum subtyping with some opt-in 

Re: [swift-evolution] Compile-time generic specialization

[David Sweeris via swift-evolution]

> On Feb 20, 2017, at 12:23, Abe Schneider via swift-evolution 
>  wrote:
> 
> However, if I define an operation to on the Tensor:
> 
> class SomeOp {
> typealias StorageType = S
> var output:Tensor
> 
> init() {
> output = Tensor(size: 10)
> }
> 
> func apply() -> Tensor {
> let result = T.cos(output)
> return result
> }
> }
> 
> let op1 = SomeOp()
> let result3 = op1.apply() // calls default `cos` instead of FloatStorage 
> version
> 
> 
> 
> So one question I have is why doesn’t the correct version of `cos` get 
> called? Before it was because there wasn’t a vtable available to figure out 
> which function to call. However, in this case since the function was defined 
> in the class, I would assume there would be (I also tried variants of this 
> with an accompanying protocol and non-static versions of the function).
> 
> 
> I can get `SomeOp` to work correctly if I create specializations of the class:
> 
> extension SomeOp where S:FloatStorage {
> func apply() -> Tensor {
> let result = T.cos(output)
> return result
> }
> }
> 
> extension SomeOp where S:IntStorage {
> func apply() -> Tensor {
> let result = T.cos(output)
> return result
> }
> }
> 
> 
> However, this doesn’t seem like a good design to me, as it requires copying 
> the same code for each StorageType introduced.

Where is T defined? What happens if you replace "T" with "Tensor"?

- Dave Sweeris ___
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 20 Feb 2017, at 18:57, John McCall  wrote:
> 
>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> It’s expected that if you need resilience, then you will throw an “open” 
>> enum. Essentially, we pass resilience of typed throws on to those who will 
>> hopefully establish resilience of enums.
>> 
>> If you prefer separate error types, then declare a base protocol for all 
>> your error types and throw a protocol existential. You won’t even need 
>> default case in switches, if closed protocols make it into the language.
>> 
>> I don’t like any solution that is based on comments. I think that compiler 
>> should always ignore comments.
>> 
> I agree.  And in general, this sort of thing is exactly my core concern about 
> adding typed throws to the language: I am completely certain that many 
> programmers will add typed throws annotations because they're programmers and 
> thus, well, probably a little obsessive/compulsive, and they're trying to 
> precisely document the behavior of their function without necessarily 
> thinking about the usefulness of that information for their clients and (if 
> they're writing a library; and really you should almost always be writing 
> code as if you're writing a library) whether they're actually willing to 
> commit to that behavior in their interface.  For those programmers, typed 
> throws is just going to box them in and force them into anti-patterns in the 
> long run.
> 
> In the vast majority of use-cases, clients are not going to exhaustively 
> handle all errors — they will always have some generic fall-back.  That is 
> not pessimism, it's actually the natural result of the complicated world we 
> live in, where code can fail for a huge host of reasons and most callers 
> won't have meaningful special-case behavior for all of them.  (On most 
> operating systems, opening a file or a network connection can fail because 
> you ran out of file descriptors.  You're seriously telling me that you're 
> going to add a special case to your error logic for that?)  Go look at the 
> actual error types that people use in most typed-throws situations and try to 
> tell me I'm wrong — they probably have like twenty alternatives, and solidly 
> a quarter or more of them will just be embedding some other 
> arbitrarily-complex or stringly-typed error value.
> 
> The real use case for typed throws is when you have something like a parser 
> library that really does only fail in a fixed number of semantically distinct 
> ways, and you both (1) actually care about enforcing that in the 
> implementation and making sure that other errors are handled internally and 
> (2) you really do expect clients to exhaustively switch over the error at 
> some point.  That's important.  But I continue to think that if adding better 
> support for that use case misleads other programmers into thinking they 
> should use typed throws, we will have made the language worse overall.
> 
> John.
> 
> 
> 
>> 2017-02-18 18:27 GMT+03:00 Karl Wagner > >:
>> 
>> 
>> 
>> 
>> 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 

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

[Joe Groff via swift-evolution]

> On Feb 20, 2017, at 12:07 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Obviously, this won't become an accepted proposal -  neither the time nor the 
> author would be appropriate for such a result.
> But the list seems a little bit bored lately, so maybe a relaxed discussion 
> without practical implications isn't the worst thing to have now ;-)
> 
> Several current threads seem to cry for sum types, so imho it is a valid 
> question what's wrong with them, and why Swift prefers enums instead.

Enums in Swift *are* sum types. There are various ergonomic issues with their 
usability, perhaps, but any implementation of sum types would be different 
sugar over the same underlying semantic model.

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

Re: [swift-evolution] [Fake-Proposal] Remove enums with associated objects

[Robert Widmann via swift-evolution]

A lot of problems look algebra-like.  Best to have sums and products at your 
disposal.

 Cheekily,

~Robert Widmann

2017/02/20 15:07、Tino Heth via swift-evolution  
のメッセージ:

> Obviously, this won't become an accepted proposal -  neither the time nor the 
> author would be appropriate for such a result.
> But the list seems a little bit bored lately, so maybe a relaxed discussion 
> without practical implications isn't the worst thing to have now ;-)
> 
> Several current threads seem to cry for sum types, so imho it is a valid 
> question what's wrong with them, and why Swift prefers enums instead.
> 
> I'm sure such a debate already happened, but I haven't seen its arguments... 
> and the ones that come to my mind don't fit to reality:
> Enums might be more powerful, but imho Optional feels more like 
> a burden.
> Sum types, on the other hand, can be composed on the fly and could save us 
> from several, incompatible implementations of trivial things like Result or 
> JSONValue.
> 
> So, what is the big advantage of enums?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Compile-time generic specialization

[Abe Schneider via swift-evolution]

Sorry, just following up with a few more thoughts.

> 
> I consider Java’s type erasure to be orthogonal to the 
> overloading/customization point issue, but of course I agree that it’s 
> surprising. 

While the underlying reason may be different, Swift has a similar potential for 
surprise with generics. Yes, it might not be a surprise for people coming from 
the world of Java, but mostly because Java’s generics are extremely limited.


> 
>> I can see the advantage of protocols if they allowed this type of design:
>> 
>> protocol LinearOperations {
>>  associatedtype StorageType
>>  static func dot(_ lhs:Tensor, _
>> rhs:Tensor) -> Tensor
>>  ...
>> }
>> 
>> extension Tensor: LinearOperations {
>> ...
>> }
>> 
>> extension Tensor: LinearOperations where StorageType:CBlasStorage {
>> ...
>> }
>> 
>> The advantage of this design is that the available functions are
>> clearly defined, but it still allows new operations to be defined
>> without having to touch the main code base. 
> 
> I’m assuming that both of these extensions implement the static func 
> dot(_:_:). This is more interesting direction for me, because it’s taking the 
> existing notion of customization points via protocol requirements and 
> extending that to also support some level of customization.


So what needs to change in the language to enable this behavior? The obvious 
candidate is allowing creating extensions with constraints. However, even if I 
include all the necessary functions within a single class (to avoid that 
issue), I’m still running into more design issues. For example, for this toy 
example (sorry for the verbosity — this was the shortest version I could come 
up with):

class Tensor {
var storage:S

init(size:Int) {
storage = S(size: size)
}

// default implementation
static func cos(_ tensor:Tensor) -> Tensor {
// ...
}
}




With specializations defined for the storage types:

extension Tensor where S:IntStorage {
static func cos(_ tensor:Tensor) -> Tensor {
// ...
}
}

extension Tensor where S:FloatStorage {
static func cos(_ tensor:Tensor) -> Tensor {
// ...
}
}




This works:

let floatTensor = Tensor(size: 10)
let result1 = T.cos(floatTensor) // calls Tensor.cos(…)

let intTensor = Tensor(size: 10)
let result2 = T.cos(intTensor) // calls Tensor.cos(…)





However, if I define an operation to on the Tensor:

class SomeOp {
typealias StorageType = S
var output:Tensor

init() {
output = Tensor(size: 10)
}

func apply() -> Tensor {
let result = T.cos(output)
return result
}
}

let op1 = SomeOp()
let result3 = op1.apply() // calls default `cos` instead of FloatStorage version



So one question I have is why doesn’t the correct version of `cos` get called? 
Before it was because there wasn’t a vtable available to figure out which 
function to call. However, in this case since the function was defined in the 
class, I would assume there would be (I also tried variants of this with an 
accompanying protocol and non-static versions of the function).


I can get `SomeOp` to work correctly if I create specializations of the class:

extension SomeOp where S:FloatStorage {
func apply() -> Tensor {
let result = T.cos(output)
return result
}
}

extension SomeOp where S:IntStorage {
func apply() -> Tensor {
let result = T.cos(output)
return result
}
}


However, this doesn’t seem like a good design to me, as it requires copying the 
same code for each StorageType introduced.


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

[swift-evolution] [Fake-Proposal] Remove enums with associated objects

[Tino Heth via swift-evolution]

Obviously, this won't become an accepted proposal -  neither the time nor the 
author would be appropriate for such a result.
But the list seems a little bit bored lately, so maybe a relaxed discussion 
without practical implications isn't the worst thing to have now ;-)

Several current threads seem to cry for sum types, so imho it is a valid 
question what's wrong with them, and why Swift prefers enums instead.

I'm sure such a debate already happened, but I haven't seen its arguments... 
and the ones that come to my mind don't fit to reality:
Enums might be more powerful, but imho Optional feels more like a 
burden.
Sum types, on the other hand, can be composed on the fly and could save us from 
several, incompatible implementations of trivial things like Result or 
JSONValue.

So, what is the big advantage of enums?
___
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

[Christopher Kornher via swift-evolution]

> On Feb 20, 2017, at 12:31 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 18, 2017, at 6:16 AM, 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. 
> 
> I disagree. It is simple enough to use different base names if you don’t want 
> the cases to match. An example of why it should not be an error: I intend to 
> for errors with same base names to be handled in the same way and I don’t 
> want to enumerate all the similar cases and change code every time I add a 
> new way to construct an error. I understand that other people want the 
> equivalent of function overloading. Code that needs to access values must 
> deal with unique cases, so type safety is assured in any case.
> 
> Java enums have arguments and match on “base names” (they are quite 
> different, but the precedent exists) and I don’t think that matching on the 
> base name would be confusing. I also do not believe that it is worth adding 
> this feature if all cases are completely unique.The pain of forcing a 
> (probably small) subset of developers to use unique names is preferable to 
> complicating the language for no functional benefit, in my opinion.

A possible compromise: specify that all base names should be matched with a new 
keyword (or?) Here the keyword ```all``` is used to match all base names.

```
enum MyError : Error
{
case e( a: String )
case e( a: Int )
}

func handleError( error: MyError )
{
switch error {
case all .e :
break
}
}
```

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

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

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 1:42 PM, Michel Fortin  wrote:
> 
>> Le 20 févr. 2017 à 14:23, Charles Srstka  a écrit :
>> 
>> I’m not sure how I feel about that, since it hamstrings the ability to 
>> improve APIs in a lot of ways without breaking backwards compatibility. A 
>> quick example off the top of my head would be all the Cocoa APIs that 
>> started out having ivars representing paths backed by simple getter methods, 
>> and were later refactored to be URL-based, but with the original path 
>> properties become computed properties pointing to the URL’s “path” property. 
>> With this, properties would not be able to be refactored in this way unless 
>> the library developer had previously declared the “path” property as 
>> private(set), which is unlikely for a property that was not intended to be 
>> changed after the class was initialized.
> 
> Version 1:
> 
>   public class A {
>   public let path: String
>   }
> 
> Version 2:
> 
>   public class A {
>   public pure var path: String { return url.path }
>   public let path: URL
>   }
> 
> This is assuming `let` is implicitly pure. It probably should not be. Or at 
> least it should not when crossing module boundaries. Note that internal to 
> the module it wouldn't violate any contract to allow pure code access to 
> `let` variables.
> 
> Which makes me think of an idea: internal to the module, `pure` could be 
> inferred for everything. Only the published APIs would require the 
> annotations, and only if you want `pure` to be part of the API contract. 
> Attaching `pure` to an internal function could still be useful for your own 
> reasoning though.

That’s a very interesting approach that could lighten the syntactic load.  We 
could strategically annotate our code where we want purity verified, but 
otherwise omit the annotation for members that don’t need to be visible outside 
the module.  This approach works especially well for closures.  I like it a lot!

> 
> -- 
> Michel Fortin
> https://michelf.ca
> 

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

[Michel Fortin via swift-evolution]

> Le 20 févr. 2017 à 14:23, Charles Srstka  a écrit :
> 
> I’m not sure how I feel about that, since it hamstrings the ability to 
> improve APIs in a lot of ways without breaking backwards compatibility. A 
> quick example off the top of my head would be all the Cocoa APIs that started 
> out having ivars representing paths backed by simple getter methods, and were 
> later refactored to be URL-based, but with the original path properties 
> become computed properties pointing to the URL’s “path” property. With this, 
> properties would not be able to be refactored in this way unless the library 
> developer had previously declared the “path” property as private(set), which 
> is unlikely for a property that was not intended to be changed after the 
> class was initialized.

Version 1:

public class A {
public let path: String
}

Version 2:

public class A {
public pure var path: String { return url.path }
public let path: URL
}

This is assuming `let` is implicitly pure. It probably should not be. Or at 
least it should not when crossing module boundaries. Note that internal to the 
module it wouldn't violate any contract to allow pure code access to `let` 
variables.

Which makes me think of an idea: internal to the module, `pure` could be 
inferred for everything. Only the published APIs would require the annotations, 
and only if you want `pure` to be part of the API contract. Attaching `pure` to 
an internal function could still be useful for your own reasoning though.

-- 
Michel Fortin
https://michelf.ca

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

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

[David Sweeris via swift-evolution]

> On Feb 20, 2017, at 11:23 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> What if the “let” property becomes a “var” property in a future version of 
>>> the library you’re linking against?
>> 
>> That would be a breaking change if the `let` was public or if any `pure` 
>> public methods were accessing it (unless they were refactored to not rely on 
>> it anymore).
> 
> I’m not sure how I feel about that, since it hamstrings the ability to 
> improve APIs in a lot of ways without breaking backwards compatibility. A 
> quick example off the top of my head would be all the Cocoa APIs that started 
> out having ivars representing paths backed by simple getter methods, and were 
> later refactored to be URL-based, but with the original path properties 
> become computed properties pointing to the URL’s “path” property. With this, 
> properties would not be able to be refactored in this way unless the library 
> developer had previously declared the “path” property as private(set), which 
> is unlikely for a property that was not intended to be changed after the 
> class was initialized.

My understanding is that this particular nuance — a “let” being semantically 
different from a “var that for whatever reason can’t be set by you" — has 
pretty much been the case since the beginning... it just doesn’t come up much. 
Come to think of it, I don’t even know if Apple's Swift Book mentions it 
(probably should, if it doesn’t).

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

[Christopher Kornher via swift-evolution]

> On Feb 18, 2017, at 6:16 AM, 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. 

I disagree. It is simple enough to use different base names if you don’t want 
the cases to match. An example of why it should not be an error: I intend to 
for errors with same base names to be handled in the same way and I don’t want 
to enumerate all the similar cases and change code every time I add a new way 
to construct an error. I understand that other people want the equivalent of 
function overloading. Code that needs to access values must deal with unique 
cases, so type safety is assured in any case.

Java enums have arguments and match on “base names” (they are quite different, 
but the precedent exists) and I don’t think that matching on the base name 
would be confusing. I also do not believe that it is worth adding this feature 
if all cases are completely unique.The pain of forcing a (probably small) 
subset of developers to use unique names is preferable to complicating the 
language for no functional benefit, in my opinion.


> 
>> - 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] Support for pure functions. Part n + 1.

[Matthew Johnson via swift-evolution]

> On Feb 20, 2017, at 1:23 PM, Charles Srstka  wrote:
> 
>> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
 On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution 
 > wrote:
 
 a) Structs/Locals:
 Structs and local variables behave similarly. You can access `let` and 
 `var` properties and mutate the later.
>>> 
>>> What if the struct contains class ivars, including private ones that you 
>>> may not know about but nonetheless get accessed as a side effect of 
>>> accessing the struct’s “var” properties?
>> 
>> You should be able to access them in accordance with the restrictions on 
>> using classes in a pure manner.
> 
> How can those restrictions be enforced, if the class is a private internal 
> property of the struct that the calling code can’t see?

If calling code can’t see it, it also can’t access it.  It can only be reached 
through a different member of the struct.  That member would need to be pure.  
That is where it would be enforced.

> 
 b) Classes:
 You can't access the variables of a class in a pure function. But you can 
 access its `let` properties. That's because as long as there is no `var` 
 in the dereferencing path, you are guarantied to be accessing a constant. 
 In classes, `let` properties are thus implicitly pure; stored `var` 
 properties are not. Which means that pure instance methods on classes can 
 only access `let` properties, in addition to computed properties that are 
 themselves `pure` and other `pure` methods.
>>> 
>>> What if the “let” property becomes a “var” property in a future version of 
>>> the library you’re linking against?
>> 
>> That would be a breaking change if the `let` was public or if any `pure` 
>> public methods were accessing it (unless they were refactored to not rely on 
>> it anymore).
> 
> I’m not sure how I feel about that, since it hamstrings the ability to 
> improve APIs in a lot of ways without breaking backwards compatibility. A 
> quick example off the top of my head would be all the Cocoa APIs that started 
> out having ivars representing paths backed by simple getter methods, and were 
> later refactored to be URL-based, but with the original path properties 
> become computed properties pointing to the URL’s “path” property. With this, 
> properties would not be able to be refactored in this way unless the library 
> developer had previously declared the “path” property as private(set), which 
> is unlikely for a property that was not intended to be changed after the 
> class was initialized.

Computed read-only properties could be `pure`.  If the refactoring was able to 
preserve this purity it shouldn’t be a breaking change (with respect to purity 
at least).  Stored `var` properties of a class would never be pure.

> 
> Charles

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

[Michel Fortin via swift-evolution]

> Le 20 févr. 2017 à 13:42, Charles Srstka  a écrit :
> 
>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution 
>>  wrote:
>> 
>> a) Structs/Locals:
>> Structs and local variables behave similarly. You can access `let` and `var` 
>> properties and mutate the later.
> 
> What if the struct contains class ivars, including private ones that you may 
> not know about but nonetheless get accessed as a side effect of accessing the 
> struct’s “var” properties?

You can look at the value of the pointer to that class instance (you can 
convert that pointer to a hex value and return it as a string if you want), but 
if you dereference the pointer you need to follow the rules for classes. If you 
call any accessor (because the type is opaque or for other reasons), those 
accessors must be pure (and thus follow the same rules).


>> b) Classes:
>> You can't access the variables of a class in a pure function. But you can 
>> access its `let` properties. That's because as long as there is no `var` in 
>> the dereferencing path, you are guarantied to be accessing a constant. In 
>> classes, `let` properties are thus implicitly pure; stored `var` properties 
>> are not. Which means that pure instance methods on classes can only access 
>> `let` properties, in addition to computed properties that are themselves 
>> `pure` and other `pure` methods.
> 
> What if the “let” property becomes a “var” property in a future version of 
> the library you’re linking against?

That's an interesting question. Either `let` provides purity guaranties 
implicitly (as I was suggesting), or it needs to be annotated `pure` in order 
to provide those guaranties. The later would allow changing a `let` to a `var` 
in a future version of a library without breaking clients. And you could also 
change a `pure let` to a `pure var`. Perhaps being explicit is better. In the 
end, it depends on how resilience works for `let`.

-- 
Michel Fortin
https://michelf.ca

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

[Charles Srstka via swift-evolution]

> On Feb 20, 2017, at 12:53 PM, Matthew Johnson  wrote:
> 
>> 
>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution 
>> > wrote:
>> 
>>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution 
>>> > wrote:
>>> 
>>> a) Structs/Locals:
>>> Structs and local variables behave similarly. You can access `let` and 
>>> `var` properties and mutate the later.
>> 
>> What if the struct contains class ivars, including private ones that you may 
>> not know about but nonetheless get accessed as a side effect of accessing 
>> the struct’s “var” properties?
> 
> You should be able to access them in accordance with the restrictions on 
> using classes in a pure manner.

How can those restrictions be enforced, if the class is a private internal 
property of the struct that the calling code can’t see?

>>> b) Classes:
>>> You can't access the variables of a class in a pure function. But you can 
>>> access its `let` properties. That's because as long as there is no `var` in 
>>> the dereferencing path, you are guarantied to be accessing a constant. In 
>>> classes, `let` properties are thus implicitly pure; stored `var` properties 
>>> are not. Which means that pure instance methods on classes can only access 
>>> `let` properties, in addition to computed properties that are themselves 
>>> `pure` and other `pure` methods.
>> 
>> What if the “let” property becomes a “var” property in a future version of 
>> the library you’re linking against?
> 
> That would be a breaking change if the `let` was public or if any `pure` 
> public methods were accessing it (unless they were refactored to not rely on 
> it anymore).

I’m not sure how I feel about that, since it hamstrings the ability to improve 
APIs in a lot of ways without breaking backwards compatibility. A quick example 
off the top of my head would be all the Cocoa APIs that started out having 
ivars representing paths backed by simple getter methods, and were later 
refactored to be URL-based, but with the original path properties become 
computed properties pointing to the URL’s “path” property. With this, 
properties would not be able to be refactored in this way unless the library 
developer had previously declared the “path” property as private(set), which is 
unlikely for a property that was not intended to be changed after the class was 
initialized.

Charles

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