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

[David Hart via swift-evolution]

> On 22 Feb 2017, at 08:37, Jonathan Hull  wrote:
> 
> I fully agree. I actually think that applies to both solutions though.  As 
> much as I would like to see the mess around private fixed, I think it needs 
> to be as part of a well considered redesign of the access system that adds 
> enough functionality to stop this cycle.  We can’t just rename things or flip 
> back and forth between options every 6 months.
> 
> As an example of what I think *is* an appropriate change is Nevin’s 
> suggestion on another thread to add a single level of submodules (which group 
> files).  As part of this change, ‘private’ would mean private to the 
> submodule (or file if the file is not part of a submodule). 
> Internal/Public/Open would remain unchanged.  Thus you have only private, 
> internal, and public/open… but the fix came as part of unifying with other 
> improvements (and is not just returning to pre-0025).

I saw this but it looks very confusing for me: private would mean different 
things in different contexts and I would have no way to make things private to 
a file in a submodule.

> Thanks,
> Jon
> 
>> On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Well-written as-is.
>> 
>> Overall, my feedback is that solution 2 should not be on the table (though 
>> there are people who clamor for it), and not because I don't agree with it. 
>> However, simply as a matter of following an appropriate process, solution 2 
>> was originally proposed in SE-0025, fully considered, and modified by the 
>> core team to the current design. One can disagree whether `scoped` is more 
>> appropriate than `private` as a name for that access modifier, and one is 
>> likely to say that `private` looks nicer than `fileprivate`, but that's 
>> neither here nor there. The appropriateness or niceness of these terms is 
>> unchanged from last year. Re-submitting SE-0025 cannot be the solution for 
>> fixing SE-0025.
> 

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

Re: [swift-evolution] [Discussion] Allowing extending existentials

[Slava Pestov via swift-evolution]

> On Feb 21, 2017, at 11:42 PM, David Hart via swift-evolution 
>  wrote:
> 
> If we drop the idea of extending Any and AnyObject (which is out of scope), 
> does the fact that what is left is syntactic sugar make it unsuitable for 
> Swift 4? I remember Chris saying syntactic sugar is not the goal for Swift 4, 
> but this syntactic sugar looks really sweet (pun intended).
> 

It’s unlikely we’ll make it a priority to implement anything like that in the 
Swift 4 timeframe, but PRs are more than welcome ;-)

Slava

> On 22 Feb 2017, at 08:36, Douglas Gregor  > wrote:
> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Feb 21, 2017, at 11:25 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>>> Yes, but it's not very discoverable. Plus, if the subclass existentials 
>>> proposal is accepted, it would actually allow us to do:
>>> 
>>> class C {}
>>> extension C & P1 {}
>> 
>> ... which is 
>> 
>> extension P1 where Self: C1 {}
>> 
>> 
>> Actually extending semantics (e.g. to extend Any or AnyObject) is a very 
>> large project that's out of scope. Without that, this is a small bit of 
>> syntactic sugar. 
>> 
>>   - Doug
>> 
>>> 
>>> On 22 Feb 2017, at 08:06, Jacob Bandes-Storch >> > wrote:
>>> 
 This works today:
 
 protocol P1{}
 protocol P2{}
 
 extension P1 where Self: P2 {
 func foo() {}
 }
 
 func bar(x: P1 & P2) {
 x.foo()
 }
 
 
 On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution 
 > wrote:
 Hello list,
 
 Found out yesterday that you can’t extend all existentials in Swift:
 
 protocol P1 {}
 extension P1 {}
 // works as expected
 
 protocol P2 {}
 extension P1 & P2 {}
 // error: non-nominal type 'P1 & P2' cannot be extended
 
 extension Any {}
 // error: non-nominal type 'Any' cannot be extended
 
 extension AnyObject {}
 // error: 'AnyObject' protocol cannot be extended
 
 I’d like to write a proposal to lift some of those restrictions. But the 
 question is: which should be lifted? P1 & P2 seems like an obvious case. 
 But what about Any and AnyObject? Is there a design reason that we 
 shouldn’t allow it?
 
 David.
 
 ___
 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] [Discussion] Allowing extending existentials

[David Hart via swift-evolution]

If we drop the idea of extending Any and AnyObject (which is out of scope), 
does the fact that what is left is syntactic sugar make it unsuitable for Swift 
4? I remember Chris saying syntactic sugar is not the goal for Swift 4, but 
this syntactic sugar looks really sweet (pun intended).

> On 22 Feb 2017, at 08:36, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Feb 21, 2017, at 11:25 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Yes, but it's not very discoverable. Plus, if the subclass existentials 
>> proposal is accepted, it would actually allow us to do:
>> 
>> class C {}
>> extension C & P1 {}
> 
> ... which is 
> 
> extension P1 where Self: C1 {}
> 
> 
> Actually extending semantics (e.g. to extend Any or AnyObject) is a very 
> large project that's out of scope. Without that, this is a small bit of 
> syntactic sugar. 
> 
>   - Doug
> 
>> 
>>> On 22 Feb 2017, at 08:06, Jacob Bandes-Storch  wrote:
>>> 
>>> This works today:
>>> 
>>> protocol P1{}
>>> protocol P2{}
>>> 
>>> extension P1 where Self: P2 {
>>> func foo() {}
>>> }
>>> 
>>> func bar(x: P1 & P2) {
>>> x.foo()
>>> }
>>> 
>>> 
 On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution 
  wrote:
 Hello list,
 
 Found out yesterday that you can’t extend all existentials in Swift:
 
 protocol P1 {}
 extension P1 {}
 // works as expected
 
 protocol P2 {}
 extension P1 & P2 {}
 // error: non-nominal type 'P1 & P2' cannot be extended
 
 extension Any {}
 // error: non-nominal type 'Any' cannot be extended
 
 extension AnyObject {}
 // error: 'AnyObject' protocol cannot be extended
 
 I’d like to write a proposal to lift some of those restrictions. But the 
 question is: which should be lifted? P1 & P2 seems like an obvious case. 
 But what about Any and AnyObject? Is there a design reason that we 
 shouldn’t allow it?
 
 David.
 
 ___
 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] [Discussion] Allowing extending existentials

[Slava Pestov via swift-evolution]

> On Feb 21, 2017, at 11:34 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’d love if we could extend the idea even further. It would be great to be 
> able to extend the typealias type, because it can be a more constrained type 
> (with a where clause).
> 
> protocol P {
> associatedtype Q
> }
> class C {}
> 
> typealias CP = C & P where Q == Int
> 
> extension CP { … }
> This would make a lot of constrained extension vanish.
> 
> 

Once we have generalized existentials, it should be possible to make something 
like the above desugar into a constrained extension.

Slava
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 22. Februar 2017 um 08:26:33, David Hart via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Yes, but it's not very discoverable. Plus, if the subclass existentials 
>> proposal is accepted, it would actually allow us to do:
>> 
>> class C {}
>> extension C & P1 {}
>> 
>> On 22 Feb 2017, at 08:06, Jacob Bandes-Storch > > wrote:
>> 
>>> This works today:
>>> 
>>> protocol P1{}
>>> protocol P2{}
>>> 
>>> extension P1 where Self: P2 {
>>> func foo() {}
>>> }
>>> 
>>> func bar(x: P1 & P2) {
>>> x.foo()
>>> }
>>> 
>>> 
>>> On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution 
>>> > wrote:
>>> Hello list,
>>> 
>>> Found out yesterday that you can’t extend all existentials in Swift:
>>> 
>>> protocol P1 {}
>>> extension P1 {}
>>> // works as expected
>>> 
>>> protocol P2 {}
>>> extension P1 & P2 {}
>>> // error: non-nominal type 'P1 & P2' cannot be extended
>>> 
>>> extension Any {}
>>> // error: non-nominal type 'Any' cannot be extended
>>> 
>>> extension AnyObject {}
>>> // error: 'AnyObject' protocol cannot be extended
>>> 
>>> I’d like to write a proposal to lift some of those restrictions. But the 
>>> question is: which should be lifted? P1 & P2 seems like an obvious case. 
>>> But what about Any and AnyObject? Is there a design reason that we 
>>> shouldn’t allow it?
>>> 
>>> David.
>>> 
>>> ___
>>> 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] [Discussion] Allowing extending existentials

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Feb 21, 2017, at 11:25 PM, David Hart via swift-evolution 
>  wrote:
> 
> Yes, but it's not very discoverable. Plus, if the subclass existentials 
> proposal is accepted, it would actually allow us to do:
> 
> class C {}
> extension C & P1 {}

... which is 

extension P1 where Self: C1 {}


Actually extending semantics (e.g. to extend Any or AnyObject) is a very large 
project that's out of scope. Without that, this is a small bit of syntactic 
sugar. 

  - Doug

> 
>> On 22 Feb 2017, at 08:06, Jacob Bandes-Storch  wrote:
>> 
>> This works today:
>> 
>> protocol P1{}
>> protocol P2{}
>> 
>> extension P1 where Self: P2 {
>> func foo() {}
>> }
>> 
>> func bar(x: P1 & P2) {
>> x.foo()
>> }
>> 
>> 
>>> On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution 
>>>  wrote:
>>> Hello list,
>>> 
>>> Found out yesterday that you can’t extend all existentials in Swift:
>>> 
>>> protocol P1 {}
>>> extension P1 {}
>>> // works as expected
>>> 
>>> protocol P2 {}
>>> extension P1 & P2 {}
>>> // error: non-nominal type 'P1 & P2' cannot be extended
>>> 
>>> extension Any {}
>>> // error: non-nominal type 'Any' cannot be extended
>>> 
>>> extension AnyObject {}
>>> // error: 'AnyObject' protocol cannot be extended
>>> 
>>> I’d like to write a proposal to lift some of those restrictions. But the 
>>> question is: which should be lifted? P1 & P2 seems like an obvious case. 
>>> But what about Any and AnyObject? Is there a design reason that we 
>>> shouldn’t allow it?
>>> 
>>> David.
>>> 
>>> ___
>>> 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] [Draft] Fix Private Access Levels

[Jonathan Hull via swift-evolution]

I fully agree. I actually think that applies to both solutions though.  As much 
as I would like to see the mess around private fixed, I think it needs to be as 
part of a well considered redesign of the access system that adds enough 
functionality to stop this cycle.  We can’t just rename things or flip back and 
forth between options every 6 months.

As an example of what I think *is* an appropriate change is Nevin’s suggestion 
on another thread to add a single level of submodules (which group files).  As 
part of this change, ‘private’ would mean private to the submodule (or file if 
the file is not part of a submodule). Internal/Public/Open would remain 
unchanged.  Thus you have only private, internal, and public/open… but the fix 
came as part of unifying with other improvements (and is not just returning to 
pre-0025).

Thanks,
Jon

> On Feb 21, 2017, at 2:41 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Well-written as-is.
> 
> Overall, my feedback is that solution 2 should not be on the table (though 
> there are people who clamor for it), and not because I don't agree with it. 
> However, simply as a matter of following an appropriate process, solution 2 
> was originally proposed in SE-0025, fully considered, and modified by the 
> core team to the current design. One can disagree whether `scoped` is more 
> appropriate than `private` as a name for that access modifier, and one is 
> likely to say that `private` looks nicer than `fileprivate`, but that's 
> neither here nor there. The appropriateness or niceness of these terms is 
> unchanged from last year. Re-submitting SE-0025 cannot be the solution for 
> fixing SE-0025.

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

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[David Hart via swift-evolution]

> 
> On 22 Feb 2017, at 08:05, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Evolutioniers,
> 
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to 
> disambiguate references to functions. (You might've used it inside a 
> #selector expression.) But there's currently no compound name for a function 
> with no arguments.
> 
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
> 
> Given these four functions, only the first one has no compound name syntax. 
> And the simple reference "let myfn = foo" is ambiguous because it could refer 
> to any of the four. A workaround is to specify a contextual type, e.g. "let 
> myfn = foo as () -> Void".
> 
> I filed SR-3550 for this a while ago, and there was some discussion in JIRA 
> about it. I'd like to continue exploring solutions here and then write up a 
> formal proposal.
> 
> To kick off the discussion, I'd like to propose foo(:) for nullary functions.
> 
> Advantages:
> - the colon marks a clear similarity to the foo(bar:) form when argument 
> labels are present.
> - cutely parallels the empty dictionary literal, [:].
> 
> Disadvantages:
> - violates intuition about one-colon-per-argument.

This is a big disadvantage for me and will potentially be very surprising for 
newcomers.

> - the parallel between #selector(foo(:))and @selector(foo) is not quite as 
> obvious as between #selector(foo(_:))and @selector(foo:).
> 
> 
> For the sake of discussion, another option would be foo(_). This was my 
> original choice, and I like that the number of colons matches the number of 
> parameters. However, it's a little less obvious as a function reference. It 
> would preclude _ from acting as an actual identifier, and might conflict with 
> pattern-matching syntax (although it appears functions can't be compared with 
> ~= anyway).

This is my favorite syntax so far.

> Looking forward to everyone's bikeshed color ideas,
> Jacob
> ___
> 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] Allowing extending existentials

[Adrian Zubarev via swift-evolution]

I’d love if we could extend the idea even further. It would be great to be able 
to extend the typealias type, because it can be a more constrained type (with a 
where clause).

protocol P {
associatedtype Q
}
class C {}

typealias CP = C & P where Q == Int

extension CP { … }
This would make a lot of constrained extension vanish.



-- 
Adrian Zubarev
Sent with Airmail

Am 22. Februar 2017 um 08:26:33, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:

Yes, but it's not very discoverable. Plus, if the subclass existentials 
proposal is accepted, it would actually allow us to do:

class C {}
extension C & P1 {}

On 22 Feb 2017, at 08:06, Jacob Bandes-Storch  wrote:

This works today:

protocol P1{}
protocol P2{}

extension P1 where Self: P2 {
    func foo() {}
}

func bar(x: P1 & P2) {
    x.foo()
}


On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution 
 wrote:
Hello list,

Found out yesterday that you can’t extend all existentials in Swift:

protocol P1 {}
extension P1 {}
// works as expected

protocol P2 {}
extension P1 & P2 {}
// error: non-nominal type 'P1 & P2' cannot be extended

extension Any {}
// error: non-nominal type 'Any' cannot be extended

extension AnyObject {}
// error: 'AnyObject' protocol cannot be extended

I’d like to write a proposal to lift some of those restrictions. But the 
question is: which should be lifted? P1 & P2 seems like an obvious case. But 
what about Any and AnyObject? Is there a design reason that we shouldn’t allow 
it?

David.

___
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: Compound name `foo(:)` for nullary functions

[Slava Pestov via swift-evolution]

> On Feb 21, 2017, at 11:05 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Evolutioniers,
> 
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to 
> disambiguate references to functions. (You might've used it inside a 
> #selector expression.) But there's currently no compound name for a function 
> with no arguments.
> 
> func foo() {}  // no compound syntax for this one :(
> func foo(_ bar: Int) {}  // foo(_:)
> func foo(bar: Int) {}  // foo(bar:)
> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
> 
> Given these four functions, only the first one has no compound name syntax. 
> And the simple reference "let myfn = foo" is ambiguous because it could refer 
> to any of the four. A workaround is to specify a contextual type, e.g. "let 
> myfn = foo as () -> Void".
> 
> I filed SR-3550  for this a while ago, 
> and there was some discussion in JIRA about it. I'd like to continue 
> exploring solutions here and then write up a formal proposal.
> 
> To kick off the discussion, I'd like to propose foo(:) for nullary functions.

I like this idea.

> 
> Advantages:
> - the colon marks a clear similarity to the foo(bar:) form when argument 
> labels are present.
> - cutely parallels the empty dictionary literal, [:].
> 
> Disadvantages:
> - violates intuition about one-colon-per-argument.
> - the parallel between #selector(foo(:)) and @selector(foo) is not quite as 
> obvious as between #selector(foo(_:)) and @selector(foo:).
> 
> 
> For the sake of discussion, another option would be foo(_). This was my 
> original choice, and I like that the number of colons matches the number of 
> parameters. However, it's a little less obvious as a function reference. It 
> would preclude _ from acting as an actual identifier, and might conflict with 
> pattern-matching syntax (although it appears functions can't be compared with 
> ~= anyway).

foo(_) looks like a pattern to me. Even if it doesn’t introduce ambiguity in 
the grammar it might be confusing.

> 
> 
> Looking forward to everyone's bikeshed color ideas,
> Jacob
> ___
> 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 21, 2017, at 8:33 PM, Matthew Johnson  wrote:
> 
>> 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
> 
> Am I understanding this correctly?  It looks like ModKit.Foo.Bar cannot see 
> or import any symbols declared in ModKit.Foo or ModKit.  Is that correct?  
> Descendents cannot see or import symbols declared in ancestors (including 
> public symbols) but they can import any submodule that is not their ancestor 
> (and therefore see public symbols in any submodule that’s not an ancestor by 
> way of importing that submodule)?  

Yes, that's correct.

> I think I understand why you might have specified this design but am 
> interested in hearing you elaborate a bit further on the rationale.

A few reasons:

1. It creates a stricter layering between parent modules and submodules: 
submodules are for lower layers, while parent modules are for higher layers. 
Layering reduces spaghetti, and less spaghetti is generally a good thing.

2. It limits the amount of code the compiler has to consider at once.

3. It helps avoid (but doesn't completely prevent) circular dependencies 
between submodules, ensuring there's an order in which they can be compiled 
separately.

On the other hand, a design which considered all submodules at once would 
certainly be more flexible. You could call back and forth between submodules 
and their parents freely, and organize your code more flexibly. But I'm not 
sure it can be made to work with this "build system decides what's in a 
submodule" approach—I'm trying to imagine how you would tell the compiler about 
the submodule mappings for fifty files without that information being in the 
source code, and I'm not liking any of the solutions I'm coming up with.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Discussion] Allowing extending existentials

[Slava Pestov via swift-evolution]

> On Feb 21, 2017, at 10:53 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello list,
> 
> Found out yesterday that you can’t extend all existentials in Swift:
> 
> protocol P1 {}
> extension P1 {}
> // works as expected
> 
> protocol P2 {}
> extension P1 & P2 {}
> // error: non-nominal type 'P1 & P2' cannot be extended

This will make name lookup rather complicated. I’d rather not do it. As Jacob 
mentions, you can almost simulate it with a constrained extension.

> 
> extension Any {}
> // error: non-nominal type 'Any' cannot be extended
> 
> extension AnyObject {}
> // error: 'AnyObject' protocol cannot be extended

These two are by design. In the future, AnyObject will be ‘special’ (basically 
we want to model it as ‘Any & class’), and not a protocol.

Slava

> 
> I’d like to write a proposal to lift some of those restrictions. But the 
> question is: which should be lifted? P1 & P2 seems like an obvious case. But 
> what about Any and AnyObject? Is there a design reason that we shouldn’t 
> allow it?
> 
> David.
> ___
> 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 Draft] Remove open Access Modifier

[Charlie Monroe via swift-evolution]

> On Feb 22, 2017, at 8:15 AM, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 21 févr. 2017 à 17:19, Tino Heth via swift-evolution 
>> > a écrit :
>> 
>> 
>>> I’ll concede that the proposal makes a claim that might very well be 
>>> disproved. I would very much like to see an actual example of a public 
>>> class that **has** to be public but **shouldn’t** be open for obvious 
>>> reasons. I would happily accept being shown wrong on that point.
>> This is afaics one of the most active disputes on evolution — and you can 
>> save you a lot of grief by accepting that it is pointless:
>> The whole discussion isn't based on facts at all, despite many false claims 
>> that marking things as final is generally better.
>> I have asked for a single example to prove this in the past as well, so I 
>> guess no one can present such a thing to you.

To me, the largest purpose is when you have a root class ("abstract") and a few 
subclasses that represent various options - in Scala, this would be a case 
class. For various reasons, it can't be an enum - for example, you need a lot 
of stored data and an enum case a(Int, Int, Int, Bool, Int, Double) is not very 
usable.

In certain places, you can have switches based on the actual subtype - with the 
default case causing fatalError. In such case, you definitely don't want 
additional subclasses to exist outside of the module as it would break the 
assumption of a known number of subclasses.

You can't make the root class final since you inherit from it. In such case, 
the public modifier makes sense.


> 
> This is bad faith. The original discussion contains many real life example. 
> You just don’t want to admit open is useful for many library writers.
> 
>> It is personal preference, so arguments don't help much here.
>> 
>> Maybe it helps to know the whole story, as everything started with "final 
>> should be default", followed by a try to forbid subclassing for types from a 
>> different module by default, finally arriving at the current compromise 
>> where you have to decide wether module clients should be allowed to subclass 
>> or not.
>> Nobody ever requested that public should be the only access level, so there 
>> has been only been pressure applied from one direction — it's interesting to 
>> see some backlash now.
>> Imho people already were quite tired of discussion when public/open was 
>> accepted as a compromise...
>> ___
>> 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] Let's talk about submodules

[Jonathan Hull via swift-evolution]

I think I could get behind this.  It definitely takes care of the 80%. 

It might even enable adding storage in extensions *within the submodule*


There is one major use case which I see all of these proposals failing to 
handle (although that may be intentional for some designs), is where you have 
something internal to the type, but you still want to allow 
subclasses/extensions outside the framework (which need that information) to 
access it.  An actual example of this is UIGestureRecognizer.  This class is 
designed to be subclassed outside of the framework, but it hides things like 
setting the ‘state' from client code (without hiding it from subclasses). This 
is important, because if a client sets the state directly, then it results in 
either undefined behavior, or an infinite loop.  Other languages use 
‘protected’ and ‘friend’ to accomplish this.  I am wondering if there is 
something we can do to solve that in Swift without the complication of 
protected/friend...

Thanks,
Jon

> On Feb 21, 2017, at 3:40 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> I think entities declared as “internal” should be visible throughout the 
> entire *module* just as they are today. In particular, if I write “struct Foo 
> {}” inside a submodule, then Foo should have internal visibility (the default 
> when no access level is specified) and thus should be available to the entire 
> module.
> 
> Similarly, if I write “public struct Bar {}” inside a submodule, then Bar 
> should be exported from the module and available to client code. In other 
> words, the submodule should exist to *organize* code, not to change its 
> meaning.
> 
> Moreover, the ongoing access level discussions elsewhere on the list make 
> clear that many people believe there should be just one visibility more 
> restricted than “internal” (which of course should be named “private”). If we 
> go that route, then “private” would mean “visible in this submodule only”. 
> For files which are not in a submodule this acts like “fileprivate”, and for 
> files which *are* in a submodule it means they can share their implementation 
> details with closely related code (usually types and extensions) while 
> allowing that code to be in separate files as appropriate.
> 
> That is most of what I want out of submodules: to provide all the benefits of 
> Swift-2-era “private” without requiring that everything be stuffed inside one 
> single file. For all other purposes a submodule would be transparent, it just 
> lets you split up a large file along its natural divisions. Consequently, I 
> see no need or purpose for nested submodules, because a submodule simply 
> “acts like” a single file.
> 
> Nevin
> ___
> 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] Allowing extending existentials

[Jacob Bandes-Storch via swift-evolution]

This works today:

protocol P1{}
protocol P2{}

extension P1 where Self: P2 {
func foo() {}
}

func bar(x: P1 & P2) {
x.foo()
}


On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello list,
>
> Found out yesterday that you can’t extend all existentials in Swift:
>
> protocol P1 {}
> extension P1 {}
> // works as expected
>
> protocol P2 {}
> extension P1 & P2 {}
> // error: non-nominal type 'P1 & P2' cannot be extended
>
> extension Any {}
> // error: non-nominal type 'Any' cannot be extended
>
> extension AnyObject {}
> // error: 'AnyObject' protocol cannot be extended
>
> I’d like to write a proposal to lift some of those restrictions. But the
> question is: which should be lifted? P1 & P2 seems like an obvious case.
> But what about Any and AnyObject? Is there a design reason that we
> shouldn’t allow it?
>
> David.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

[Jacob Bandes-Storch via swift-evolution]

Evolutioniers,

*Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
disambiguate references to functions. (You might've used it inside a
#selector expression.) But there's currently no compound name for a
function with no arguments.

func foo() {}  // no compound syntax for this one :(
func foo(_ bar: Int) {}  // foo(_:)
func foo(bar: Int) {}  // foo(bar:)
func foo(bar: String, baz: Double) {}  // foo(bar:baz:)

Given these four functions, only the first one has no compound name syntax.
And the simple reference "let myfn = foo" is ambiguous because it could
refer to any of the four. A workaround is to specify a contextual type,
e.g. "let myfn = foo as () -> Void".

I filed SR-3550  for this a while
ago, and there was some discussion in JIRA about it. I'd like to continue
exploring solutions here and then write up a formal proposal.

To kick off the discussion, *I'd like to propose foo(:) for nullary
functions.*

Advantages:
- the colon marks a clear similarity to the foo(bar:) form when argument
labels are present.
- cutely parallels the empty dictionary literal, [:].

Disadvantages:
- violates intuition about one-colon-per-argument.
- the parallel between #selector(foo(:)) and @selector(foo) is not quite as
obvious as between #selector(foo(_:)) and @selector(foo:).


For the sake of discussion, another option would be *foo(_)*. This was my
original choice, and I like that the number of colons matches the number of
parameters. However, it's a little less obvious as a function reference. It
would preclude _ from acting as an actual identifier, and might conflict
with pattern-matching syntax (although it appears functions can't be
compared with ~= anyway).


Looking forward to everyone's bikeshed color ideas,
Jacob
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Allowing extending existentials

[David Hart via swift-evolution]

Hello list,

Found out yesterday that you can’t extend all existentials in Swift:

protocol P1 {}
extension P1 {}
// works as expected

protocol P2 {}
extension P1 & P2 {}
// error: non-nominal type 'P1 & P2' cannot be extended

extension Any {}
// error: non-nominal type 'Any' cannot be extended

extension AnyObject {}
// error: 'AnyObject' protocol cannot be extended

I’d like to write a proposal to lift some of those restrictions. But the 
question is: which should be lifted? P1 & P2 seems like an obvious case. But 
what about Any and AnyObject? Is there a design reason that we shouldn’t allow 
it?

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

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

[David Hart via swift-evolution]

> On 21 Feb 2017, at 23:41, Xiaodi Wu  wrote:
> 
> Well-written as-is.
> 
> Overall, my feedback is that solution 2 should not be on the table (though 
> there are people who clamor for it), and not because I don't agree with it. 
> However, simply as a matter of following an appropriate process, solution 2 
> was originally proposed in SE-0025, fully considered, and modified by the 
> core team to the current design. One can disagree whether `scoped` is more 
> appropriate than `private` as a name for that access modifier, and one is 
> likely to say that `private` looks nicer than `fileprivate`, but that's 
> neither here nor there. The appropriateness or niceness of these terms is 
> unchanged from last year. Re-submitting SE-0025 cannot be the solution for 
> fixing SE-0025.

I agree with you, as you know that I support Solution 1. But I was hoping to 
reduce the amount of community flamewar by giving each alternative a level 
chance and letting the core team decide. But you make a good point about the 
fact that it was the state SE-0025 was it before it was modified by the core 
team. And I’m starting to have doubts. What do you think Matthew?

> On Tue, Feb 21, 2017 at 12:58 AM, David Hart  > 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:
> 
>  
> 

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

[Robert Widmann via swift-evolution]

> On Feb 22, 2017, at 12:41 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Feb 21, 2017, at 11:09 PM, Robert Widmann  > wrote:
> 
>> 
>>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Feb 21, 2017, at 10:41 PM, Robert Widmann > wrote:
 
 By API boundaries I mean both the one internal to MyModule.Foo and the one 
 defined by MyModule.  Here “the API boundary” is explicitly about the 
 submodule MyModule.Foo, whose internal state may have been “unsealed” in 
 the top level by the extension, but has not been re-exported.
>>> 
>>> I’m sorry, but I just don’t understand how modules form an API boundary in 
>>> this system.  To me a boundary means something that blocks access.  In this 
>>> system `internal` ranges over the entire module and all submodules.  The 
>>> only boundaries I can see besides the module itself are files and lexical 
>>> scopes (with `fileprivate` and `private`).  
>>> 
>> 
>> 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).
>> 
>> 
>> Your API boundary lives, as it does today, at the edges of each (sub)module 
>> declaration.  APIs that are public or open in a module defines code that is 
>> free to move across this boundary and into the open.  APIs that are internal 
>> are free to have their modules unsealed into other internal modules to 
>> enable modular composition.  APIs that are private and fileprivate do not 
>> participate in the API boundary because they are not eligible for any kind 
>> of export.  
>> 
>> If any of that is unclear, please let me know. 
> 
> Yes, in fact parts are unclear.
> 
> "APIs that are public or open in a module defines code that is free to move 
> across this boundary and into the open"
> 
> This is unclear because you're saying submodules form an API boundary and 
> you're also saying we need to make APIs open or public to allow them to move 
> across this boundary.  But then you say we can unseal it (import or extend, 
> right?) within the module and gain visibility to the internal symbols.  Are 
> you trying to say that it's a soft boundary within the module that can be 
> permeated with an import or by extension?

Of course.  Soft implies more permeability than you are actually afforded, but 
if you want to think of it that way then it may help to put it in context.  

For what it’s worth, the bulk of the discussion around this feature is focused 
on author-side concerns like the behavior of internal modules because access 
control makes a mess of any reasonable semantics. 

> 
> If so, that's not the kind of boundary I think many of us are talking about.  
> We're talking about a hard boundary within the module, but broader than a 
> file.

How then, does one go about accessing declarations contained in these kinds of 
impermeable modules?  You must define points of exposure to be able to use the 
module.  What you’re describing is as though you had can only build hierarchies 
of completely private types and then cherry-pick them one-by-one into the open 
- which, mind you, is not a pattern encouraged by any of the access control 
levels we have today and isn’t supported by any language I’m aware of.

> 
>>>  means that it is trivial to put code anywhere within the module that 
>>> extends the submodule and wraps a symbol in a new name and declares it 
>>> `public`.  
>> 
>> Precisely.  That’s the same pattern that good Swift code, arguably good code 
>> in any language that enables hiding, uses today.
>> 
>>> They can also trivially add a `public import MyModule.Foo` anywhere at the 
>>> top level of their file because every file is forced to include top level 
>>> scope.
>> 
>> Perhaps you misunderstand.  Say the APIs in MyModule.Foo were all of 
>> internal or stricter access: The re-export is a no-op.  You cannot change 
>> the access level of declarations, you can only do the modular thing and wrap 
>> them in a palatable interface for export by a module you want to be 
>> user-facing.  You have to decide to make an API public, just as today you 
>> have to decide to make part of an interface public.  I don’t see how this is 
>> distinct from the goals of this proposal.
> 
> Yes, I understand this.  But submodules aren't visible outside the module by 
> default.  It's possible for a submodule to have public and open symbols 
> without the top level public import anywhere in the program.  

> What I'm saying here is that someone in a distant part of the code base could 
> arbitrarily add it if they 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 21, 2017, at 11:09 PM, Robert Widmann  wrote:
> 
> 
>>> On Feb 21, 2017, at 11:59 PM, Matthew Johnson  
>>> wrote:
>>> 
>>> 
>>> On Feb 21, 2017, at 10:41 PM, Robert Widmann  
>>> wrote:
>>> 
>>> By API boundaries I mean both the one internal to MyModule.Foo and the one 
>>> defined by MyModule.  Here “the API boundary” is explicitly about the 
>>> submodule MyModule.Foo, whose internal state may have been “unsealed” in 
>>> the top level by the extension, but has not been re-exported.
>> 
>> I’m sorry, but I just don’t understand how modules form an API boundary in 
>> this system.  To me a boundary means something that blocks access.  In this 
>> system `internal` ranges over the entire module and all submodules.  The 
>> only boundaries I can see besides the module itself are files and lexical 
>> scopes (with `fileprivate` and `private`).  
>> 
> 
> 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).
> 
> 
> Your API boundary lives, as it does today, at the edges of each (sub)module 
> declaration.  APIs that are public or open in a module defines code that is 
> free to move across this boundary and into the open.  APIs that are internal 
> are free to have their modules unsealed into other internal modules to enable 
> modular composition.  APIs that are private and fileprivate do not 
> participate in the API boundary because they are not eligible for any kind of 
> export.  
> 
> If any of that is unclear, please let me know. 

Yes, in fact parts are unclear.

"APIs that are public or open in a module defines code that is free to move 
across this boundary and into the open"

This is unclear because you're saying submodules form an API boundary and 
you're also saying we need to make APIs open or public to allow them to move 
across this boundary.  But then you say we can unseal it (import or extend, 
right?) within the module and gain visibility to the internal symbols.  Are you 
trying to say that it's a soft boundary within the module that can be permeated 
with an import or by extension?

If so, that's not the kind of boundary I think many of us are talking about.  
We're talking about a hard boundary within the module, but broader than a file.

>>  means that it is trivial to put code anywhere within the module that 
>> extends the submodule and wraps a symbol in a new name and declares it 
>> `public`.  
> 
> Precisely.  That’s the same pattern that good Swift code, arguably good code 
> in any language that enables hiding, uses today.
> 
>> They can also trivially add a `public import MyModule.Foo` anywhere at the 
>> top level of their file because every file is forced to include top level 
>> scope.
> 
> Perhaps you misunderstand.  Say the APIs in MyModule.Foo were all of internal 
> or stricter access: The re-export is a no-op.  You cannot change the access 
> level of declarations, you can only do the modular thing and wrap them in a 
> palatable interface for export by a module you want to be user-facing.  You 
> have to decide to make an API public, just as today you have to decide to 
> make part of an interface public.  I don’t see how this is distinct from the 
> goals of this proposal.

Yes, I understand this.  But submodules aren't visible outside the module by 
default.  It's possible for a submodule to have public and open symbols without 
the top level public import anywhere in the program.  What I'm saying here is 
that someone in a distant part of the code base could arbitrarily add it if 
they decided to.  The system doesn't prevent it.  

I understand that you consider that a non goal.  I'm simply pointing out that 
the system has this property.  I think it's reasonable to want a system with 
different properties.  And I don't think it's clear yet exactly what kind of 
system might garner the support necessary to be accepted as Swift's submodule 
system.  That's part of the reason we have these discussions! :)

> 
>> 
>> In my opinion, we need to identify what goals we have for a submodule system 
>> - what problems are we trying to solve and what use cases do we intend to 
>> enable.  
>> 
>> There are quite a few of us who want the ability to form solid API 
>> boundaries inside a module and view this as one of the fundamental features 
>> of a submodule system.  It’s reasonable to ask why we view this capability 
>> as essential.
>> 
>> I can’t speak for anyone else, but here are a few reasons why it’s important 
>> to me:
>> 
>> * Solid API boundaries are essential to good design.  
>> * Having access to an entire code base does not reduce the benefits of #1.  
>> Some code bases are substantial in size 

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

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 11:59 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 21, 2017, at 10:41 PM, Robert Widmann > > wrote:
>> 
>> By API boundaries I mean both the one internal to MyModule.Foo and the one 
>> defined by MyModule.  Here “the API boundary” is explicitly about the 
>> submodule MyModule.Foo, whose internal state may have been “unsealed” in the 
>> top level by the extension, but has not been re-exported.
> 
> I’m sorry, but I just don’t understand how modules form an API boundary in 
> this system.  To me a boundary means something that blocks access.  In this 
> system `internal` ranges over the entire module and all submodules.  The only 
> boundaries I can see besides the module itself are files and lexical scopes 
> (with `fileprivate` and `private`).  
> 

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


Your API boundary lives, as it does today, at the edges of each (sub)module 
declaration.  APIs that are public or open in a module defines code that is 
free to move across this boundary and into the open.  APIs that are internal 
are free to have their modules unsealed into other internal modules to enable 
modular composition.  APIs that are private and fileprivate do not participate 
in the API boundary because they are not eligible for any kind of export.  

If any of that is unclear, please let me know. 

> This means that it is trivial to put code anywhere within the module that 
> extends the submodule and wraps a symbol in a new name and declares it 
> `public`.  

Precisely.  That’s the same pattern that good Swift code, arguably good code in 
any language that enables hiding, uses today.

> They can also trivially add a `public import MyModule.Foo` anywhere at the 
> top level of their file because every file is forced to include top level 
> scope.

Perhaps you misunderstand.  Say the APIs in MyModule.Foo were all of internal 
or stricter access: The re-export is a no-op.  You cannot change the access 
level of declarations, you can only do the modular thing and wrap them in a 
palatable interface for export by a module you want to be user-facing.  You 
have to decide to make an API public, just as today you have to decide to make 
part of an interface public.  I don’t see how this is distinct from the goals 
of this proposal.

> 
> In my opinion, we need to identify what goals we have for a submodule system 
> - what problems are we trying to solve and what use cases do we intend to 
> enable.  
> 
> There are quite a few of us who want the ability to form solid API boundaries 
> inside a module and view this as one of the fundamental features of a 
> submodule system.  It’s reasonable to ask why we view this capability as 
> essential.
> 
> I can’t speak for anyone else, but here are a few reasons why it’s important 
> to me:
> 
> * Solid API boundaries are essential to good design.  
> * Having access to an entire code base does not reduce the benefits of #1.  
> Some code bases are substantial in size and hard boundaries are important to 
> keeping them manageable.
> * Using full-fledged modules to do this is possible, but also involves a bit 
> of ceremony that is incidental, not essential complexity in many cases.  It 
> would be better to have a lighter weight mechanism to do this.
> * Swift currently only has whole module optimization, not whole program 
> optimization.  There is a performance penalty to using full-fledged modules.
> 
>> 
>> ~Robert Widmann
>> 
>>> On Feb 21, 2017, at 11:38 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Feb 21, 2017, at 10:29 PM, Robert Widmann > wrote:
 
 This level of access, the “private to this submodule except to the select 
 set of interfaces I want to see it” level, is the equivalent of friend 
 classes in C++.  I don’t consider leaving this out to be a hole, nor is it 
 an "encapsulation-related problem” because at no point can you break the 
 API boundary and re-export anything here with a higher level of access 
 than it had previously.
>>> 
>>> By API boundary you mean the top-level module, right?
>>> 
 
> On Feb 21, 2017, at 11:13 PM, Matthew Johnson  > wrote:
> 
> 
>> On Feb 21, 2017, at 10:11 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:

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

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 10:41 PM, Robert Widmann  wrote:
> 
> By API boundaries I mean both the one internal to MyModule.Foo and the one 
> defined by MyModule.  Here “the API boundary” is explicitly about the 
> submodule MyModule.Foo, whose internal state may have been “unsealed” in the 
> top level by the extension, but has not been re-exported.

I’m sorry, but I just don’t understand how modules form an API boundary in this 
system.  To me a boundary means something that blocks access.  In this system 
`internal` ranges over the entire module and all submodules.  The only 
boundaries I can see besides the module itself are files and lexical scopes 
(with `fileprivate` and `private`).  

This means that it is trivial to put code anywhere within the module that 
extends the submodule and wraps a symbol in a new name and declares it 
`public`.  They can also trivially add a `public import MyModule.Foo` anywhere 
at the top level of their file because every file is forced to include top 
level scope.

In my opinion, we need to identify what goals we have for a submodule system - 
what problems are we trying to solve and what use cases do we intend to enable. 
 

There are quite a few of us who want the ability to form solid API boundaries 
inside a module and view this as one of the fundamental features of a submodule 
system.  It’s reasonable to ask why we view this capability as essential.

I can’t speak for anyone else, but here are a few reasons why it’s important to 
me:

* Solid API boundaries are essential to good design.  
* Having access to an entire code base does not reduce the benefits of #1.  
Some code bases are substantial in size and hard boundaries are important to 
keeping them manageable.
* Using full-fledged modules to do this is possible, but also involves a bit of 
ceremony that is incidental, not essential complexity in many cases.  It would 
be better to have a lighter weight mechanism to do this.
* Swift currently only has whole module optimization, not whole program 
optimization.  There is a performance penalty to using full-fledged modules.

> 
> ~Robert Widmann
> 
>> On Feb 21, 2017, at 11:38 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On Feb 21, 2017, at 10:29 PM, Robert Widmann  
>>> wrote:
>>> 
>>> This level of access, the “private to this submodule except to the select 
>>> set of interfaces I want to see it” level, is the equivalent of friend 
>>> classes in C++.  I don’t consider leaving this out to be a hole, nor is it 
>>> an "encapsulation-related problem” because at no point can you break the 
>>> API boundary and re-export anything here with a higher level of access than 
>>> it had previously.
>> 
>> By API boundary you mean the top-level module, right?
>> 
>>> 
 On Feb 21, 2017, at 11:13 PM, Matthew Johnson  
 wrote:
 
 
> On Feb 21, 2017, at 10:11 PM, Matthew Johnson  
> wrote:
> 
> 
>> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  
>>> wrote:
>>> 
>>> Correct.  Because, in dividing the submodule across an extension, you 
>>> have placed what should be a private API into a differently-scoped 
>>> location.
>> 
>> Okay. So is your submodule design not intended to address the "I want to 
>> encapsulate implementation details so they're only visible to several 
>> units of code in different files, but not the entire module" use case? 
>> Because if there's no way to scope a symbol to "everything inside this 
>> submodule, but nothing outside this submodule", I think it leaves that 
>> use case unserved.
> 
> Unless I’m missing something there is also another encapsulation-related 
> problem with the proposed design.  Let’s suppose for the sake of 
> discussion there was a `submoduleprivate` access modifier (intentionally 
> ungainly and not realistic).
> 
> // File 1
> module Foo {
> // internal, visible to the whole module
> class Bar { submoduleprivate var protectedState: Int = 0 }
> }
> 
> // File 2 - Has nothing to do with Foo at all
> import MyModule.Foo
> 
> module NotFoo {
> // Hey, I need to see Bar.protectedState!!!
> func totallyNotFoo() {
>   var bar = Bar()
>   bar.foosExposedPrivates = 42
> }
> }
> 
> // ok, I’ll just add an extension to Foo so I can see submoduleprivate 
> and wrap what I need
> module Foo {
 
 Oops, this should have been `extension Foo`, but otherwise I believe it is 
 valid under this proposal.
 
> // Hey, I’ll be nice and keep it fileprivate, but I could make it public 
> if I wanted to.
> extension Foo {
> fileprivate var foosExposedPrivates: 

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

[Robert Widmann via swift-evolution]

Then let’s discuss that.

You claim Swift has some emphasis on file-oriented programming constructs, I 
argue this is the case locally (fileprivate), but not the case in the language 
as a whole.  Looking more broadly, it is possible to restrict yourself to a 
particular view where one public type resides in one file, but then what to 
make of extensions?  What becomes of “internal” access, which permeates the 
entire module crossing over any file boundaries that might exist?  Today, a 
Swift module can depend on the kinds of files given to the compiler, but there 
is particular emphasis on a module not necessarily being a collection of files, 
but a collection of interfaces all living under the same shared namespace (the 
module name).  A particular facet of that interface set may be freely extended 
by the presence, or contracted by the absence, of a file or files when the 
module is built but one could very well imagine alternative abstractions that 
would serve this purpose just as well - e.g. an in-memory AST.

Maybe what you notice is that you are encouraged (or rather, required) by your 
tools to organize your code a particular way, and this is no mistake.  They 
exist apart from the language itself for a reason, because they themselves 
often depend on the state of the filesystem or the outside world and that 
concern spills over (correctly or not) into your organizational style.  But 
organizational style is just that: we can enable a broader class of programs to 
be designed with the system given here than with one that restricts us to a 
subset of it.  Because let’s not forget, it is actually a subset of the 
functionality presented herein.  If the proposal’s were implemented today, you 
would absolutely be able to design these kinds of modules and tie them to 
filesystem locations.  But you would also be free to group functionality and 
tie a set of files together into the same (sub)module.

> On Feb 21, 2017, at 10:46 PM, Xiaodi Wu  wrote:
> 
> Well put. As for me, it is not the syntactic delta with which I am concerned. 
> It is just a canary for the organizational delta.
> 
> There are certain freedoms enabled not by the _lack_ of constraints but 
> rather their judicious application. Swift has in the past--and it is your 
> burden to justify why it shouldn't continue to in the future--judged the 
> file-based approach to be one such judicious constraint.
> 
> 
> On Tue, Feb 21, 2017 at 21:42 Robert Widmann  > wrote:
>> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
 
 On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > wrote:
 
 On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann >wrote:
 
> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  > wrote:
> 
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann  >wrote:
> 
>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via 
>>> swift-evolution >> > wrote:
>>> 
>>> To my mind, any submodule system for Swift should be designed to 
>>> relieve the pressure for long files, and make it easy to group tightly 
>>> related files into a single unit with shared visibility. That way 
>>> developers can easily organize their code into smaller files while 
>>> utilizing Swift’s pattern of providing protocol conformances in 
>>> extensions and keeping implementation details hidden from the rest of 
>>> the module at large.
>>> 
>> 
>> Wonderful, because that’s absolutely supported by this proposal.  To 
>> group tightly related files into a single unit, simply declare a 
>> submodule for them and extend it in each of your related files.
>> 
>> It's supported, but it isn't first-class. By this I mean: there are two 
>> distinguishable uses supported by your proposal, lumped together by the 
>> fact that they are both about grouping units of code together. Put 
>> crudely, one use case is grouping lines of code, while the other is 
>> about grouping files of code. The merits of supporting both have already 
>> been debated in this discussion. The issue I'll touch on is supporting 

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

[Chris Lattner via swift-evolution]

On Feb 20, 2017, at 11:12 PM, John McCall  wrote:
>> 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.

Yeah, I agree that it will be appealing to people who don’t know better, but 
here’s the thing: the (almost certain) Swift design will prevent the bad thing 
from happening in practice.

Consider the barriers Swift already puts in place to prevent the bad thing 
(declaring an inappropriately narrow explicitly-specified throw signature) from 
happening:

1) First of all, you need to declare a public API.  If it isn’t public, then 
there is no concern at all, you can evolve the implementation and clients 
together.

2) The Second problem depends on the number of errors it can throw.  If there 
is exactly one type of error, the most common way to handle it is by returning 
optional.  If you have one obvious failure mode with a value, then you throw 
that value.  The most common case is where you can throw more than one sort of 
error, and therefore have an enum to describe it.

3) Third, your enum needs to be declared fragile in order to allow clients to 
enumerate their cases specifically.

The third step (having to mark your enum fragile, however it is spelled) is the 
biggest sign that you’re opting into a commitment that you should think really 
hard about.  If folks don’t know that this is a big API commitment, then we 
have bigger problems.


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

Agreed.

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

Proposed solution:  ABI is that the callee takes in a register which is either 
a buffer address to fill in or null.  On error, the callee returns the error 
pointer in a specific register.  If there was a buffer passed in, it uses it, 
otherwise it allocates.

In practice, this allows the compiler to only pre-allocate the buffer when it 
knows the fixed size, otherwise the caller allocates on the heap on demand.

AFAICT, the cost of this API is only a “li rN, 0” in the normal path.

-Chris

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

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

[Xiaodi Wu via swift-evolution]

Sign, perhaps, can be thought of as "part of a number," but signum refers
to the signum function (http://en.wikipedia.org/wiki/Sign_function) defined
as:

-1 if x < 0
0 if x = 0
1 if x > 0

1 isn't really "part of" 42, for instance, at least not in the sense that
42 and + are "part of" 42.
On Tue, Feb 21, 2017 at 22:18 Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> You raised two points:
>
>   1. "... magnitude is something the number ‘has’ whereas signum is a
> completely new thing ..." I think sign is as much part of a number as
> magnitude. Its a minor point, code complete gets it anyway.
>
>   2. "... [extras] are defined as protocol extensions, therefore they
> should be discoverable through completion ..." I wasn't thinking so much
> about code completion, more browsing the protocol to see what is available
> (I use SwiftDoc quite a bit).
>
> Thanks for running with this - very valuable,
>
>   -- Howard.
>
> On 22 February 2017 at 10:27, Max Moiseev  wrote:
>
>
> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes
>
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> 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] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

By API boundaries I mean both the one internal to MyModule.Foo and the one 
defined by MyModule.  Here “the API boundary” is explicitly about the submodule 
MyModule.Foo, whose internal state may have been “unsealed” in the top level by 
the extension, but has not been re-exported.

~Robert Widmann

> On Feb 21, 2017, at 11:38 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 21, 2017, at 10:29 PM, Robert Widmann  
>> wrote:
>> 
>> This level of access, the “private to this submodule except to the select 
>> set of interfaces I want to see it” level, is the equivalent of friend 
>> classes in C++.  I don’t consider leaving this out to be a hole, nor is it 
>> an "encapsulation-related problem” because at no point can you break the API 
>> boundary and re-export anything here with a higher level of access than it 
>> had previously.
> 
> By API boundary you mean the top-level module, right?
> 
>> 
>>> On Feb 21, 2017, at 11:13 PM, Matthew Johnson  
>>> wrote:
>>> 
>>> 
 On Feb 21, 2017, at 10:11 PM, Matthew Johnson  
 wrote:
 
 
> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  
>> wrote:
>> 
>> Correct.  Because, in dividing the submodule across an extension, you 
>> have placed what should be a private API into a differently-scoped 
>> location.
> 
> Okay. So is your submodule design not intended to address the "I want to 
> encapsulate implementation details so they're only visible to several 
> units of code in different files, but not the entire module" use case? 
> Because if there's no way to scope a symbol to "everything inside this 
> submodule, but nothing outside this submodule", I think it leaves that 
> use case unserved.
 
 Unless I’m missing something there is also another encapsulation-related 
 problem with the proposed design.  Let’s suppose for the sake of 
 discussion there was a `submoduleprivate` access modifier (intentionally 
 ungainly and not realistic).
 
 // File 1
 module Foo {
 // internal, visible to the whole module
 class Bar { submoduleprivate var protectedState: Int = 0 }
 }
 
 // File 2 - Has nothing to do with Foo at all
 import MyModule.Foo
 
 module NotFoo {
 // Hey, I need to see Bar.protectedState!!!
 func totallyNotFoo() {
var bar = Bar()
bar.foosExposedPrivates = 42
 }
 }
 
 // ok, I’ll just add an extension to Foo so I can see submoduleprivate and 
 wrap what I need
 module Foo {
>>> 
>>> Oops, this should have been `extension Foo`, but otherwise I believe it is 
>>> valid under this proposal.
>>> 
 // Hey, I’ll be nice and keep it fileprivate, but I could make it public 
 if I wanted to.
 extension Foo {
  fileprivate var foosExposedPrivates: Int {
 // Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
 get { return protectedState }
 set  { protectedState = newValue }
  }
 }
 }
 
> 
> -- 
> 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] [Proposal][Discussion] Modular Swift

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 10:29 PM, Robert Widmann  wrote:
> 
> This level of access, the “private to this submodule except to the select set 
> of interfaces I want to see it” level, is the equivalent of friend classes in 
> C++.  I don’t consider leaving this out to be a hole, nor is it an 
> "encapsulation-related problem” because at no point can you break the API 
> boundary and re-export anything here with a higher level of access than it 
> had previously.

By API boundary you mean the top-level module, right?

> 
>> On Feb 21, 2017, at 11:13 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On Feb 21, 2017, at 10:11 PM, Matthew Johnson  
>>> wrote:
>>> 
>>> 
 On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
> On Feb 21, 2017, at 7:38 PM, Robert Widmann  
> wrote:
> 
> Correct.  Because, in dividing the submodule across an extension, you 
> have placed what should be a private API into a differently-scoped 
> location.
 
 Okay. So is your submodule design not intended to address the "I want to 
 encapsulate implementation details so they're only visible to several 
 units of code in different files, but not the entire module" use case? 
 Because if there's no way to scope a symbol to "everything inside this 
 submodule, but nothing outside this submodule", I think it leaves that use 
 case unserved.
>>> 
>>> Unless I’m missing something there is also another encapsulation-related 
>>> problem with the proposed design.  Let’s suppose for the sake of discussion 
>>> there was a `submoduleprivate` access modifier (intentionally ungainly and 
>>> not realistic).
>>> 
>>> // File 1
>>> module Foo {
>>>  // internal, visible to the whole module
>>>  class Bar { submoduleprivate var protectedState: Int = 0 }
>>> }
>>> 
>>> // File 2 - Has nothing to do with Foo at all
>>> import MyModule.Foo
>>> 
>>> module NotFoo {
>>> // Hey, I need to see Bar.protectedState!!!
>>> func totallyNotFoo() {
>>> var bar = Bar()
>>> bar.foosExposedPrivates = 42
>>> }
>>> }
>>> 
>>> // ok, I’ll just add an extension to Foo so I can see submoduleprivate and 
>>> wrap what I need
>>> module Foo {
>> 
>> Oops, this should have been `extension Foo`, but otherwise I believe it is 
>> valid under this proposal.
>> 
>>>  // Hey, I’ll be nice and keep it fileprivate, but I could make it public 
>>> if I wanted to.
>>>  extension Foo {
>>>   fileprivate var foosExposedPrivates: Int {
>>>  // Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
>>>  get { return protectedState }
>>>  set  { protectedState = newValue }
>>>   }
>>>  }
>>> }
>>> 
 
 -- 
 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] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

TJ and I had a proposal 
 that would 
have closed this loophole by overhauling qualified imports syntax.

> On Feb 21, 2017, at 11:36 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 21, 2017, at 10:25 PM, Robert Widmann > > wrote:
>> 
>> Good question!  This behavior is actually the behavior that exists today.  
>> For example, open a playground and type
>> 
>> import Foundation.NSDebug
>> 
>> let s : NSString = “"
>> 
>> You’ll notice no matter which submodule you try to visit (Darwin.uuid is 
>> another good example), Swift has decided to insert a top-level import.  We 
>> decided not to change this behavior to maintain source compatibility.
> 
> So there is no way to import a single submodule?  If that is the case why not 
> just disallow the syntax which implies only a single submodule is getting 
> imported and require users to say `import Foo`?  I don’t know what the 
> rationale was for this in the past, but I think it’s undesirable and we’re 
> trying to design something for the future here.
> 
>> 
>> 
>>> On Feb 21, 2017, at 11:21 PM, Matthew Johnson >> > wrote:
>>> 
 
 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

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

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 10:25 PM, Robert Widmann  wrote:
> 
> Good question!  This behavior is actually the behavior that exists today.  
> For example, open a playground and type
> 
> import Foundation.NSDebug
> 
> let s : NSString = “"
> 
> You’ll notice no matter which submodule you try to visit (Darwin.uuid is 
> another good example), Swift has decided to insert a top-level import.  We 
> decided not to change this behavior to maintain source compatibility.

So there is no way to import a single submodule?  If that is the case why not 
just disallow the syntax which implies only a single submodule is getting 
imported and require users to say `import Foo`?  I don’t know what the 
rationale was for this in the past, but I think it’s undesirable and we’re 
trying to design something for the future here.

> 
> 
>> On Feb 21, 2017, at 11:21 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> 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
>>>  
>>> 

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

[Matthew Johnson via swift-evolution]

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

Am I understanding this correctly?  It looks like ModKit.Foo.Bar cannot see or 
import any symbols declared in ModKit.Foo or ModKit.  Is that correct?  
Descendents cannot see or import symbols declared in ancestors (including 
public symbols) but they can import any submodule that is not their ancestor 
(and therefore see public symbols in any submodule that’s not an ancestor by 
way of importing that submodule)?  

I think I understand why you might have specified this design but am interested 
in hearing you elaborate a bit further on the rationale.

> 
> 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][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

This level of access, the “private to this submodule except to the select set 
of interfaces I want to see it” level, is the equivalent of friend classes in 
C++.  I don’t consider leaving this out to be a hole, nor is it an 
"encapsulation-related problem” because at no point can you break the API 
boundary and re-export anything here with a higher level of access than it had 
previously.

> On Feb 21, 2017, at 11:13 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 21, 2017, at 10:11 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
 On Feb 21, 2017, at 7:38 PM, Robert Widmann  
 wrote:
 
 Correct.  Because, in dividing the submodule across an extension, you have 
 placed what should be a private API into a differently-scoped location.
>>> 
>>> Okay. So is your submodule design not intended to address the "I want to 
>>> encapsulate implementation details so they're only visible to several units 
>>> of code in different files, but not the entire module" use case? Because if 
>>> there's no way to scope a symbol to "everything inside this submodule, but 
>>> nothing outside this submodule", I think it leaves that use case unserved.
>> 
>> Unless I’m missing something there is also another encapsulation-related 
>> problem with the proposed design.  Let’s suppose for the sake of discussion 
>> there was a `submoduleprivate` access modifier (intentionally ungainly and 
>> not realistic).
>> 
>> // File 1
>> module Foo {
>>   // internal, visible to the whole module
>>   class Bar { submoduleprivate var protectedState: Int = 0 }
>> }
>> 
>> // File 2 - Has nothing to do with Foo at all
>> import MyModule.Foo
>> 
>> module NotFoo {
>>  // Hey, I need to see Bar.protectedState!!!
>>  func totallyNotFoo() {
>>  var bar = Bar()
>>  bar.foosExposedPrivates = 42
>>  }
>> }
>> 
>> // ok, I’ll just add an extension to Foo so I can see submoduleprivate and 
>> wrap what I need
>> module Foo {
> 
> Oops, this should have been `extension Foo`, but otherwise I believe it is 
> valid under this proposal.
> 
>>   // Hey, I’ll be nice and keep it fileprivate, but I could make it public 
>> if I wanted to.
>>   extension Foo {
>>fileprivate var foosExposedPrivates: Int {
>>   // Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
>>   get { return protectedState }
>>   set  { protectedState = newValue }
>>}
>>   }
>> }
>> 
>>> 
>>> -- 
>>> 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] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

Good question!  This behavior is actually the behavior that exists today.  For 
example, open a playground and type

import Foundation.NSDebug

let s : NSString = “"

You’ll notice no matter which submodule you try to visit (Darwin.uuid is 
another good example), Swift has decided to insert a top-level import.  We 
decided not to change this behavior to maintain source compatibility.


> On Feb 21, 2017, at 11:21 PM, Matthew Johnson  wrote:
> 
>> 
>> 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 

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

[Matthew Johnson via swift-evolution]

> 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
I’ve read this a couple of times now and I keep getting hung up on this.  Is 
the comment a mistake?  I would only expect to get Foo.Bar.Baz here, not 
Foo.Bar or Foo itself.  If it’s not a mistake, why did you choose this behavior?


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

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

[Howard Lovatt via swift-evolution]

You raised two points:

  1. "... magnitude is something the number ‘has’ whereas signum is a
completely new thing ..." I think sign is as much part of a number as
magnitude. Its a minor point, code complete gets it anyway.

  2. "... [extras] are defined as protocol extensions, therefore they
should be discoverable through completion ..." I wasn't thinking so much
about code completion, more browsing the protocol to see what is available
(I use SwiftDoc quite a bit).

Thanks for running with this - very valuable,

  -- Howard.

On 22 February 2017 at 10:27, Max Moiseev  wrote:

>
> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>>
>> https://github.com/apple/swift-evolution/blob/master/
>> proposals/0104-improved-integers.md
>>
>>
>> • What is your evaluation of the proposal?
>>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
>> • Is the problem being addressed significant enough to warrant a change
>> to Swift?
>>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>>
>> • Does this proposal fit well with the feel and direction of Swift?
>>
>
> Yes
>
>>
>> • If you have used other languages or libraries with a similar feature,
>> how do you feel that this proposal compares to those?
>>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>>
>> • How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> 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

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 10:11 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  
>>> wrote:
>>> 
>>> Correct.  Because, in dividing the submodule across an extension, you have 
>>> placed what should be a private API into a differently-scoped location.
>> 
>> Okay. So is your submodule design not intended to address the "I want to 
>> encapsulate implementation details so they're only visible to several units 
>> of code in different files, but not the entire module" use case? Because if 
>> there's no way to scope a symbol to "everything inside this submodule, but 
>> nothing outside this submodule", I think it leaves that use case unserved.
> 
> Unless I’m missing something there is also another encapsulation-related 
> problem with the proposed design.  Let’s suppose for the sake of discussion 
> there was a `submoduleprivate` access modifier (intentionally ungainly and 
> not realistic).
> 
> // File 1
> module Foo {
>// internal, visible to the whole module
>class Bar { submoduleprivate var protectedState: Int = 0 }
> }
> 
> // File 2 - Has nothing to do with Foo at all
> import MyModule.Foo
> 
> module NotFoo {
>   // Hey, I need to see Bar.protectedState!!!
>   func totallyNotFoo() {
>   var bar = Bar()
>   bar.foosExposedPrivates = 42
>   }
> }
> 
> // ok, I’ll just add an extension to Foo so I can see submoduleprivate and 
> wrap what I need
> module Foo {

Oops, this should have been `extension Foo`, but otherwise I believe it is 
valid under this proposal.

>// Hey, I’ll be nice and keep it fileprivate, but I could make it public 
> if I wanted to.
>extension Bar {
> fileprivate var foosExposedPrivates: Int {
>// Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
>get { return protectedState }
>set  { protectedState = newValue }
> }
>}
> }
> 
>> 
>> -- 
>> 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] [Proposal][Discussion] Modular Swift

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 9:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  wrote:
>> 
>> Correct.  Because, in dividing the submodule across an extension, you have 
>> placed what should be a private API into a differently-scoped location.
> 
> Okay. So is your submodule design not intended to address the "I want to 
> encapsulate implementation details so they're only visible to several units 
> of code in different files, but not the entire module" use case? Because if 
> there's no way to scope a symbol to "everything inside this submodule, but 
> nothing outside this submodule", I think it leaves that use case unserved.

Unless I’m missing something there is also another encapsulation-related 
problem with the proposed design.  Let’s suppose for the sake of discussion 
there was a `submoduleprivate` access modifier (intentionally ungainly and not 
realistic).

// File 1
module Foo {
// internal, visible to the whole module
class Bar { submoduleprivate var protectedState: Int = 0 }
}

// File 2 - Has nothing to do with Foo at all
import MyModule.Foo

module NotFoo {
   // Hey, I need to see Bar.protectedState!!!
   func totallyNotFoo() {
   var bar = Bar()
   bar.foosExposedPrivates = 42
   }
}

// ok, I’ll just add an extension to Foo so I can see submoduleprivate and wrap 
what I need
module Foo {
// Hey, I’ll be nice and keep it fileprivate, but I could make it public if 
I wanted to.
extension Bar {
 fileprivate var foosExposedPrivates: Int {
// Yep, I’m inside Foo so I can see it’s submoduleprivate stuff
get { return protectedState }
set  { protectedState = newValue }
 }
}
}

> 
> -- 
> 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] [Proposal][Discussion] Modular Swift

[Daniel Duan via swift-evolution]

FWIW, I like the freedom of choice. A Java-like file-based solution can be 
limiting for *some* style of programming. It is, as Robert mentioned, geared 
towards benefit of the implementation. I also suspect ppl who are asking for 
file-based solution _now_ may find themselves wanting the alternative in the 
future. Point is, let’s support both and let ppl use a linter.

> On Feb 21, 2017, at 7:46 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Well put. As for me, it is not the syntactic delta with which I am concerned. 
> It is just a canary for the organizational delta.
> 
> There are certain freedoms enabled not by the _lack_ of constraints but 
> rather their judicious application. Swift has in the past--and it is your 
> burden to justify why it shouldn't continue to in the future--judged the 
> file-based approach to be one such judicious constraint.
> 
> 
> On Tue, Feb 21, 2017 at 21:42 Robert Widmann  > wrote:
>> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
 
 On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > wrote:
 
 On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann >wrote:
 
> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  > wrote:
> 
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann  >wrote:
> 
>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via 
>>> swift-evolution >> > wrote:
>>> 
>>> To my mind, any submodule system for Swift should be designed to 
>>> relieve the pressure for long files, and make it easy to group tightly 
>>> related files into a single unit with shared visibility. That way 
>>> developers can easily organize their code into smaller files while 
>>> utilizing Swift’s pattern of providing protocol conformances in 
>>> extensions and keeping implementation details hidden from the rest of 
>>> the module at large.
>>> 
>> 
>> Wonderful, because that’s absolutely supported by this proposal.  To 
>> group tightly related files into a single unit, simply declare a 
>> submodule for them and extend it in each of your related files.
>> 
>> It's supported, but it isn't first-class. By this I mean: there are two 
>> distinguishable uses supported by your proposal, lumped together by the 
>> fact that they are both about grouping units of code together. Put 
>> crudely, one use case is grouping lines of code, while the other is 
>> about grouping files of code. The merits of supporting both have already 
>> been debated in this discussion. The issue I'll touch on is supporting 
>> both with the same syntax. The chief drawbacks here are:
>> 
> 
> What exactly would be required to make it first class?  Referencing file 
> names in the module declaration?
> 
>  See below.
>> - It makes sense to use braces to group lines of code, but it makes no 
>> sense to use braces to group files of code; this just causes entire 
>> files to be indented.
>> 
> 
> If braces aren’t used to demarcate scopes, nesting modules becomes 
> ambiguous.
> 
> Again, let's observe the distinction about grouping files vs. grouping 
> lines.
> 
> Grouping files does not require braces: if the intended use of your 
> feature were to label files X, Y, and Z as belonging to one submodule and 
> A, B, and C to another, it would not matter if X, Y, and Z belonged to 
> Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require 
> braces.
>  
> It’s important to note that indentation is one particular style.  LLVM 
> code style, in particular, chooses not to indent after namespace 
> declarations.  This issue also crops up when dealing with nested type 
> declarations, and I distinctly remember it not being a big enough deal to 
> "fix this" at the time when a proposal to “flatten” these declaration was 
> brought up.
>  
> Mine is not a critique of the syntax itself; I don't particularly care 
> about indents, nor do I mind not indenting namespaces.
> 
> What I'm saying 

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

[Robert Widmann via swift-evolution]

Whoops, move bar() out of the utility and you get the actual answer here, 
because you want to be able to see this in foo()!

> On Feb 21, 2017, at 10:54 PM, Robert Widmann  wrote:
> 
> This case is unserved because it is anti-modular and a nightmare to maintain. 
>  The actual way to structure this is to factor bar() and baz() into their own 
> utility submodule, or even deeper if necessary, that has as a parent the 
> primary module that wishes to consume them both but not re-export them out to 
> the parent.  For example,
> 
> 
>   // foo.swift
>   import MyMod.Submodule
>   func foo() {
>   bar()
>   }
> 
>   // bar.swift
> 
>// Make my utilities visible in Foo.Submodule, but invisible to the 
> parent.
>import Foo.Submodule.UtilitySubmodule
> 
>   module Submodule {
>   module UtilitySubmodule  {
>   internal func bar() {
>   baz()
> }
>   }
>   }
> 
>   // baz.swift
>   extension Submodule.UtilitySubmodule {  
>   internal func baz() {
>   …
>   }
>   }
> 
> The thought is that it should be as cheap to create submodules to organize 
> interfaces under as it is to create new directories to organize code under.
> 
> Though, this example is a little odd given that you’re defining and importing 
> the same utility submodule.  Really, what you would want to do is declare the 
> utility in its own file/files outside of bar.swift to really take full 
> advantage of the separation afforded here, then consume it internally with 
> the import as written here.
> 
>> On Feb 21, 2017, at 10:47 PM, Brent Royal-Gordon  
>> wrote:
>> 
>>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  
>>> wrote:
>>> 
>>> Correct.  Because, in dividing the submodule across an extension, you have 
>>> placed what should be a private API into a differently-scoped location.
>> 
>> Okay. So is your submodule design not intended to address the "I want to 
>> encapsulate implementation details so they're only visible to several units 
>> of code in different files, but not the entire module" use case? Because if 
>> there's no way to scope a symbol to "everything inside this submodule, but 
>> nothing outside this submodule", I think it leaves that use case unserved.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 

___
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 case is unserved because it is anti-modular and a nightmare to maintain.  
The actual way to structure this is to factor bar() and baz() into their own 
utility submodule, or even deeper if necessary, that has as a parent the 
primary module that wishes to consume them both but not re-export them out to 
the parent.  For example,


// foo.swift
import MyMod.Submodule
func foo() {
bar()
}

// bar.swift

// Make my utilities visible in Foo.Submodule, but invisible to the 
parent.
import Foo.Submodule.UtilitySubmodule

module Submodule {
module UtilitySubmodule  {
   internal func bar() {
baz()
  }
   }
}

// baz.swift
extension Submodule.UtilitySubmodule {  
internal func baz() {
…
}
}

The thought is that it should be as cheap to create submodules to organize 
interfaces under as it is to create new directories to organize code under.

Though, this example is a little odd given that you’re defining and importing 
the same utility submodule.  Really, what you would want to do is declare the 
utility in its own file/files outside of bar.swift to really take full 
advantage of the separation afforded here, then consume it internally with the 
import as written here.

> On Feb 21, 2017, at 10:47 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 21, 2017, at 7:38 PM, Robert Widmann  wrote:
>> 
>> Correct.  Because, in dividing the submodule across an extension, you have 
>> placed what should be a private API into a differently-scoped location.
> 
> Okay. So is your submodule design not intended to address the "I want to 
> encapsulate implementation details so they're only visible to several units 
> of code in different files, but not the entire module" use case? Because if 
> there's no way to scope a symbol to "everything inside this submodule, but 
> nothing outside this submodule", I think it leaves that use case unserved.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

> On Feb 21, 2017, at 9:42 PM, Robert Widmann  wrote:
> 
> 
>> On Feb 21, 2017, at 10:36 PM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
 
 On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > wrote:
 
 On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann >wrote:
 
> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  > wrote:
> 
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann  >wrote:
> 
>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via 
>>> swift-evolution >> > wrote:
>>> 
>>> To my mind, any submodule system for Swift should be designed to 
>>> relieve the pressure for long files, and make it easy to group tightly 
>>> related files into a single unit with shared visibility. That way 
>>> developers can easily organize their code into smaller files while 
>>> utilizing Swift’s pattern of providing protocol conformances in 
>>> extensions and keeping implementation details hidden from the rest of 
>>> the module at large.
>>> 
>> 
>> Wonderful, because that’s absolutely supported by this proposal.  To 
>> group tightly related files into a single unit, simply declare a 
>> submodule for them and extend it in each of your related files.
>> 
>> It's supported, but it isn't first-class. By this I mean: there are two 
>> distinguishable uses supported by your proposal, lumped together by the 
>> fact that they are both about grouping units of code together. Put 
>> crudely, one use case is grouping lines of code, while the other is 
>> about grouping files of code. The merits of supporting both have already 
>> been debated in this discussion. The issue I'll touch on is supporting 
>> both with the same syntax. The chief drawbacks here are:
>> 
> 
> What exactly would be required to make it first class?  Referencing file 
> names in the module declaration?
> 
>  See below.
>> - It makes sense to use braces to group lines of code, but it makes no 
>> sense to use braces to group files of code; this just causes entire 
>> files to be indented.
>> 
> 
> If braces aren’t used to demarcate scopes, nesting modules becomes 
> ambiguous.
> 
> Again, let's observe the distinction about grouping files vs. grouping 
> lines.
> 
> Grouping files does not require braces: if the intended use of your 
> feature were to label files X, Y, and Z as belonging to one submodule and 
> A, B, and C to another, it would not matter if X, Y, and Z belonged to 
> Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require 
> braces.
>  
> It’s important to note that indentation is one particular style.  LLVM 
> code style, in particular, chooses not to indent after namespace 
> declarations.  This issue also crops up when dealing with nested type 
> declarations, and I distinctly remember it not being a big enough deal to 
> "fix this" at the time when a proposal to “flatten” these declaration was 
> brought up.
>  
> Mine is not a critique of the syntax itself; I don't particularly care 
> about indents, nor do I mind not indenting namespaces.
> 
> What I'm saying is, you would not have chosen to require braces if your 
> proposed feature were aimed at making the grouping of files into 
> submodules as simple as possible. You chose to accommodate grouping lines 
> using the same syntax as grouping files over the simplest design for 
> grouping files. Make no mistake, this promotes one use over another.
 
 Ah, I see.  Yes, one of the stated goals is to become 
 filesystem-independent.  We certainly cannot do that by encouraging the 
 alternative.
  
 Swift's current design is deliberately not file system-independent. A 
 submodule design built on top of Swift could preserve that. Your draft 
 proposal makes two changes: it introduces a design for submodules; and, it 
 eliminates files as a unit of code by default (not least by declaring 
 `fileprivate` redundant). To my mind, you have presented no justification 
 for the 

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 21, 2017, at 7:38 PM, Robert Widmann  wrote:
> 
> Correct.  Because, in dividing the submodule across an extension, you have 
> placed what should be a private API into a differently-scoped location.

Okay. So is your submodule design not intended to address the "I want to 
encapsulate implementation details so they're only visible to several units of 
code in different files, but not the entire module" use case? Because if 
there's no way to scope a symbol to "everything inside this submodule, but 
nothing outside this submodule", I think it leaves that use case unserved.

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

Well put. As for me, it is not the syntactic delta with which I am
concerned. It is just a canary for the organizational delta.

There are certain freedoms enabled not by the _lack_ of constraints but
rather their judicious application. Swift has in the past--and it is your
burden to justify why it shouldn't continue to in the future--judged the
file-based approach to be one such judicious constraint.


On Tue, Feb 21, 2017 at 21:42 Robert Widmann 
wrote:

> On Feb 21, 2017, at 10:36 PM, Matthew Johnson 
> wrote:
>
>
> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann 
> wrote:
>
>
> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann 
> wrote:
>
>
> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To my mind, any submodule system for Swift should be designed to relieve
> the pressure for long files, and make it easy to group tightly related
> files into a single unit with shared visibility. That way developers can
> easily organize their code into smaller files while utilizing Swift’s
> pattern of providing protocol conformances in extensions and keeping
> implementation details hidden from the rest of the module at large.
>
>
> Wonderful, because that’s absolutely supported by this proposal.  To group
> tightly related files into a single unit, simply declare a submodule for
> them and extend it in each of your related files.
>
>
> It's supported, but it isn't first-class. By this I mean: there are two
> distinguishable uses supported by your proposal, lumped together by the
> fact that they are both about grouping units of code together. Put crudely,
> one use case is grouping lines of code, while the other is about grouping
> files of code. The merits of supporting both have already been debated in
> this discussion. The issue I'll touch on is supporting both with the same
> syntax. The chief drawbacks here are:
>
>
> What exactly would be required to *make* it first class?  Referencing
> file names in the module declaration?
>
>
>  See below.
>
> - It makes sense to use braces to group lines of code, but it makes no
> sense to use braces to group files of code; this just causes entire files
> to be indented.
>
>
> If braces aren’t used to demarcate scopes, nesting modules becomes
> ambiguous.
>
>
> Again, let's observe the distinction about grouping files vs. grouping
> lines.
>
> Grouping files does not require braces: if the intended use of your
> feature were to label files X, Y, and Z as belonging to one submodule and
> A, B, and C to another, it would not matter if X, Y, and Z belonged to
> Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require
> braces.
>
>
> It’s important to note that indentation is one particular style.  LLVM
> code style, in particular, chooses not to indent after namespace
> declarations.  This issue also crops up when dealing with nested type
> declarations, and I distinctly remember it not being a big enough deal to
> "fix this" at the time when a proposal to “flatten” these declaration was
> brought up.
>
>
> Mine is not a critique of the syntax itself; I don't particularly care
> about indents, nor do I mind not indenting namespaces.
>
> What I'm saying is, you would not have chosen to require braces if your
> proposed feature were aimed at making the grouping of files into submodules
> as simple as possible. You chose to accommodate grouping lines using the
> same syntax as grouping files over the simplest design for grouping files.
> Make no mistake, this promotes one use over another.
>
>
> Ah, I see.  Yes, one of the stated goals is to become
> filesystem-independent.  We certainly cannot do that by encouraging the
> alternative.
>
>
> Swift's current design is deliberately not file system-independent. A
> submodule design built on top of Swift could preserve that. Your draft
> proposal makes two changes: it introduces a design for submodules; and, it
> eliminates files as a unit of code by default (not least by declaring
> `fileprivate` redundant). To my mind, you have presented no justification
> for the second change other than to say that it is a stated goal--but why?
>
>
>
>
>
>- fileprivate access can be recreated by creating a private "utility
>submodule" containing declarations of at most internal access.
>
>
>
>
> - Because some lines of code necessarily precede some other lines of code,
> it makes sense to declare the first group using `module` 

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

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 9:38 PM, Michel Fortin  wrote:
> 
>> Le 21 févr. 2017 à 22:05, Matthew Johnson  a écrit :
>> 
 Le 20 févr. 2017 à 12:17, Matthew Johnson  a écrit 
 :
 
> e) Generic Containers:
> Generic containers that impose requirements on their elements will pose 
> some additional problems, for instance: `Set.insert` needs to call 
> `hashValue` and `==` on its elements, making the purity of `Set.insert` 
> constrained by the purity of those functions. Without a way to express 
> this kind of conditional purity, `Set` and `Dictionary` cannot be pure.
 
 Could we use a mechanism similar to `rethrows` to address this kind of 
 transitive purity?  We have already discussed something along those lines 
 for handling functions passed as arguments.  Maybe that mechanism could be 
 designed to handle this use case as well.
>>> 
>>> Similar, yes. But more complicated too. In pseudo code, this is what you'd 
>>> have to express for `Set.insert`:
>>> 
>>> pure(where: Element.hashValue is pure, Element.== is pure)
>>> func insert(_ element: Element) { ... }
>>> 
>>> Then the compiler can enforce that `insert` only does things that are 
>>> allowed in a pure function, but can ignore the purity of Element.hashValue 
>>> and Element.== because the caller will check for that that.
>> 
>> Yep, that’s the kind of thing I had in mind.
>> 
>> I can imagine being this explicit could get pretty cumbersome though.  I 
>> wonder if there is a way to streamline this.  For example, in this case if 
>> we could just talk about `Element`’s conformance to `Hashable` and we could 
>> talk about a `pure` conformance (all requirements are met with pure 
>> implementations) then we could just say something like this:
>> 
>> pure(Element.Hashable)
>> func insert(_ element: Element) { ... }
>> 
>> Note: I also removed some redundancies - we could just say that the 
>> parameters are a list of things the purity of which `insert`’s purity 
>> depends.
>> 
>> For function arguments it would look something like this:
>> 
>> pure(transform)
>> func map(transform: Element -> T)
> 
> The approach is interesting and less heavy than my pseudo code example. The 
> syntax with protocols is a bit off though. What does `Element.Hashable` mean 
> in Swift? It refers to a member inside of `Element`, not a conformance of 
> `Element` to the `Hashable` protocol. I don't think there is any syntax to 
> refer to a conformance of a certain type to a protocol in Swift. The closest 
> is a check for the existence of a conformance for generic arguments.

Right, this was pseudo code and I just used the first syntax for referencing a 
conformance that came to mind.  We would obviously need to do a solid round of 
design of the real syntax.  I was mostly trying to show an approach we might be 
able to sue keep the annotations manageable.

> 
> But I'd tend to gravitate towards your last example, which is simpler: just 
> provide a path to the function that must be pure. Ideally you would be able 
> do it like this:
> 
>   pure(Element.hashValue, Element.==)
> 
> Unfortunately, it's hard (impossible?) currently to represent the getter of a 
> property or to get the function associated with an operator like ==, so this 
> is a bit ad-hoc. (Try to assign the function to a variable to see what I 
> mean.) There's still some general language improvements required to make this 
> work.
> 
> If you want another syntax requiring all functions in a protocol conformance 
> to be pure, that's an additive thing. I'm not sure it's worth its weight 
> though.

Yeah, it’s hard to say.  I just feel like referencing individual functions and 
properties is going to be a significant burden in some cases.  I’m trying to 
think of how we might be able to keep it under control.  If we can’t then 
people won’t want to bother with the annotation even when their function should 
be pure.

> 
> I do agree that it's cumbersome to have these complicated annotations. We 
> could imitate D and have generic functions infer their purity automatically, 
> but that wouldn't work well in a language like Swift where generic code can 
> be opaque. Instead, perhaps the compiler could automatically suggest what to 
> add when it detects some requirements are missing in a pure function.

I think it’s worth investing effort into trying to find a way to avoid 
burdensome annotations rather than having the compiler generate the boilerplate 
for us.

> 
> 
> -- 
> 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][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 10:36 PM, Matthew Johnson  wrote:
> 
>> 
>> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann >> >wrote:
>>> 
 On Feb 21, 2017, at 9:37 PM, Xiaodi Wu > wrote:
 
 On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann >wrote:
 
> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  > wrote:
> 
> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> 
>> To my mind, any submodule system for Swift should be designed to relieve 
>> the pressure for long files, and make it easy to group tightly related 
>> files into a single unit with shared visibility. That way developers can 
>> easily organize their code into smaller files while utilizing Swift’s 
>> pattern of providing protocol conformances in extensions and keeping 
>> implementation details hidden from the rest of the module at large.
>> 
> 
> Wonderful, because that’s absolutely supported by this proposal.  To 
> group tightly related files into a single unit, simply declare a 
> submodule for them and extend it in each of your related files.
> 
> It's supported, but it isn't first-class. By this I mean: there are two 
> distinguishable uses supported by your proposal, lumped together by the 
> fact that they are both about grouping units of code together. Put 
> crudely, one use case is grouping lines of code, while the other is about 
> grouping files of code. The merits of supporting both have already been 
> debated in this discussion. The issue I'll touch on is supporting both 
> with the same syntax. The chief drawbacks here are:
> 
 
 What exactly would be required to make it first class?  Referencing file 
 names in the module declaration?
 
  See below.
> - It makes sense to use braces to group lines of code, but it makes no 
> sense to use braces to group files of code; this just causes entire files 
> to be indented.
> 
 
 If braces aren’t used to demarcate scopes, nesting modules becomes 
 ambiguous.
 
 Again, let's observe the distinction about grouping files vs. grouping 
 lines.
 
 Grouping files does not require braces: if the intended use of your 
 feature were to label files X, Y, and Z as belonging to one submodule and 
 A, B, and C to another, it would not matter if X, Y, and Z belonged to 
 Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require 
 braces.
  
 It’s important to note that indentation is one particular style.  LLVM 
 code style, in particular, chooses not to indent after namespace 
 declarations.  This issue also crops up when dealing with nested type 
 declarations, and I distinctly remember it not being a big enough deal to 
 "fix this" at the time when a proposal to “flatten” these declaration was 
 brought up.
  
 Mine is not a critique of the syntax itself; I don't particularly care 
 about indents, nor do I mind not indenting namespaces.
 
 What I'm saying is, you would not have chosen to require braces if your 
 proposed feature were aimed at making the grouping of files into 
 submodules as simple as possible. You chose to accommodate grouping lines 
 using the same syntax as grouping files over the simplest design for 
 grouping files. Make no mistake, this promotes one use over another.
>>> 
>>> Ah, I see.  Yes, one of the stated goals is to become 
>>> filesystem-independent.  We certainly cannot do that by encouraging the 
>>> alternative.
>>>  
>>> Swift's current design is deliberately not file system-independent. A 
>>> submodule design built on top of Swift could preserve that. Your draft 
>>> proposal makes two changes: it introduces a design for submodules; and, it 
>>> eliminates files as a unit of code by default (not least by declaring 
>>> `fileprivate` redundant). To my mind, you have presented no justification 
>>> for the second change other than to say that it is a stated goal--but why?
>> 
>> 
>> 
>> fileprivate access can be recreated by creating a private "utility 
>> submodule" containing declarations of at most internal access.
>> 
>> 
 
> - 

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

[Michel Fortin via swift-evolution]

> Le 21 févr. 2017 à 22:05, Matthew Johnson  a écrit :
> 
>>> Le 20 févr. 2017 à 12:17, Matthew Johnson  a écrit :
>>> 
 e) Generic Containers:
 Generic containers that impose requirements on their elements will pose 
 some additional problems, for instance: `Set.insert` needs to call 
 `hashValue` and `==` on its elements, making the purity of `Set.insert` 
 constrained by the purity of those functions. Without a way to express 
 this kind of conditional purity, `Set` and `Dictionary` cannot be pure.
>>> 
>>> Could we use a mechanism similar to `rethrows` to address this kind of 
>>> transitive purity?  We have already discussed something along those lines 
>>> for handling functions passed as arguments.  Maybe that mechanism could be 
>>> designed to handle this use case as well.
>> 
>> Similar, yes. But more complicated too. In pseudo code, this is what you'd 
>> have to express for `Set.insert`:
>> 
>>  pure(where: Element.hashValue is pure, Element.== is pure)
>>  func insert(_ element: Element) { ... }
>> 
>> Then the compiler can enforce that `insert` only does things that are 
>> allowed in a pure function, but can ignore the purity of Element.hashValue 
>> and Element.== because the caller will check for that that.
> 
> Yep, that’s the kind of thing I had in mind.
> 
> I can imagine being this explicit could get pretty cumbersome though.  I 
> wonder if there is a way to streamline this.  For example, in this case if we 
> could just talk about `Element`’s conformance to `Hashable` and we could talk 
> about a `pure` conformance (all requirements are met with pure 
> implementations) then we could just say something like this:
> 
> pure(Element.Hashable)
> func insert(_ element: Element) { ... }
> 
> Note: I also removed some redundancies - we could just say that the 
> parameters are a list of things the purity of which `insert`’s purity depends.
> 
> For function arguments it would look something like this:
> 
> pure(transform)
> func map(transform: Element -> T)

The approach is interesting and less heavy than my pseudo code example. The 
syntax with protocols is a bit off though. What does `Element.Hashable` mean in 
Swift? It refers to a member inside of `Element`, not a conformance of 
`Element` to the `Hashable` protocol. I don't think there is any syntax to 
refer to a conformance of a certain type to a protocol in Swift. The closest is 
a check for the existence of a conformance for generic arguments.

But I'd tend to gravitate towards your last example, which is simpler: just 
provide a path to the function that must be pure. Ideally you would be able do 
it like this:

pure(Element.hashValue, Element.==)

Unfortunately, it's hard (impossible?) currently to represent the getter of a 
property or to get the function associated with an operator like ==, so this is 
a bit ad-hoc. (Try to assign the function to a variable to see what I mean.) 
There's still some general language improvements required to make this work.

If you want another syntax requiring all functions in a protocol conformance to 
be pure, that's an additive thing. I'm not sure it's worth its weight though.

I do agree that it's cumbersome to have these complicated annotations. We could 
imitate D and have generic functions infer their purity automatically, but that 
wouldn't work well in a language like Swift where generic code can be opaque. 
Instead, perhaps the compiler could automatically suggest what to add when it 
detects some requirements are missing in a pure 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] [Proposal][Discussion] Modular Swift

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 9:34 PM, Robert Widmann 
wrote:

> Let’s use some code to illustrate things.
>
> // FooUtilities.swift
> //
> // -module-name=Foo
> // module Foo {
> // Defines Foo.Utilities
> module Utilities {
>   internal func visibleInThisSubmodule() {}
> }
> //}
>
> // FooUtilities+MoreUtilities.swift
> extension Foo.Utilities {
>   private func privateHelper() {
> visibleInThisSubmodule()
>   }
> }
>

Either I'm entirely misunderstanding what you're trying to illustrate, or
this is totally unresponsive to Brent's question. In either case, I'll let
Brent ask his own question from here.


On Feb 21, 2017, at 10:31 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 9:29 PM, Robert Widmann 
> wrote:
>
>> Once again, internal is your keyword.  An extension allows you to “open
>> and expand” the module boundary here, which is exactly what you want here -
>> to extend this module across file boundaries without showing your cards to
>> an external consumer of your framework.
>>
>
> Sorry, I don't understand. Does your design support the use case below? I
> don't think it does. Are you replying that supporting the use case below is
> not a goal of your proposal? If so, please just say so.
>
>
> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Sorry, been replying to multiple sub-threads today.
>>>
>>>
>>> For bar(), because you wish to be able to
>>>
>>> 1) Not export it across the outermost module boundary
>>> 2) But still use it internally
>>>
>>> Internal access is required.  Any higher and you would export (violating
>>> 1), any lower and you wouldn’t be able to internally import (violating 2).
>>>
>>> For baz(), because you wish to be able to
>>>
>>> 1) Not export it across the outermost module boundary,
>>> 2) Or even your own internal submodule boundary
>>>
>>
>> 3) But still use it within the same submodule, across different file
>> boundaries: this is the feature that many people have stated they want to
>> emerge out of a submodule design.
>>
>> Private or fileprivate suffices depending on the scoping you wish for it
>>> to have within the file/interface it’s a part of relative to the other APIs
>>> in the submodule.
>>>
>>> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon <
>>> br...@architechies.com> wrote:
>>> >
>>> > I specified two different behaviors for `bar()` and `baz()`. I see now
>>> that you describe `internal` as having the behavior I want for `bar()`. Is
>>> there a way I can get the behavior I want for `baz()`?
>>> >
>>> > --
>>> > Brent Royal-Gordon
>>> > Sent from my iPhone
>>> >
>>> > On Feb 21, 2017, at 6:51 PM, Robert Widmann 
>>> wrote:
>>> >
>>> >>> What access modifiers do I put on `bar()` and `baz()` so that
>>> `MyMod` can access `bar()` but not `baz()`, and code outside `MyMod` can
>>> access neither `bar()` nor `baz()`?
>>> >>>
>>> >>
>>> >> internal
>>>
>>> ___
>>> 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

[Robert Widmann via swift-evolution]

Correct.  Because, in dividing the submodule across an extension, you have 
placed what should be a private API into a differently-scoped location.

> On Feb 21, 2017, at 10:34 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 21, 2017, at 7:14 PM, Robert Widmann  wrote:
>> 
>> Fileprivate and private are not changing at all.  Their meaning now extends 
>> from “private to this file” and “private to this declaration” respectively 
>> to those meanings plus “unexportable across any module boundary”.  One 
>> implication of this is it is now possible to create module-scoped private 
>> constants, functions, and data structures, which is one of the use-cases 
>> that Daniel Duan mentioned earlier down in the thread.
> 
> So what you are saying is that, in my example:
> 
>   // foo.swift
>   import MyMod.Submodule
>   func foo() {
>   bar()
>   }
> 
>   // bar.swift
>   module Submodule {
>   internal func bar() {
>   baz()
>   }
>   }
> 
>   // baz.swift
>   extension Submodule {   
>   ??? func baz() {
>   …
>   }
>   }
> 
> There is nothing I can put in the `???` slot that will expose `baz()` to 
> `bar()`, but not to `foo()`. Correct?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

> On Feb 21, 2017, at 9:28 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann > >wrote:
>> 
>>> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann >> >wrote:
>>> 
 On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > wrote:
 
 On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
 > wrote:
 
> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
> > wrote:
> 
> To my mind, any submodule system for Swift should be designed to relieve 
> the pressure for long files, and make it easy to group tightly related 
> files into a single unit with shared visibility. That way developers can 
> easily organize their code into smaller files while utilizing Swift’s 
> pattern of providing protocol conformances in extensions and keeping 
> implementation details hidden from the rest of the module at large.
> 
 
 Wonderful, because that’s absolutely supported by this proposal.  To group 
 tightly related files into a single unit, simply declare a submodule for 
 them and extend it in each of your related files.
 
 It's supported, but it isn't first-class. By this I mean: there are two 
 distinguishable uses supported by your proposal, lumped together by the 
 fact that they are both about grouping units of code together. Put 
 crudely, one use case is grouping lines of code, while the other is about 
 grouping files of code. The merits of supporting both have already been 
 debated in this discussion. The issue I'll touch on is supporting both 
 with the same syntax. The chief drawbacks here are:
 
>>> 
>>> What exactly would be required to make it first class?  Referencing file 
>>> names in the module declaration?
>>> 
>>>  See below.
 - It makes sense to use braces to group lines of code, but it makes no 
 sense to use braces to group files of code; this just causes entire files 
 to be indented.
 
>>> 
>>> If braces aren’t used to demarcate scopes, nesting modules becomes 
>>> ambiguous.
>>> 
>>> Again, let's observe the distinction about grouping files vs. grouping 
>>> lines.
>>> 
>>> Grouping files does not require braces: if the intended use of your feature 
>>> were to label files X, Y, and Z as belonging to one submodule and A, B, and 
>>> C to another, it would not matter if X, Y, and Z belonged to Foo.Bar and A, 
>>> B, and C to Foo.Bar.Baz: your syntax would not require braces.
>>>  
>>> It’s important to note that indentation is one particular style.  LLVM code 
>>> style, in particular, chooses not to indent after namespace declarations.  
>>> This issue also crops up when dealing with nested type declarations, and I 
>>> distinctly remember it not being a big enough deal to "fix this" at the 
>>> time when a proposal to “flatten” these declaration was brought up.
>>>  
>>> Mine is not a critique of the syntax itself; I don't particularly care 
>>> about indents, nor do I mind not indenting namespaces.
>>> 
>>> What I'm saying is, you would not have chosen to require braces if your 
>>> proposed feature were aimed at making the grouping of files into submodules 
>>> as simple as possible. You chose to accommodate grouping lines using the 
>>> same syntax as grouping files over the simplest design for grouping files. 
>>> Make no mistake, this promotes one use over another.
>> 
>> Ah, I see.  Yes, one of the stated goals is to become 
>> filesystem-independent.  We certainly cannot do that by encouraging the 
>> alternative.
>>  
>> Swift's current design is deliberately not file system-independent. A 
>> submodule design built on top of Swift could preserve that. Your draft 
>> proposal makes two changes: it introduces a design for submodules; and, it 
>> eliminates files as a unit of code by default (not least by declaring 
>> `fileprivate` redundant). To my mind, you have presented no justification 
>> for the second change other than to say that it is a stated goal--but why?
> 
> 
> 
> fileprivate access can be recreated by creating a private "utility submodule" 
> containing declarations of at most internal access.
> 
> 
>>> 
 - Because some lines of code necessarily precede some other lines of code, 
 it makes sense to declare the first group using `module` and to extend 
 that with the second group using `extension`. However, because a file of 
 

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 9:28 PM, Robert Widmann 
wrote:

>
> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann 
> wrote:
>
>>
>> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann > >wrote:
>>
>>>
>>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  wrote:
>>>
>>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>

 On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via
 swift-evolution  wrote:

 To my mind, any submodule system for Swift should be designed to
 relieve the pressure for long files, and make it easy to group tightly
 related files into a single unit with shared visibility. That way
 developers can easily organize their code into smaller files while
 utilizing Swift’s pattern of providing protocol conformances in extensions
 and keeping implementation details hidden from the rest of the module at
 large.


 Wonderful, because that’s absolutely supported by this proposal.  To
 group tightly related files into a single unit, simply declare a submodule
 for them and extend it in each of your related files.

>>>
>>> It's supported, but it isn't first-class. By this I mean: there are two
>>> distinguishable uses supported by your proposal, lumped together by the
>>> fact that they are both about grouping units of code together. Put crudely,
>>> one use case is grouping lines of code, while the other is about grouping
>>> files of code. The merits of supporting both have already been debated in
>>> this discussion. The issue I'll touch on is supporting both with the same
>>> syntax. The chief drawbacks here are:
>>>
>>>
>>> What exactly would be required to *make* it first class?  Referencing
>>> file names in the module declaration?
>>>
>>
>>  See below.
>>
>>> - It makes sense to use braces to group lines of code, but it makes no
>>> sense to use braces to group files of code; this just causes entire files
>>> to be indented.
>>>
>>>
>>> If braces aren’t used to demarcate scopes, nesting modules becomes
>>> ambiguous.
>>>
>>
>> Again, let's observe the distinction about grouping files vs. grouping
>> lines.
>>
>> Grouping files does not require braces: if the intended use of your
>> feature were to label files X, Y, and Z as belonging to one submodule and
>> A, B, and C to another, it would not matter if X, Y, and Z belonged to
>> Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require
>> braces.
>>
>>
>>> It’s important to note that indentation is one particular style.  LLVM
>>> code style, in particular, chooses not to indent after namespace
>>> declarations.  This issue also crops up when dealing with nested type
>>> declarations, and I distinctly remember it not being a big enough deal to
>>> "fix this" at the time when a proposal to “flatten” these declaration was
>>> brought up.
>>>
>>
>> Mine is not a critique of the syntax itself; I don't particularly care
>> about indents, nor do I mind not indenting namespaces.
>>
>> What I'm saying is, you would not have chosen to require braces if your
>> proposed feature were aimed at making the grouping of files into submodules
>> as simple as possible. You chose to accommodate grouping lines using the
>> same syntax as grouping files over the simplest design for grouping files.
>> Make no mistake, this promotes one use over another.
>>
>>
>> Ah, I see.  Yes, one of the stated goals is to become
>> filesystem-independent.  We certainly cannot do that by encouraging the
>> alternative.
>>
>
> Swift's current design is deliberately not file system-independent. A
> submodule design built on top of Swift could preserve that. Your draft
> proposal makes two changes: it introduces a design for submodules; and, it
> eliminates files as a unit of code by default (not least by declaring
> `fileprivate` redundant). To my mind, you have presented no justification
> for the second change other than to say that it is a stated goal--but why?
>
>
>
>
>
>- fileprivate access can be recreated by creating a private "utility
>submodule" containing declarations of at most internal access.
>
>
>
>
>> - Because some lines of code necessarily precede some other lines of
>>> code, it makes sense to declare the first group using `module` and to
>>> extend that with the second group using `extension`. However, because a
>>> file of code does not necessarily precede another file of code, it is
>>> arbitrary which file is surrounded with a `module` declaration and which
>>> one is surrounded with an `extension` declaration.
>>>
>>>
>>> Absolutely.  But it is similarly arbitrary which public APIs are exposed
>>> in a type declaration and which are exposed in an extension 

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

[Robert Widmann via swift-evolution]

Let’s use some code to illustrate things.  

// FooUtilities.swift
//
// -module-name=Foo
// module Foo {
// Defines Foo.Utilities
module Utilities {
  internal func visibleInThisSubmodule() {}
}
//}

// FooUtilities+MoreUtilities.swift
extension Foo.Utilities {
  private func privateHelper() {
visibleInThisSubmodule()
  }
}



> On Feb 21, 2017, at 10:31 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 9:29 PM, Robert Widmann  > wrote:
> Once again, internal is your keyword.  An extension allows you to “open and 
> expand” the module boundary here, which is exactly what you want here - to 
> extend this module across file boundaries without showing your cards to an 
> external consumer of your framework. 
> 
> Sorry, I don't understand. Does your design support the use case below? I 
> don't think it does. Are you replying that supporting the use case below is 
> not a goal of your proposal? If so, please just say so.
> 
> 
>> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> Sorry, been replying to multiple sub-threads today.
>> 
>> 
>> For bar(), because you wish to be able to
>> 
>> 1) Not export it across the outermost module boundary
>> 2) But still use it internally
>> 
>> Internal access is required.  Any higher and you would export (violating 1), 
>> any lower and you wouldn’t be able to internally import (violating 2).
>> 
>> For baz(), because you wish to be able to
>> 
>> 1) Not export it across the outermost module boundary,
>> 2) Or even your own internal submodule boundary
>>  
>> 3) But still use it within the same submodule, across different file 
>> boundaries: this is the feature that many people have stated they want to 
>> emerge out of a submodule design.
>> 
>> Private or fileprivate suffices depending on the scoping you wish for it to 
>> have within the file/interface it’s a part of relative to the other APIs in 
>> the submodule.
>> 
>> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon > > > wrote:
>> >
>> > I specified two different behaviors for `bar()` and `baz()`. I see now 
>> > that you describe `internal` as having the behavior I want for `bar()`. Is 
>> > there a way I can get the behavior I want for `baz()`?
>> >
>> > --
>> > Brent Royal-Gordon
>> > Sent from my iPhone
>> >
>> > On Feb 21, 2017, at 6:51 PM, Robert Widmann > > > wrote:
>> >
>> >>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` 
>> >>> can access `bar()` but not `baz()`, and code outside `MyMod` can access 
>> >>> neither `bar()` nor `baz()`?
>> >>>
>> >>
>> >> internal
>> 
>> ___
>> 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

[Brent Royal-Gordon via swift-evolution]

> On Feb 21, 2017, at 7:14 PM, Robert Widmann  wrote:
> 
> Fileprivate and private are not changing at all.  Their meaning now extends 
> from “private to this file” and “private to this declaration” respectively to 
> those meanings plus “unexportable across any module boundary”.  One 
> implication of this is it is now possible to create module-scoped private 
> constants, functions, and data structures, which is one of the use-cases that 
> Daniel Duan mentioned earlier down in the thread.

So what you are saying is that, in my example:

// foo.swift
import MyMod.Submodule
func foo() {
bar()
}

// bar.swift
module Submodule {
internal func bar() {
baz()
}
}

// baz.swift
extension Submodule {   
??? func baz() {
…
}
}

There is nothing I can put in the `???` slot that will expose `baz()` to 
`bar()`, but not to `foo()`. Correct?

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 9:29 PM, Robert Widmann 
wrote:

> Once again, internal is your keyword.  An extension allows you to “open
> and expand” the module boundary here, which is exactly what you want here -
> to extend this module across file boundaries without showing your cards to
> an external consumer of your framework.
>

Sorry, I don't understand. Does your design support the use case below? I
don't think it does. Are you replying that supporting the use case below is
not a goal of your proposal? If so, please just say so.


On Feb 21, 2017, at 10:26 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Sorry, been replying to multiple sub-threads today.
>>
>>
>> For bar(), because you wish to be able to
>>
>> 1) Not export it across the outermost module boundary
>> 2) But still use it internally
>>
>> Internal access is required.  Any higher and you would export (violating
>> 1), any lower and you wouldn’t be able to internally import (violating 2).
>>
>> For baz(), because you wish to be able to
>>
>> 1) Not export it across the outermost module boundary,
>> 2) Or even your own internal submodule boundary
>>
>
> 3) But still use it within the same submodule, across different file
> boundaries: this is the feature that many people have stated they want to
> emerge out of a submodule design.
>
> Private or fileprivate suffices depending on the scoping you wish for it
>> to have within the file/interface it’s a part of relative to the other APIs
>> in the submodule.
>>
>> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon <
>> br...@architechies.com> wrote:
>> >
>> > I specified two different behaviors for `bar()` and `baz()`. I see now
>> that you describe `internal` as having the behavior I want for `bar()`. Is
>> there a way I can get the behavior I want for `baz()`?
>> >
>> > --
>> > Brent Royal-Gordon
>> > Sent from my iPhone
>> >
>> > On Feb 21, 2017, at 6:51 PM, Robert Widmann 
>> wrote:
>> >
>> >>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod`
>> can access `bar()` but not `baz()`, and code outside `MyMod` can access
>> neither `bar()` nor `baz()`?
>> >>>
>> >>
>> >> internal
>>
>> ___
>> 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

[Robert Widmann via swift-evolution]

Once again, internal is your keyword.  An extension allows you to “open and 
expand” the module boundary here, which is exactly what you want here - to 
extend this module across file boundaries without showing your cards to an 
external consumer of your framework. 

> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution 
> > wrote:
> Sorry, been replying to multiple sub-threads today.
> 
> 
> For bar(), because you wish to be able to
> 
> 1) Not export it across the outermost module boundary
> 2) But still use it internally
> 
> Internal access is required.  Any higher and you would export (violating 1), 
> any lower and you wouldn’t be able to internally import (violating 2).
> 
> For baz(), because you wish to be able to
> 
> 1) Not export it across the outermost module boundary,
> 2) Or even your own internal submodule boundary
>  
> 3) But still use it within the same submodule, across different file 
> boundaries: this is the feature that many people have stated they want to 
> emerge out of a submodule design.
> 
> Private or fileprivate suffices depending on the scoping you wish for it to 
> have within the file/interface it’s a part of relative to the other APIs in 
> the submodule.
> 
> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon  > > wrote:
> >
> > I specified two different behaviors for `bar()` and `baz()`. I see now that 
> > you describe `internal` as having the behavior I want for `bar()`. Is there 
> > a way I can get the behavior I want for `baz()`?
> >
> > --
> > Brent Royal-Gordon
> > Sent from my iPhone
> >
> > On Feb 21, 2017, at 6:51 PM, Robert Widmann  > > wrote:
> >
> >>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
> >>> access `bar()` but not `baz()`, and code outside `MyMod` can access 
> >>> neither `bar()` nor `baz()`?
> >>>
> >>
> >> internal
> 
> ___
> 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

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 10:03 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann  >wrote:
> 
>> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann > >wrote:
>> 
>>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
 On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
 > wrote:
 
 To my mind, any submodule system for Swift should be designed to relieve 
 the pressure for long files, and make it easy to group tightly related 
 files into a single unit with shared visibility. That way developers can 
 easily organize their code into smaller files while utilizing Swift’s 
 pattern of providing protocol conformances in extensions and keeping 
 implementation details hidden from the rest of the module at large.
 
>>> 
>>> Wonderful, because that’s absolutely supported by this proposal.  To group 
>>> tightly related files into a single unit, simply declare a submodule for 
>>> them and extend it in each of your related files.
>>> 
>>> It's supported, but it isn't first-class. By this I mean: there are two 
>>> distinguishable uses supported by your proposal, lumped together by the 
>>> fact that they are both about grouping units of code together. Put crudely, 
>>> one use case is grouping lines of code, while the other is about grouping 
>>> files of code. The merits of supporting both have already been debated in 
>>> this discussion. The issue I'll touch on is supporting both with the same 
>>> syntax. The chief drawbacks here are:
>>> 
>> 
>> What exactly would be required to make it first class?  Referencing file 
>> names in the module declaration?
>> 
>>  See below.
>>> - It makes sense to use braces to group lines of code, but it makes no 
>>> sense to use braces to group files of code; this just causes entire files 
>>> to be indented.
>>> 
>> 
>> If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.
>> 
>> Again, let's observe the distinction about grouping files vs. grouping lines.
>> 
>> Grouping files does not require braces: if the intended use of your feature 
>> were to label files X, Y, and Z as belonging to one submodule and A, B, and 
>> C to another, it would not matter if X, Y, and Z belonged to Foo.Bar and A, 
>> B, and C to Foo.Bar.Baz: your syntax would not require braces.
>>  
>> It’s important to note that indentation is one particular style.  LLVM code 
>> style, in particular, chooses not to indent after namespace declarations.  
>> This issue also crops up when dealing with nested type declarations, and I 
>> distinctly remember it not being a big enough deal to "fix this" at the time 
>> when a proposal to “flatten” these declaration was brought up.
>>  
>> Mine is not a critique of the syntax itself; I don't particularly care about 
>> indents, nor do I mind not indenting namespaces.
>> 
>> What I'm saying is, you would not have chosen to require braces if your 
>> proposed feature were aimed at making the grouping of files into submodules 
>> as simple as possible. You chose to accommodate grouping lines using the 
>> same syntax as grouping files over the simplest design for grouping files. 
>> Make no mistake, this promotes one use over another.
> 
> Ah, I see.  Yes, one of the stated goals is to become filesystem-independent. 
>  We certainly cannot do that by encouraging the alternative.
>  
> Swift's current design is deliberately not file system-independent. A 
> submodule design built on top of Swift could preserve that. Your draft 
> proposal makes two changes: it introduces a design for submodules; and, it 
> eliminates files as a unit of code by default (not least by declaring 
> `fileprivate` redundant). To my mind, you have presented no justification for 
> the second change other than to say that it is a stated goal--but why?



fileprivate access can be recreated by creating a private "utility submodule" 
containing declarations of at most internal access.


>> 
>>> - Because some lines of code necessarily precede some other lines of code, 
>>> it makes sense to declare the first group using `module` and to extend that 
>>> with the second group using `extension`. However, because a file of code 
>>> does not necessarily precede another file of code, it is arbitrary which 
>>> file is surrounded with a `module` declaration and which one is surrounded 
>>> with an `extension` declaration.
>> 
>> Absolutely.  But it is similarly arbitrary which public 

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> Sorry, been replying to multiple sub-threads today.
>
>
> For bar(), because you wish to be able to
>
> 1) Not export it across the outermost module boundary
> 2) But still use it internally
>
> Internal access is required.  Any higher and you would export (violating
> 1), any lower and you wouldn’t be able to internally import (violating 2).
>
> For baz(), because you wish to be able to
>
> 1) Not export it across the outermost module boundary,
> 2) Or even your own internal submodule boundary
>

3) But still use it within the same submodule, across different file
boundaries: this is the feature that many people have stated they want to
emerge out of a submodule design.

Private or fileprivate suffices depending on the scoping you wish for it to
> have within the file/interface it’s a part of relative to the other APIs in
> the submodule.
>
> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon 
> wrote:
> >
> > I specified two different behaviors for `bar()` and `baz()`. I see now
> that you describe `internal` as having the behavior I want for `bar()`. Is
> there a way I can get the behavior I want for `baz()`?
> >
> > --
> > Brent Royal-Gordon
> > Sent from my iPhone
> >
> > On Feb 21, 2017, at 6:51 PM, Robert Widmann 
> wrote:
> >
> >>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod`
> can access `bar()` but not `baz()`, and code outside `MyMod` can access
> neither `bar()` nor `baz()`?
> >>>
> >>
> >> internal
>
> ___
> 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

[Robert Widmann via swift-evolution]

Fileprivate and private are not changing at all.  Their meaning now extends 
from “private to this file” and “private to this declaration” respectively to 
those meanings plus “unexportable across any module boundary”.  One implication 
of this is it is now possible to create module-scoped private constants, 
functions, and data structures, which is one of the use-cases that Daniel Duan 
mentioned earlier down in the thread.

> On Feb 21, 2017, at 10:12 PM, Brent Royal-Gordon  
> wrote:
> 
> So are private and/or fileprivate changing to mean "visible within current 
> submodule"? Because I specified that baz() is in a type extension, possibly 
> in another file. 
> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
> 
>> On Feb 21, 2017, at 7:08 PM, Robert Widmann  wrote:
>> 
>> For baz(), because you wish to be able to
>> 
>> 1) Not export it across the outermost module boundary, 
>> 2) Or even your own internal submodule boundary
>> 
>> Private or fileprivate suffices depending on the scoping you wish for it to 
>> have within the file/interface it’s a part of relative to the other APIs in 
>> the submodule.

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

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

[Brent Royal-Gordon via swift-evolution]

So are private and/or fileprivate changing to mean "visible within current 
submodule"? Because I specified that baz() is in a type extension, possibly in 
another file. 

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Feb 21, 2017, at 7:08 PM, Robert Widmann  wrote:
> 
> For baz(), because you wish to be able to
> 
> 1) Not export it across the outermost module boundary, 
> 2) Or even your own internal submodule boundary
> 
> Private or fileprivate suffices depending on the scoping you wish for it to 
> have within the file/interface it’s a part of relative to the other APIs in 
> the submodule.
___
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]

Sorry, been replying to multiple sub-threads today.


For bar(), because you wish to be able to 

1) Not export it across the outermost module boundary
2) But still use it internally

Internal access is required.  Any higher and you would export (violating 1), 
any lower and you wouldn’t be able to internally import (violating 2).

For baz(), because you wish to be able to

1) Not export it across the outermost module boundary, 
2) Or even your own internal submodule boundary

Private or fileprivate suffices depending on the scoping you wish for it to 
have within the file/interface it’s a part of relative to the other APIs in the 
submodule.

> On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon  
> wrote:
> 
> I specified two different behaviors for `bar()` and `baz()`. I see now that 
> you describe `internal` as having the behavior I want for `bar()`. Is there a 
> way I can get the behavior I want for `baz()`?
> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
> 
> On Feb 21, 2017, at 6:51 PM, Robert Widmann  wrote:
> 
>>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
>>> access `bar()` but not `baz()`, and code outside `MyMod` can access neither 
>>> `bar()` nor `baz()`?
>>> 
>> 
>> internal

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 8:51 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon 
> wrote:
>
> On Feb 21, 2017, at 6:43 PM, Robert Widmann 
> wrote:
>
> That is not what this proposal requires.  A public API is ripe for
> re(export), but if the parent wishes to communicate with its children
> without exporting across the module boundary, see the definition of
> `internal`.
>
>
> I'm not sure whether I'm misunderstanding or we're talking past each other.
>
> Let me state this really simply. You have some code in a top-level module,
> `MyMod`:
>
> import MyMod.Submodule
>
> func foo() {
> bar()
> }
>
> And you have some other code in a submodule:
>
> module Submodule {
> ??? func bar() {
> baz()
> }
> }
>
> And then—perhaps in a separate file—you have some other code in an
> extension of the submodule:
>
> extension Submodule {
> ??? func baz() {
> …
> }
> }
>
> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can
> access `bar()` but not `baz()`, and code outside `MyMod` can access neither
> `bar()` nor `baz()`?
>
>
> internal
>

Huh? Brent wants `bar()` to be visible inside `foo()`, but not `baz()`. How
can they both use `internal`?


>
>- open and public declarations are exported by a module for
>consumption by clients of the module.
>
>
>- internal declarations scope over the entire module and any derived
>submodules.
>
> This way you can consume your own interface without it crossing the module
> boundary.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Feb 21, 2017, at 8:57 PM, Michel Fortin via swift-evolution 
>  wrote:
> 
> (this was accidentally sent off-list, reposting here a day later)

And this was my reply.

> 
>> Le 20 févr. 2017 à 12:17, Matthew Johnson  a écrit :
>> 
>>> e) Generic Containers:
>>> Generic containers that impose requirements on their elements will pose 
>>> some additional problems, for instance: `Set.insert` needs to call 
>>> `hashValue` and `==` on its elements, making the purity of `Set.insert` 
>>> constrained by the purity of those functions. Without a way to express this 
>>> kind of conditional purity, `Set` and `Dictionary` cannot be pure.
>> 
>> Could we use a mechanism similar to `rethrows` to address this kind of 
>> transitive purity?  We have already discussed something along those lines 
>> for handling functions passed as arguments.  Maybe that mechanism could be 
>> designed to handle this use case as well.
> 
> Similar, yes. But more complicated too. In pseudo code, this is what you'd 
> have to express for `Set.insert`:
> 
>   pure(where: Element.hashValue is pure, Element.== is pure)
>   func insert(_ element: Element) { ... }
> 
> Then the compiler can enforce that `insert` only does things that are allowed 
> in a pure function, but can ignore the purity of Element.hashValue and 
> Element.== because the caller will check for that that.

Yep, that’s the kind of thing I had in mind.

I can imagine being this explicit could get pretty cumbersome though.  I wonder 
if there is a way to streamline this.  For example, in this case if we could 
just talk about `Element`’s conformance to `Hashable` and we could talk about a 
`pure` conformance (all requirements are met with pure implementations) then we 
could just say something like this:

pure(Element.Hashable)
func insert(_ element: Element) { ... }

Note: I also removed some redundancies - we could just say that the parameters 
are a list of things the purity of which `insert`’s purity depends.

For function arguments it would look something like this:

pure(transform)
func map(transform: Element -> T)

> 
> -- 
> Michel Fortin
> https://michelf.ca
> 
> ___
> 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

[Brent Royal-Gordon via swift-evolution]

I specified two different behaviors for `bar()` and `baz()`. I see now that you 
describe `internal` as having the behavior I want for `bar()`. Is there a way I 
can get the behavior I want for `baz()`?

-- 
Brent Royal-Gordon
Sent from my iPhone

On Feb 21, 2017, at 6:51 PM, Robert Widmann  wrote:

>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
>> access `bar()` but not `baz()`, and code outside `MyMod` can access neither 
>> `bar()` nor `baz()`?
>> 
> 
> internal
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 8:41 PM, Robert Widmann 
wrote:

>
> On Feb 21, 2017, at 9:37 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann 
> wrote:
>
>>
>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution
>>>  wrote:
>>>
>>> To my mind, any submodule system for Swift should be designed to relieve
>>> the pressure for long files, and make it easy to group tightly related
>>> files into a single unit with shared visibility. That way developers can
>>> easily organize their code into smaller files while utilizing Swift’s
>>> pattern of providing protocol conformances in extensions and keeping
>>> implementation details hidden from the rest of the module at large.
>>>
>>>
>>> Wonderful, because that’s absolutely supported by this proposal.  To
>>> group tightly related files into a single unit, simply declare a submodule
>>> for them and extend it in each of your related files.
>>>
>>
>> It's supported, but it isn't first-class. By this I mean: there are two
>> distinguishable uses supported by your proposal, lumped together by the
>> fact that they are both about grouping units of code together. Put crudely,
>> one use case is grouping lines of code, while the other is about grouping
>> files of code. The merits of supporting both have already been debated in
>> this discussion. The issue I'll touch on is supporting both with the same
>> syntax. The chief drawbacks here are:
>>
>>
>> What exactly would be required to *make* it first class?  Referencing
>> file names in the module declaration?
>>
>
>  See below.
>
>> - It makes sense to use braces to group lines of code, but it makes no
>> sense to use braces to group files of code; this just causes entire files
>> to be indented.
>>
>>
>> If braces aren’t used to demarcate scopes, nesting modules becomes
>> ambiguous.
>>
>
> Again, let's observe the distinction about grouping files vs. grouping
> lines.
>
> Grouping files does not require braces: if the intended use of your
> feature were to label files X, Y, and Z as belonging to one submodule and
> A, B, and C to another, it would not matter if X, Y, and Z belonged to
> Foo.Bar and A, B, and C to Foo.Bar.Baz: your syntax would not require
> braces.
>
>
>> It’s important to note that indentation is one particular style.  LLVM
>> code style, in particular, chooses not to indent after namespace
>> declarations.  This issue also crops up when dealing with nested type
>> declarations, and I distinctly remember it not being a big enough deal to
>> "fix this" at the time when a proposal to “flatten” these declaration was
>> brought up.
>>
>
> Mine is not a critique of the syntax itself; I don't particularly care
> about indents, nor do I mind not indenting namespaces.
>
> What I'm saying is, you would not have chosen to require braces if your
> proposed feature were aimed at making the grouping of files into submodules
> as simple as possible. You chose to accommodate grouping lines using the
> same syntax as grouping files over the simplest design for grouping files.
> Make no mistake, this promotes one use over another.
>
>
> Ah, I see.  Yes, one of the stated goals is to become
> filesystem-independent.  We certainly cannot do that by encouraging the
> alternative.
>

Swift's current design is deliberately not file system-independent. A
submodule design built on top of Swift could preserve that. Your draft
proposal makes two changes: it introduces a design for submodules; and, it
eliminates files as a unit of code by default (not least by declaring
`fileprivate` redundant). To my mind, you have presented no justification
for the second change other than to say that it is a stated goal--but why?

>
> - Because some lines of code necessarily precede some other lines of code,
>> it makes sense to declare the first group using `module` and to extend that
>> with the second group using `extension`. However, because a file of code
>> does not necessarily precede another file of code, it is arbitrary which
>> file is surrounded with a `module` declaration and which one is surrounded
>> with an `extension` declaration.
>>
>>
>> Absolutely.  But it is similarly arbitrary which public APIs are exposed
>> in a type declaration and which are exposed in an extension declaration.
>>
>
> Not entirely, no. Stored properties must be in the type declaration. Enum
> cases must be in the type declaration. Perhaps you regard these as
> temporary inconveniences of the current grammar; I see them as quite
> reasonable ways to give some consistency as to what's written where in a
> language where types can be retroactively extended. In a very real sense,
> you must read the type declaration before you 

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

[Michel Fortin via swift-evolution]

(this was accidentally sent off-list, reposting here a day later)

> Le 20 févr. 2017 à 12:17, Matthew Johnson  a écrit :
> 
>> e) Generic Containers:
>> Generic containers that impose requirements on their elements will pose some 
>> additional problems, for instance: `Set.insert` needs to call `hashValue` 
>> and `==` on its elements, making the purity of `Set.insert` constrained by 
>> the purity of those functions. Without a way to express this kind of 
>> conditional purity, `Set` and `Dictionary` cannot be pure.
> 
> Could we use a mechanism similar to `rethrows` to address this kind of 
> transitive purity?  We have already discussed something along those lines for 
> handling functions passed as arguments.  Maybe that mechanism could be 
> designed to handle this use case as well.

Similar, yes. But more complicated too. In pseudo code, this is what you'd have 
to express for `Set.insert`:

pure(where: Element.hashValue is pure, Element.== is pure)
func insert(_ element: Element) { ... }

Then the compiler can enforce that `insert` only does things that are allowed 
in a pure function, but can ignore the purity of Element.hashValue and 
Element.== because the caller will check for that that.

-- 
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][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

What is implied by the definition of `internal` in the proposal (which should, 
as this thread has shown, be stated explicitly) is that by “export” we mean 
“export to clients” across the outermost module-boundary.  Any API that is not 
public is, by definition, not able to cross this outermost boundary.  Internal 
API is allowed to cross internal boundaries if it is imported internally.  
Private and fileprivate API may not, as the name implies, cross file boundaries 
and so cannot be allowed to cross either boundary.

> On Feb 21, 2017, at 9:49 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 21, 2017, at 6:43 PM, Robert Widmann  wrote:
>> 
>> That is not what this proposal requires.  A public API is ripe for 
>> re(export), but if the parent wishes to communicate with its children 
>> without exporting across the module boundary, see the definition of 
>> `internal`.
> 
> I'm not sure whether I'm misunderstanding or we're talking past each other.
> 
> Let me state this really simply. You have some code in a top-level module, 
> `MyMod`:
> 
>   import MyMod.Submodule
>   
>   func foo() {
>   bar()
>   }
> 
> And you have some other code in a submodule:
> 
>   module Submodule {
>   ??? func bar() {
>   baz()
>   }
>   }
> 
> And then—perhaps in a separate file—you have some other code in an extension 
> of the submodule:
> 
>   extension Submodule {   
>   ??? func baz() {
>   …
>   }
>   }
> 
> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
> access `bar()` but not `baz()`, and code outside `MyMod` can access neither 
> `bar()` nor `baz()`?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
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 9:49 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 21, 2017, at 6:43 PM, Robert Widmann  wrote:
>> 
>> That is not what this proposal requires.  A public API is ripe for 
>> re(export), but if the parent wishes to communicate with its children 
>> without exporting across the module boundary, see the definition of 
>> `internal`.
> 
> I'm not sure whether I'm misunderstanding or we're talking past each other.
> 
> Let me state this really simply. You have some code in a top-level module, 
> `MyMod`:
> 
>   import MyMod.Submodule
>   
>   func foo() {
>   bar()
>   }
> 
> And you have some other code in a submodule:
> 
>   module Submodule {
>   ??? func bar() {
>   baz()
>   }
>   }
> 
> And then—perhaps in a separate file—you have some other code in an extension 
> of the submodule:
> 
>   extension Submodule {   
>   ??? func baz() {
>   …
>   }
>   }
> 
> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
> access `bar()` but not `baz()`, and code outside `MyMod` can access neither 
> `bar()` nor `baz()`?
> 

internal


open and public declarations are exported by a module for consumption by 
clients of the module.
internal declarations scope over the entire module and any derived submodules.
This way you can consume your own interface without it crossing the module 
boundary.

> -- 
> Brent Royal-Gordon
> Architechies
> 

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

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 21, 2017, at 6:43 PM, Robert Widmann  wrote:
> 
> That is not what this proposal requires.  A public API is ripe for 
> re(export), but if the parent wishes to communicate with its children without 
> exporting across the module boundary, see the definition of `internal`.

I'm not sure whether I'm misunderstanding or we're talking past each other.

Let me state this really simply. You have some code in a top-level module, 
`MyMod`:

import MyMod.Submodule

func foo() {
bar()
}

And you have some other code in a submodule:

module Submodule {
??? func bar() {
baz()
}
}

And then—perhaps in a separate file—you have some other code in an extension of 
the submodule:

extension Submodule {   
??? func baz() {
…
}
}

What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can 
access `bar()` but not `baz()`, and code outside `MyMod` can access neither 
`bar()` nor `baz()`?

-- 
Brent Royal-Gordon
Architechies

___
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 9:44 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 8:32 PM, Robert Widmann  > wrote:
> There’s an important distinction between the ability to wall off, and this 
> particular instance of doing so.  By definition, a module allows for the 
> encapsulation and export of a subset of an API, the same way access modifiers 
> allow types to expose an interface.  If the sub-parts of that API must 
> interact, they must by definition share the same concerns and belong together 
> under the same submodule.  If their implementations require separation then 
> further subdivisions can be made with further submodules.  This is the design 
> practice encouraged, and put to good use, by every other language with 
> modules since the heyday of Modula, and breaking that contract by creating 
> unnecessary parent divisions to introduce headaches for yourself is just 
> another case of anti-modular use of a modular system.  There’s nothing we can 
> do to stop you from asking for this, but that also doesn’t excuse the poor 
> design choice here - especially when it can be rectified by reshuffling your 
> own dependency graph.
> 
> Indeed, I won't disagree with you wrt _modules_. I notice you titled this 
> thread "submodules" but propose a syntax that uses the word `module`. Left 
> unsaid, I'd imagine, is that you regard a submodule as a 
> module-within-a-module.
> 
> This is *not*, as I understand it, what most people on this list are asking 
> for wrt _submodules_. Instead, they are asking for a unit of code greater 
> than a file but less than a module. To parallel that new facility, they want 
> an access level greater than fileprivate but less than internal. This draft 
> proposal (in its failure to acknowledge this frequent ask) explicitly but 
> _silently_ rejects those motivations.

So they want to be able to aggregate interfaces and define their exportability, 
while also maintaining the ability to scope a declaration to a particular 
grouping.  This is, quite literally, the semantics we have defined - with 
modules enabling aggregation and `internal` stretching to become this “new” 
access control kind.

> 
>> On Feb 21, 2017, at 9:19 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
 On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution 
 > wrote:
 
 It has been my hope that a lightweight module system will remove the need 
 for `private` *and* `fileprivate`.
>>> 
>>> I really doubt it will. `private`/`fileprivate` works because you can also 
>>> access `internal` at the same time.
>>> 
>>> What I mean by that is, think about code like this:
>>> 
>>> // Foo.swift
>>> public class Foo {
>>> public init() { … }
>>> 
>>> func doBar() -> Quux {
>>> return helper(in: randomRange())
>>> }
>>> 
>>> private func helper(in range: Range) -> Quux {
>>> …
>>> }
>>> }
>>> 
>>> // Bar.swift
>>> public class Bar {
>>> public static let shared = Bar()
>>> 
>>> func baz(with foo: Foo) {
>>> let quux = foo.doBar()
>>> process(quux)
>>> }
>>> 
>>> private func process(_ quux: Quux) {
>>> …
>>> }
>>> }
>>> 
>>> These classes have `public` APIs that are externally visible, `internal` 
>>> APIs for communicating with each other, and `private` APIs for 
>>> implementation details. Now try to reproduce the same design with 
>>> submodules and `public`/`internal` only:
>>> 
>>> public import MyMod.Foo
>>> public import MyMod.Bar
>>> 
>>> module Foo {
>>> public class Foo {
>>> public init() { … }
>>> 
>>> 
>>> ??? func doBar() -> Quux {
>>> return helper(in: randomRange())
>>> }
>>> 
>>> func helper(in range: Range) -> Quux {
>>> …
>>> }
>>> }
>>> }
>>> 
>>> // Bar.swift
>>> module Bar {
>>> public class Bar {
>>> public static let shared = Bar()
>>> 
>>> ??? func baz(with foo: Foo) {
>>> let quux = foo.doBar()
>>> process(quux)
>>> }
>>> 
>>> func process(_ quux: Quux) {
>>>  

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 8:32 PM, Robert Widmann 
wrote:

> There’s an important distinction between the ability to wall off, and this
> particular instance of doing so.  By definition, a module allows for the
> encapsulation and export of a subset of an API, the same way access
> modifiers allow types to expose an interface.  If the sub-parts of that API
> must interact, they must by definition share the same concerns and belong
> together under the same submodule.  If their implementations require
> separation then further subdivisions can be made with further submodules.
> This is the design practice encouraged, and put to good use, by every other
> language with modules since the heyday of Modula, and breaking that
> contract by creating unnecessary parent divisions to introduce headaches
> for yourself is just another case of anti-modular use of a modular system.
> There’s nothing we can do to stop you from asking for this, but that also
> doesn’t excuse the poor design choice here - especially when it can be
> rectified by reshuffling your own dependency graph.
>

Indeed, I won't disagree with you wrt _modules_. I notice you titled this
thread "submodules" but propose a syntax that uses the word `module`. Left
unsaid, I'd imagine, is that you regard a submodule as a
module-within-a-module.

This is *not*, as I understand it, what most people on this list are asking
for wrt _submodules_. Instead, they are asking for a unit of code greater
than a file but less than a module. To parallel that new facility, they
want an access level greater than fileprivate but less than internal. This
draft proposal (in its failure to acknowledge this frequent ask) explicitly
but _silently_ rejects those motivations.

On Feb 21, 2017, at 9:19 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It has been my hope that a lightweight module system will remove the need
>> for `private` *and* `fileprivate`.
>>
>>
>> I really doubt it will. `private`/`fileprivate` works because you can
>> also access `internal` at the same time.
>>
>> What I mean by that is, think about code like this:
>>
>> // Foo.swift
>> public class Foo {
>> public init() { … }
>>
>> func doBar() -> Quux {
>> return helper(in: randomRange())
>> }
>>
>> private func helper(in range: Range) -> Quux {
>> …
>> }
>> }
>>
>> // Bar.swift
>> public class Bar {
>> public static let shared = Bar()
>>
>> func baz(with foo: Foo) {
>> let quux = foo.doBar()
>> process(quux)
>> }
>>
>> private func process(_ quux: Quux) {
>> …
>> }
>> }
>>
>> These classes have `public` APIs that are externally visible, `internal`
>> APIs for communicating with each other, and `private` APIs for
>> implementation details. Now try to reproduce the same design with
>> submodules and `public`/`internal` only:
>>
>> public import MyMod.Foo
>> public import MyMod.Bar
>>
>> module Foo {
>> public class Foo {
>> public init() { … }
>>
>>
>> ??? func doBar() -> Quux {
>> return helper(in: randomRange())
>> }
>>
>> func helper(in range: Range) -> Quux {
>> …
>> }
>> }
>> }
>>
>> // Bar.swift
>> module Bar {
>> public class Bar {
>> public static let shared = Bar()
>>
>> ??? func baz(with foo: Foo) {
>> let quux = foo.doBar()
>> process(quux)
>> }
>>
>> func process(_ quux: Quux) {
>> …
>> }
>> }
>> }
>>
>> The `doBar()` and `baz()` methods have to be either exposed to third
>> parties or kept away from yourself. That's just not viable.
>>
>>
>> If they must communicate, they can be a part of the same (sub)module.
>> This makes filling in these annotations trivial.  Nobody actually uses
>> modules to wall off their own APIs from themselves like this, they use
>> submodules to encapsulate the internal parts and surface public APIs in the
>> parent.
>>
>
> I think you'll find a ton of people on this list who would want to use
> submodules precisely to wall off their own APIs from themselves. Witness
> the hundreds of messages about new syntax to do just that.
>
>
>>
>> module Bar {
>>
>> public class Foo {
>>
>> public init() { … }
>>
>>
>>
>> internal func doBar() -> Quux {
>>
>> return helper(in: randomRange())
>>
>> }
>>
>>
>> internal func helper(in range: Range) -> Quux {
>>
>> …
>>
>> }
>>
>> }
>>
>> }
>>
>>
>> // Bar.swift
>>
>> extension Bar {
>>
>> public class Bar {
>>
>> public static let shared = Bar()
>>
>>
>> internal func baz(with foo: Foo) {
>>
>> let quux = foo.doBar()
>>
>> process(quux)
>>
>> }
>>
>>
>> internal func process(_ quux: Quux) {
>>
>> …
>>
>> }
>>
>> }
>> }
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org

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

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 9:38 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 21, 2017, at 6:09 PM, Robert Widmann  wrote:
>> 
>>> If I'm reading this correctly, you're proposing that the `internal` APIs in 
>>> a submodule should *not* be accessible to enclosing modules. I also don't 
>>> see any indication that you can control who is allowed to import a 
>>> particular submodule.
>>> 
>>> That means that, if you use a submodule to encapsulate internal state, the 
>>> APIs that are available to the parent module are *also* available to any 
>>> rando who feels like importing your submodule. I don't think that's going 
>>> to be a tenable design.
>> 
>> If the state is truly internal, and you are using internal access control, 
>> this is impossible.  The internal state cannot cross the module boundary 
>> unless it is marked public.  If a “random” feels like importing my 
>> submodule, they will not have access to any symbols.
> 
> I think you're missing my point.
> 
> What you appear to be saying is: "If two things need privileged access to 
> each other, they should be in the same module; if they should hide 
> implementation details from each other, they should be in different modules." 
> But it's perfectly possible for two things to *both* need privileged access 
> to some APIs *and* hide implementation details from one another.
> 
> Basically, my objection is, this proposal requires that parent modules only 
> communicate with submodules through fully `public` APIs which are also 
> available outside the module. If you want to encapsulate certain 
> implementation details by putting them in a submodule, you must paradoxically 
> expose other details—the APIs through which the parent module is supposed to 
> interact with the submodule—to the whole world. That restriction conflicts 
> with Swift's important goal of ensuring that libraries only expose API 
> surface they're committed to supporting indefinitely.

That is not what this proposal requires.  A public API is ripe for re(export), 
but if the parent wishes to communicate with its children without exporting 
across the module boundary, see the definition of `internal`.

> 
> Basically, I think that either we need a new access level meaning "visible to 
> the top-level module and all of its submodules, but not to other modules", or 
> we need a way to specify that a submodule is internal-only and shouldn't be 
> importable by outside code. My submodule sketch the other day took the second 
> approach, but I think one or the other is necessary if we want submodules to 
> serve both as public units of API surface and private encapsulators of 
> implementation detail.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
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 9:37 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann  >wrote:
> 
>> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>> > wrote:
>>> 
>>> To my mind, any submodule system for Swift should be designed to relieve 
>>> the pressure for long files, and make it easy to group tightly related 
>>> files into a single unit with shared visibility. That way developers can 
>>> easily organize their code into smaller files while utilizing Swift’s 
>>> pattern of providing protocol conformances in extensions and keeping 
>>> implementation details hidden from the rest of the module at large.
>>> 
>> 
>> Wonderful, because that’s absolutely supported by this proposal.  To group 
>> tightly related files into a single unit, simply declare a submodule for 
>> them and extend it in each of your related files.
>> 
>> It's supported, but it isn't first-class. By this I mean: there are two 
>> distinguishable uses supported by your proposal, lumped together by the fact 
>> that they are both about grouping units of code together. Put crudely, one 
>> use case is grouping lines of code, while the other is about grouping files 
>> of code. The merits of supporting both have already been debated in this 
>> discussion. The issue I'll touch on is supporting both with the same syntax. 
>> The chief drawbacks here are:
>> 
> 
> What exactly would be required to make it first class?  Referencing file 
> names in the module declaration?
> 
>  See below.
>> - It makes sense to use braces to group lines of code, but it makes no sense 
>> to use braces to group files of code; this just causes entire files to be 
>> indented.
>> 
> 
> If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.
> 
> Again, let's observe the distinction about grouping files vs. grouping lines.
> 
> Grouping files does not require braces: if the intended use of your feature 
> were to label files X, Y, and Z as belonging to one submodule and A, B, and C 
> to another, it would not matter if X, Y, and Z belonged to Foo.Bar and A, B, 
> and C to Foo.Bar.Baz: your syntax would not require braces.
>  
> It’s important to note that indentation is one particular style.  LLVM code 
> style, in particular, chooses not to indent after namespace declarations.  
> This issue also crops up when dealing with nested type declarations, and I 
> distinctly remember it not being a big enough deal to "fix this" at the time 
> when a proposal to “flatten” these declaration was brought up.
>  
> Mine is not a critique of the syntax itself; I don't particularly care about 
> indents, nor do I mind not indenting namespaces.
> 
> What I'm saying is, you would not have chosen to require braces if your 
> proposed feature were aimed at making the grouping of files into submodules 
> as simple as possible. You chose to accommodate grouping lines using the same 
> syntax as grouping files over the simplest design for grouping files. Make no 
> mistake, this promotes one use over another.

Ah, I see.  Yes, one of the stated goals is to become filesystem-independent.  
We certainly cannot do that by encouraging the alternative.

> 
>> - Because some lines of code necessarily precede some other lines of code, 
>> it makes sense to declare the first group using `module` and to extend that 
>> with the second group using `extension`. However, because a file of code 
>> does not necessarily precede another file of code, it is arbitrary which 
>> file is surrounded with a `module` declaration and which one is surrounded 
>> with an `extension` declaration.
> 
> Absolutely.  But it is similarly arbitrary which public APIs are exposed in a 
> type declaration and which are exposed in an extension declaration.
> 
> Not entirely, no. Stored properties must be in the type declaration. Enum 
> cases must be in the type declaration. Perhaps you regard these as temporary 
> inconveniences of the current grammar; I see them as quite reasonable ways to 
> give some consistency as to what's written where in a language where types 
> can be retroactively extended. In a very real sense, you must read the type 
> declaration before you read the extensions in order to understand the latter. 
> By comparison, there is nothing that must be in your proposed module 
> declaration.
>  
> My hope is that the module declaration itself will become the one-stop-shop 
> for re-exports and general public bookkeeping just as aggregate declarations 
> are today.  Module extensions exist to accommodate users that wish to break 
> 

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

[Brent Royal-Gordon via swift-evolution]

> On Feb 21, 2017, at 6:09 PM, Robert Widmann  wrote:
> 
>> If I'm reading this correctly, you're proposing that the `internal` APIs in 
>> a submodule should *not* be accessible to enclosing modules. I also don't 
>> see any indication that you can control who is allowed to import a 
>> particular submodule.
>> 
>> That means that, if you use a submodule to encapsulate internal state, the 
>> APIs that are available to the parent module are *also* available to any 
>> rando who feels like importing your submodule. I don't think that's going to 
>> be a tenable design.
> 
> If the state is truly internal, and you are using internal access control, 
> this is impossible.  The internal state cannot cross the module boundary 
> unless it is marked public.  If a “random” feels like importing my submodule, 
> they will not have access to any symbols.

I think you're missing my point.

What you appear to be saying is: "If two things need privileged access to each 
other, they should be in the same module; if they should hide implementation 
details from each other, they should be in different modules." But it's 
perfectly possible for two things to *both* need privileged access to some APIs 
*and* hide implementation details from one another.

Basically, my objection is, this proposal requires that parent modules only 
communicate with submodules through fully `public` APIs which are also 
available outside the module. If you want to encapsulate certain implementation 
details by putting them in a submodule, you must paradoxically expose other 
details—the APIs through which the parent module is supposed to interact with 
the submodule—to the whole world. That restriction conflicts with Swift's 
important goal of ensuring that libraries only expose API surface they're 
committed to supporting indefinitely.

Basically, I think that either we need a new access level meaning "visible to 
the top-level module and all of its submodules, but not to other modules", or 
we need a way to specify that a submodule is internal-only and shouldn't be 
importable by outside code. My submodule sketch the other day took the second 
approach, but I think one or the other is necessary if we want submodules to 
serve both as public units of API surface and private encapsulators of 
implementation detail.

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 8:22 PM, Robert Widmann 
wrote:

>
> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  wrote:
>
> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> To my mind, any submodule system for Swift should be designed to relieve
>> the pressure for long files, and make it easy to group tightly related
>> files into a single unit with shared visibility. That way developers can
>> easily organize their code into smaller files while utilizing Swift’s
>> pattern of providing protocol conformances in extensions and keeping
>> implementation details hidden from the rest of the module at large.
>>
>>
>> Wonderful, because that’s absolutely supported by this proposal.  To
>> group tightly related files into a single unit, simply declare a submodule
>> for them and extend it in each of your related files.
>>
>
> It's supported, but it isn't first-class. By this I mean: there are two
> distinguishable uses supported by your proposal, lumped together by the
> fact that they are both about grouping units of code together. Put crudely,
> one use case is grouping lines of code, while the other is about grouping
> files of code. The merits of supporting both have already been debated in
> this discussion. The issue I'll touch on is supporting both with the same
> syntax. The chief drawbacks here are:
>
>
> What exactly would be required to *make* it first class?  Referencing
> file names in the module declaration?
>

 See below.

> - It makes sense to use braces to group lines of code, but it makes no
> sense to use braces to group files of code; this just causes entire files
> to be indented.
>
>
> If braces aren’t used to demarcate scopes, nesting modules becomes
> ambiguous.
>

Again, let's observe the distinction about grouping files vs. grouping
lines.

Grouping files does not require braces: if the intended use of your feature
were to label files X, Y, and Z as belonging to one submodule and A, B, and
C to another, it would not matter if X, Y, and Z belonged to Foo.Bar and A,
B, and C to Foo.Bar.Baz: your syntax would not require braces.


> It’s important to note that indentation is one particular style.  LLVM
> code style, in particular, chooses not to indent after namespace
> declarations.  This issue also crops up when dealing with nested type
> declarations, and I distinctly remember it not being a big enough deal to
> "fix this" at the time when a proposal to “flatten” these declaration was
> brought up.
>

Mine is not a critique of the syntax itself; I don't particularly care
about indents, nor do I mind not indenting namespaces.

What I'm saying is, you would not have chosen to require braces if your
proposed feature were aimed at making the grouping of files into submodules
as simple as possible. You chose to accommodate grouping lines using the
same syntax as grouping files over the simplest design for grouping files.
Make no mistake, this promotes one use over another.

- Because some lines of code necessarily precede some other lines of code,
> it makes sense to declare the first group using `module` and to extend that
> with the second group using `extension`. However, because a file of code
> does not necessarily precede another file of code, it is arbitrary which
> file is surrounded with a `module` declaration and which one is surrounded
> with an `extension` declaration.
>
>
> Absolutely.  But it is similarly arbitrary which public APIs are exposed
> in a type declaration and which are exposed in an extension declaration.
>

Not entirely, no. Stored properties must be in the type declaration. Enum
cases must be in the type declaration. Perhaps you regard these as
temporary inconveniences of the current grammar; I see them as quite
reasonable ways to give some consistency as to what's written where in a
language where types can be retroactively extended. In a very real sense,
you must read the type declaration before you read the extensions in order
to understand the latter. By comparison, there is nothing that must be in
your proposed module declaration.


> My hope is that the module declaration itself will become the
> one-stop-shop for re-exports and general public bookkeeping just as
> aggregate declarations are today.  Module extensions exist to accommodate
> users that wish to break related functionality across files or into
> separate independent regions within the same file for the same reasons type
> extensions exist.
>

Indeed, that you phrase it this way supports Nevin's argument. _Module
extensions_ exist to accommodate his use case; however, his use case
(which, mind you, is what I think most people are thinking of when it comes
to submodules, given previous threads on this topic) isn't the raison
d'etre for your submodule proposal. Quite simply, a 

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

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 9:13 PM, Xiaodi Wu  wrote:
> 
> On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
>> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> 
>> To my mind, any submodule system for Swift should be designed to relieve the 
>> pressure for long files, and make it easy to group tightly related files 
>> into a single unit with shared visibility. That way developers can easily 
>> organize their code into smaller files while utilizing Swift’s pattern of 
>> providing protocol conformances in extensions and keeping implementation 
>> details hidden from the rest of the module at large.
>> 
> 
> Wonderful, because that’s absolutely supported by this proposal.  To group 
> tightly related files into a single unit, simply declare a submodule for them 
> and extend it in each of your related files.
> 
> It's supported, but it isn't first-class. By this I mean: there are two 
> distinguishable uses supported by your proposal, lumped together by the fact 
> that they are both about grouping units of code together. Put crudely, one 
> use case is grouping lines of code, while the other is about grouping files 
> of code. The merits of supporting both have already been debated in this 
> discussion. The issue I'll touch on is supporting both with the same syntax. 
> The chief drawbacks here are:
> 

What exactly would be required to make it first class?  Referencing file names 
in the module declaration?

> - It makes sense to use braces to group lines of code, but it makes no sense 
> to use braces to group files of code; this just causes entire files to be 
> indented.
> 

If braces aren’t used to demarcate scopes, nesting modules becomes ambiguous.  
It’s important to note that indentation is one particular style.  LLVM code 
style, in particular, chooses not to indent after namespace declarations.  This 
issue also crops up when dealing with nested type declarations, and I 
distinctly remember it not being a big enough deal to "fix this" at the time 
when a proposal to “flatten” these declaration was brought up.

> - Because some lines of code necessarily precede some other lines of code, it 
> makes sense to declare the first group using `module` and to extend that with 
> the second group using `extension`. However, because a file of code does not 
> necessarily precede another file of code, it is arbitrary which file is 
> surrounded with a `module` declaration and which one is surrounded with an 
> `extension` declaration.

Absolutely.  But it is similarly arbitrary which public APIs are exposed in a 
type declaration and which are exposed in an extension declaration.  My hope is 
that the module declaration itself will become the one-stop-shop for re-exports 
and general public bookkeeping just as aggregate declarations are today.  
Module extensions exist to accommodate users that wish to break related 
functionality across files or into separate independent regions within the same 
file for the same reasons type extensions exist.


> 
> Any variables defined with `internal` access will be visible across those 
> files to those extensions and only those extensions (see the section on 
> access control and modules).  Any variables declared fileprivate or private 
> will, obviously, not be visible across these files.  As an example:
> 
> // FooUtilities.swift
> //
> // -module-name=Foo
> // module Foo {
> // Defines Foo.Utilities
> module Utilities {
>   public func exportableOutsideThisSubmodule() {}
>   func visibleInThisSubmodule() {}
>   private func invisibleToOtherFiles() {}
> }
> //}
> 
> // FooUtilities+MoreUtilities.swift
> extension Utilities {
>   private func privateHelper() {
> visibleInThisSubmodule()
>   }
> }
> 
> I’m not sure where you got the impression that we were just trying to make 
> another fileprivate happen.
> 
>> 
>> Nevin
>> ___
>> 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] [Proposal][Discussion] Modular Swift

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 8:15 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It has been my hope that a lightweight module system will remove the need
> for `private` *and* `fileprivate`.
>
>
> I really doubt it will. `private`/`fileprivate` works because you can also
> access `internal` at the same time.
>
> What I mean by that is, think about code like this:
>
> // Foo.swift
> public class Foo {
> public init() { … }
>
> func doBar() -> Quux {
> return helper(in: randomRange())
> }
>
> private func helper(in range: Range) -> Quux {
> …
> }
> }
>
> // Bar.swift
> public class Bar {
> public static let shared = Bar()
>
> func baz(with foo: Foo) {
> let quux = foo.doBar()
> process(quux)
> }
>
> private func process(_ quux: Quux) {
> …
> }
> }
>
> These classes have `public` APIs that are externally visible, `internal`
> APIs for communicating with each other, and `private` APIs for
> implementation details. Now try to reproduce the same design with
> submodules and `public`/`internal` only:
>
> public import MyMod.Foo
> public import MyMod.Bar
>
> module Foo {
> public class Foo {
> public init() { … }
>
>
> ??? func doBar() -> Quux {
> return helper(in: randomRange())
> }
>
> func helper(in range: Range) -> Quux {
> …
> }
> }
> }
>
> // Bar.swift
> module Bar {
> public class Bar {
> public static let shared = Bar()
>
> ??? func baz(with foo: Foo) {
> let quux = foo.doBar()
> process(quux)
> }
>
> func process(_ quux: Quux) {
> …
> }
> }
> }
>
> The `doBar()` and `baz()` methods have to be either exposed to third
> parties or kept away from yourself. That's just not viable.
>
>
> If they must communicate, they can be a part of the same (sub)module.
> This makes filling in these annotations trivial.  Nobody actually uses
> modules to wall off their own APIs from themselves like this, they use
> submodules to encapsulate the internal parts and surface public APIs in the
> parent.
>

I think you'll find a ton of people on this list who would want to use
submodules precisely to wall off their own APIs from themselves. Witness
the hundreds of messages about new syntax to do just that.


>
> module Bar {
>
> public class Foo {
>
> public init() { … }
>
>
>
> internal func doBar() -> Quux {
>
> return helper(in: randomRange())
>
> }
>
>
> internal func helper(in range: Range) -> Quux {
>
> …
>
> }
>
> }
>
> }
>
>
> // Bar.swift
>
> extension Bar {
>
> public class Bar {
>
> public static let shared = Bar()
>
>
> internal func baz(with foo: Foo) {
>
> let quux = foo.doBar()
>
> process(quux)
>
> }
>
>
> internal func process(_ quux: Quux) {
>
> …
>
> }
>
> }
> }
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 7:46 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> It has been my hope that a lightweight module system will remove the need 
>> for `private` *and* `fileprivate`.
> 
> I really doubt it will. `private`/`fileprivate` works because you can also 
> access `internal` at the same time.
> 
> What I mean by that is, think about code like this:
> 
>   // Foo.swift
>   public class Foo {
>   public init() { … }
> 
>   func doBar() -> Quux {
>   return helper(in: randomRange())
>   }
> 
>   private func helper(in range: Range) -> Quux {
>   …
>   }
>   }
> 
>   // Bar.swift
>   public class Bar {
>   public static let shared = Bar()
> 
>   func baz(with foo: Foo) {
>   let quux = foo.doBar()
>   process(quux)
>   }
>   
>   private func process(_ quux: Quux) {
>   …
>   }
>   }
> 
> These classes have `public` APIs that are externally visible, `internal` APIs 
> for communicating with each other, and `private` APIs for implementation 
> details. Now try to reproduce the same design with submodules and 
> `public`/`internal` only:
> 
>   public import MyMod.Foo
>   public import MyMod.Bar
> 
>   module Foo {
>   public class Foo {
>   public init() { … }
> 
> 
>   ??? func doBar() -> Quux {
>   return helper(in: randomRange())
>   }
> 
>   func helper(in range: Range) -> Quux {
>   …
>   }
>   }
>   }
> 
>   // Bar.swift
>   module Bar {
>   public class Bar {
>   public static let shared = Bar()
>   
>   ??? func baz(with foo: Foo) {
>   let quux = foo.doBar()
>   process(quux)
>   }
>   
>   func process(_ quux: Quux) {
>   …
>   }
>   }
>   }
> 
> The `doBar()` and `baz()` methods have to be either exposed to third parties 
> or kept away from yourself. That's just not viable.
> 

If they must communicate, they can be a part of the same (sub)module.  This 
makes filling in these annotations trivial.  Nobody actually uses modules to 
wall off their own APIs from themselves like this, they use submodules to 
encapsulate the internal parts and surface public APIs in the parent.

module Bar {
public class Foo {
public init() { … }


internal func doBar() -> Quux {
return helper(in: randomRange())
}

internal func helper(in range: Range) -> Quux {
…
}
}
}

// Bar.swift
extension Bar {
public class Bar {
public static let shared = Bar()

internal func baz(with foo: Foo) {
let quux = foo.doBar()
process(quux)
}

internal func process(_ quux: Quux) {
…
}
}
}

> -- 
> 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] [Proposal][Discussion] Modular Swift

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 7:59 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To my mind, any submodule system for Swift should be designed to relieve
> the pressure for long files, and make it easy to group tightly related
> files into a single unit with shared visibility. That way developers can
> easily organize their code into smaller files while utilizing Swift’s
> pattern of providing protocol conformances in extensions and keeping
> implementation details hidden from the rest of the module at large.
>
>
> Wonderful, because that’s absolutely supported by this proposal.  To group
> tightly related files into a single unit, simply declare a submodule for
> them and extend it in each of your related files.
>

It's supported, but it isn't first-class. By this I mean: there are two
distinguishable uses supported by your proposal, lumped together by the
fact that they are both about grouping units of code together. Put crudely,
one use case is grouping lines of code, while the other is about grouping
files of code. The merits of supporting both have already been debated in
this discussion. The issue I'll touch on is supporting both with the same
syntax. The chief drawbacks here are:

- It makes sense to use braces to group lines of code, but it makes no
sense to use braces to group files of code; this just causes entire files
to be indented.

- Because some lines of code necessarily precede some other lines of code,
it makes sense to declare the first group using `module` and to extend that
with the second group using `extension`. However, because a file of code
does not necessarily precede another file of code, it is arbitrary which
file is surrounded with a `module` declaration and which one is surrounded
with an `extension` declaration.

In both of these cases, your proposal has chosen to accommodate grouping
lines of code over the ergonomics of grouping files of code. Therefore,
while Nevin's use case is "absolutely supported by this proposal," I agree
with him that your choices promote something else entirely.


Any variables defined with `internal` access will be visible across those
> files to those extensions and only those extensions (see the section on
> access control and modules).  Any variables declared fileprivate or private
> will, obviously, not be visible across these files.  As an example:
>
> // FooUtilities.swift
> //
> // -module-name=Foo
> // module Foo {
> // Defines Foo.Utilities
> module Utilities {
>   public func exportableOutsideThisSubmodule() {}
>   func visibleInThisSubmodule() {}
>   private func invisibleToOtherFiles() {}
> }
> //}
>
> // FooUtilities+MoreUtilities.swift
> extension Utilities {
>   private func privateHelper() {
> visibleInThisSubmodule()
>   }
> }
>
> I’m not sure where you got the impression that we were just trying to make
> another fileprivate happen.
>
>
> Nevin
> ___
> 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] [Proposal][Discussion] Modular Swift

[Robert Widmann via swift-evolution]

> On Feb 21, 2017, at 8:00 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 20, 2017, at 5:56 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> The semantics of some existing access control modifiers shall also be 
>> extended to support module declarations:
>> 
>>  • open and public declarations are exported by a module for consumption 
>> by clients of the module.
>>  • internal declarations scope over the entire module and any derived 
>> submodules.
> 
> If I'm reading this correctly, you're proposing that the `internal` APIs in a 
> submodule should *not* be accessible to enclosing modules. I also don't see 
> any indication that you can control who is allowed to import a particular 
> submodule.
> 
> That means that, if you use a submodule to encapsulate internal state, the 
> APIs that are available to the parent module are *also* available to any 
> rando who feels like importing your submodule. I don't think that's going to 
> be a tenable design.

If the state is truly internal, and you are using internal access control, this 
is impossible.  The internal state cannot cross the module boundary unless it 
is marked public.  If a “random” feels like importing my submodule, they will 
not have access to any symbols.

> 
> (I have a couple other objections—I think the keyword ought to be `submodule` 
> if you don't need a top-level `module` declaration, I think there's a lot to 
> be said for a single declaration covering the entire file, and I'm pretty 
> iffy on this entire approach anyway—but this seems like the most serious 
> problem of the bunch.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
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 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> To my mind, any submodule system for Swift should be designed to relieve the 
> pressure for long files, and make it easy to group tightly related files into 
> a single unit with shared visibility. That way developers can easily organize 
> their code into smaller files while utilizing Swift’s pattern of providing 
> protocol conformances in extensions and keeping implementation details hidden 
> from the rest of the module at large.
> 

Wonderful, because that’s absolutely supported by this proposal.  To group 
tightly related files into a single unit, simply declare a submodule for them 
and extend it in each of your related files.  Any variables defined with 
`internal` access will be visible across those files to those extensions and 
only those extensions (see the section on access control and modules).  Any 
variables declared fileprivate or private will, obviously, not be visible 
across these files.  As an example:

// FooUtilities.swift
//
// -module-name=Foo
// module Foo {
// Defines Foo.Utilities
module Utilities {
  public func exportableOutsideThisSubmodule() {}
  func visibleInThisSubmodule() {}
  private func invisibleToOtherFiles() {}
}
//}

// FooUtilities+MoreUtilities.swift
extension Utilities {
  private func privateHelper() {
visibleInThisSubmodule()
  }
}

I’m not sure where you got the impression that we were just trying to make 
another fileprivate happen.

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

[Zach Waldowski via swift-evolution]

I agree with Nevin’s points in large strokes, but I don’t think large files are 
the end of the world. I think an important takeaway idea from all the access 
control threads is that we need not provide facilities in the language to 
support antipatterns; we should more focus on how to encourage good patterns 
better.

On the face of it, I’m excited by the proposal; even if this isn’t the answer, 
we should seek to go down any road that removes fileprivate (and I mean remove 
- not just a new spelling) but preserves aspect the feature to please whatever 
it is that people like about that feature.

> On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> This proposal is definitely *not* what I want from a submodule system, 
> because it will exacerbate the problem of developers stuffing large amounts 
> of code into a single file.
> 
> The “fileprivate” keyword already encourages long files, because there is no 
> way to split up related components into separate files while retaining 
> encapsulation. And scope-based “private” is even worse of an offender, 
> because it requires nesting code inside the same *type declaration*, so you 
> can’t even benefit from extensions.
> 
> To my mind, any submodule system for Swift should be designed to relieve the 
> pressure for long files, and make it easy to group tightly related files into 
> a single unit with shared visibility. That way developers can easily organize 
> their code into smaller files while utilizing Swift’s pattern of providing 
> protocol conformances in extensions and keeping implementation details hidden 
> from the rest of the module at large.
> 
> For example, one possible design would enable us to replace both “private” 
> and “fileprivate” with a single new access level—probably spelled “private— 
> which restricts visibility to just the current submodule. That way it 
> provides all the benefits of “fileprivate” (implementation hiding and the 
> ability to use extensions) while also allowing code to be placed in separate 
> files rather than one large file.
> 
> Nevin
> ___
> 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

[Colin Barrett via swift-evolution]

On Sun, Feb 19, 2017 at 2:34 PM Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> Now that I think about it, generic throws does not exactly cover rethrows.
> Firstly, rethrows has semantic information that function itself does not
> throw—it would be lost.
>

That's not true. Parametric polymorphism guarantees that rethrows and
polymorphic throw are the same.

For example, you can prove that as a consequence of parametricity that
there is only one (pure) function in the of the set of all functions with
the type ``forall A. A -> A'' and furthermore that it is the identity
function.

The intuition behind this is that you (meaning the fiction; imagine being a
function!) cannot construct your own value of "A" since you don't have any
information about what "A" is. The only place to get an "A" is from your
argument.

Secondly, rethrows allows a function with multiple throwing function
> parameters to become non-throwing iff all the arguments are non-throwing.
> How would you express it with generics?
> In the proposal, in this case you are required to provide a non-generic
> supertype of all used error types. This type can’t just turn into Never
> automatically.
>
> One solution would be to retain rethrows as an additional attribute.
> It would help with semantic information, and resulting error will be able
> to turn into Never as a special case—now that we know, that this function
> doesn’t throw that error itself.
>
> 2017-02-19 0:16 GMT+03:00 Martin Waitz :
>
>
> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution <
> swift-evolution@swift.org>:
>
> Thank you for taking the time to put this proposal together Anton!  I
> really want to see typed throws make it into Swift 4.  This will be a very
> nice feature to have.
>
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by
> making every function have an error type which is by default `Never` for
> non-throwing functions and `Error` for throwing functions that do not
> specify an error type.
>
> I want to urge you to consider updating the proposal to take this
> direction now rather than later.  This is a breaking change which means the
> longer we wait the harder it is to justify.  In fact, I think incorporating
> the breaking change could increase the chances of it being accepted for
> Swift 4.  Without that it is a purely additive change and those are not
> being given priority in the Swift 4 release.
>
>
> Seconded.
> With typed throwing function parameters, it makes a lot of sense to be
> able to specify the rethrown type, based on the function given as parameter.
>
> ​
> ___
> 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

[Nevin Brackett-Rozinsky via swift-evolution]

This proposal is definitely *not* what I want from a submodule system,
because it will exacerbate the problem of developers stuffing large amounts
of code into a single file.

The “fileprivate” keyword already encourages long files, because there is
no way to split up related components into separate files while retaining
encapsulation. And scope-based “private” is even worse of an offender,
because it requires nesting code inside the same *type declaration*, so you
can’t even benefit from extensions.

To my mind, any submodule system for Swift should be designed to relieve
the pressure for long files, and make it easy to group tightly related
files into a single unit with shared visibility. That way developers can
easily organize their code into smaller files while utilizing Swift’s
pattern of providing protocol conformances in extensions and keeping
implementation details hidden from the rest of the module at large.

For example, one possible design would enable us to replace both “private”
and “fileprivate” with a single new access level—probably spelled
“private— which restricts visibility to just the current submodule. That
way it provides all the benefits of “fileprivate” (implementation hiding
and the ability to use extensions) while also allowing code to be placed in
separate files rather than one large file.

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

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

[Colin Barrett via swift-evolution]

Pardon for the misfire; I switched to a new mail client recently and it
didn't behave as I was expecting.

I was intending to reply to Jordan's comments upthread about popCount.

On Tue, Feb 21, 2017 at 7:28 PM Colin Barrett 
wrote:

> I'm not sure exactly where the bar is, but chiming in that recently, in
> implementing generic succinct data structures as an exercise, I needed to
> define exactly this operation generically.
>
> -Colin
> On Tue, Feb 21, 2017 at 6:29 PM Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes
>
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Colin Barrett via swift-evolution]

I'm not sure exactly where the bar is, but chiming in that recently, in
implementing generic succinct data structures as an exercise, I needed to
define exactly this operation generically.

-Colin
On Tue, Feb 21, 2017 at 6:29 PM Max Moiseev via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs
> through February 25, 2017. This proposal was accepted for Swift 3, but was
> not implemented in time for the release. The revised proposal is available
> here:
>
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>
>
> Well worth while. Few nit picks:
>
>   1. Number.init? Description should say BinaryInteger not floating-point.
>
> I’ll update the proposal.
>
>   2. Number should document that mutating versions of operators can
> overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
>
> Documentation changes noted. Thanks!
>
>   4. SignedNumber, it is weird that `signum` is a function when other
> similar things, e.g. `magnitude`, are properties.
>
> I think of it as: magnitude is something the number ‘has’ whereas signum
> is a completely new thing of the same type.
>
>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols
> and provide default implementations, otherwise they are difficult to find.
>
> They are defined as protocol extensions, therefore they should be
> discoverable through completion and in the generated source code. Or what
> do you mean by ‘difficult to find’?
>
> Thanks for the feedback!
>
>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes, the current design has not served my purpose on more than one
> occasion
>
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes
>
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Yes, this proposal is similar to what other languages provide, e.g. Scala.
> In Scala however they tackle the `conversion problem as well in their
> `traits heirarchy. I guess this could be added at a later date.
>
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Read the proposal, have used similar features in other languages, and have
> had trouble with Swift's current heirarchy.
> --
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> On Feb 21, 2017, at 2:27 AM, Joanna Carter  
> wrote:
> 
> But in the Swift world, we now have the ability to extend almost any type, 
> except Any and AnyObject, which appear to be protected by some deep and dark 
> mechanism within the compiler.  So, just as those two protocols cannot be 
> extended, should we not be looking at some generally available mechanism to 
> prevent extensibility of any type?
> 
> And, I am not talking visibility here, just extensibility ; somehow those two 
> concerns are often conflated and, I believe, this is the cause of much of the 
> "lively" discussion on visibility specifiers.

This is imho more of an issue with ABI and resiliency. If I can create an 
extension which adds a method to a type, and that type gains a method with that 
same signature in a later release, what is the behavior?

> 
>> 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
> 
> Indeed. I do wonder if some folks approach visibility control as an exercise 
> in "what can I see" whereas, demonstrated by C++ friends, it becomes obvious 
> that it is more about "what do I want to allow to be seen"
> 
> Is there not a value in forking this discussion into which keywords are truly 
> about visibility control and which are about extensibility control?

Possibly; they are two axes. However, I’m hoping that new access modifiers 
(including possible submodule functionality) + extensibility modifiers are 
considered holistically. 

For instance, if there is a feature that allows something comparable to 
‘friend’ level access, a restrictive private makes a lot more sense than one 
with exceptions allowing access to subtypes, within the same file, to 
extensions, etc. A restrictive, scoped private would be what you use to protect 
the invariants of your type, with less protected methods given to allow 
extensions and internal modification safely.

But without a submodule or similar access level, we need a “fileprivate” level 
access (renamed to ‘private’ or not) to make sure code needing a higher level 
of access can get it, by being embedded in the same file.

> OK, how does this sound?
> 
> Extend the 'final' concept, currently used only in classes, to protect any, 
> non-protocol, type from being extended.

The extension mechanism, both being able to add new methods and to conform an 
existing class to a protocol retroactively, is absurdly powerful. It doesn’t 
offer any privileged manipulation of types today that would give a safety 
related reason to restrict it. I’d be reluctant to let someone take that away 
from me personally without a strong language-level justification (such as 
needing to restrict it partially to meet ABI/resiliency requirements)

-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

[Nevin Brackett-Rozinsky via swift-evolution]

I think entities declared as “internal” should be visible throughout the
entire *module* just as they are today. In particular, if I write “struct
Foo {}” inside a submodule, then Foo should have internal visibility (the
default when no access level is specified) and thus should be available to
the entire module.

Similarly, if I write “public struct Bar {}” inside a submodule, then Bar
should be exported from the module and available to client code. In other
words, the submodule should exist to *organize* code, not to change its
meaning.

Moreover, the ongoing access level discussions elsewhere on the list make
clear that many people believe there should be just one visibility more
restricted than “internal” (which of course should be named “private”). If
we go that route, then “private” would mean “visible in this submodule
only”. For files which are not in a submodule this acts like “fileprivate”,
and for files which *are* in a submodule it means they can share their
implementation details with closely related code (usually types and
extensions) while allowing that code to be in separate files as appropriate.

That is most of what I want out of submodules: to provide all the benefits
of Swift-2-era “private” without requiring that everything be stuffed
inside one single file. For all other purposes a submodule would be
transparent, it just lets you split up a large file along its natural
divisions. Consequently, I see no need or purpose for nested submodules,
because a submodule simply “acts like” a single file.

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

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

[Max Moiseev via swift-evolution]

> On Feb 21, 2017, at 3:05 PM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> The re-review of SE-0104 "Protocol-oriented integers" begins now and runs 
> through February 25, 2017. This proposal was accepted for Swift 3, but was 
> not implemented in time for the release. The revised proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> 
> 
> 
>   • What is your evaluation of the proposal?
> 
> Well worth while. Few nit picks:
> 
>   1. Number.init? Description should say BinaryInteger not floating-point.
I’ll update the proposal.

>   2. Number should document that mutating versions of operators can overflow.
>   3. SignedNumber should document that negate and unary `-` can overflow.
Documentation changes noted. Thanks!

>   4. SignedNumber, it is weird that `signum` is a function when other similar 
> things, e.g. `magnitude`, are properties.
I think of it as: magnitude is something the number ‘has’ whereas signum is a 
completely new thing of the same type.

>   5. Not worth representing `DoubleWidth` as an enumeration, it is obscure 
> and therefore will only confuse people.
>   6. It would be better to put the 'extra' operations into the protocols and 
> provide default implementations, otherwise they are difficult to find. 
They are defined as protocol extensions, therefore they should be discoverable 
through completion and in the generated source code. Or what do you mean by 
‘difficult to find’?

Thanks for the feedback!

> 
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
> 
> Yes, the current design has not served my purpose on more than one occasion 
> 
>   • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes
> 
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
> 
> Yes, this proposal is similar to what other languages provide, e.g. Scala. In 
> Scala however they tackle the `conversion problem as well in their `traits 
> heirarchy. I guess this could be added at a later date.
> 
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> Read the proposal, have used similar features in other languages, and have 
> had trouble with Swift's current heirarchy. 
> -- 
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Patrick Pijnappel via swift-evolution]

 Arbitrary sized signed -1 can have different popcount depending on the
> underlying buffer length (if there is a buffer) even if it’s the same type
> and the same value. Same with leading zeros, as the underlying
> representation is unbounded on the more significant side.


Sensible, why didn't I think of that :).


> Also, arguably shouldn't it be numberOfLeadingZeroBits?
>>
> There is countLeadingZeroBits for that.


I'm mean whether leadingZeroBits should be named numberOfLeadingZeroBits, I
don't see any countLeadingZeroBits.

Joe recently sent an email on behalf of Dave to start this very discussion.


Yeah, that's the one I was responding to! I'm was talking more concretely
about language support.

On Wed, Feb 22, 2017 at 10:18 AM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Feb 21, 2017, at 5:39 PM, Dave Abrahams  wrote:
> Sent from my moss-covered three-handled family gradunza
>
> On Feb 21, 2017, at 10:08 AM, John McCall  wrote:
>
>
> On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Sent from my moss-covered three-handled family gradunza
>
> On Feb 21, 2017, at 9:04 AM, Jordan Rose  wrote:
>
> [Proposal: https://github.com/apple/swift-evolution/blob/master/
> proposals/0104-improved-integers.md]
>
> Hi, Max (and Dave). I did have some questions about this revision:
>
> Arithmetic and SignedArithmetic protocols have been renamed
> to Number and SignedNumber.
>
>
> What happens to NSNumber here? It feels like the same problem as Character
> and (NS)CharacterSet.
>
>
> Endian-converting initializers and properties were added to
> the FixedWidthInteger protocol.
>
>
> This is the thing I have the biggest problem with. Endian conversions
> aren't numeric operations, and you can't meaningfully mix numbers of
> different endianness. That implies to me that numbers with different
> endianness should have different types. I think there's a design to explore
> with LittleEndian and BigEndian, and explicitly using those types
> whenever you need to convert.
>
>
> I disagree. Nobody actually wants to compute with numbers in the wrong
> endianness for the machine. This is just used for corrections at the ends
> of wire protocols, where static type has no meaning.
>
>
> I think Jordan's suggestion is not that LittleEndian or
> BigEndian would be artihmetic types, but that they would be different
> types, primarily opaque, that can be explicitly converted to/from Int.
> When you read something off the wire, you ask for the bytes as one of those
> two types (as appropriate) and then convert to the underlying type.
> Ideally, Int doesn't even conform to the "this type can be read off the
> wire" protocol, eliminating the common mistake of serializing something
> using native endianness.
>
>
> Still, you have to implement those somehow. How do you do that without
> this functionality in the Integer API?  Turtles have to stop somewhere. We
> could de-emphasize these APIs by making them static, but "x." already
> *is* a place of reduced emphasis for integers.
>
>
> That's fair.  I don't object to having methods for these as long as they
> aren't the encouraged way of working with byte-swapped integers.
>
> John.
>
>
> John.
>
>
> Here's a sketch of such a thing:
>
> struct LittleEndian {
>   private var storage: Value
>
>   public var value: Value {
> #if little_endian
> return storage
> #else
> return swapBytes(storage)
> #endif
>   }
>
>   public var bitPattern: Value {
> return storage
>   }
>
>   public var asBigEndian: BigEndian {
> return BigEndian(value: self.value)
>   }
>
>   public init(value: Value) {
> #if little_endian
> storage = value
> #else
> storage = swapBytes(value)
> #endif
>   }
>
>   public init(bitPattern: Value) {
> storage = bitPattern
>   }
> }
>
>
> I'm not saying this is the *right* solution, just that I suspect adding
> Self-producing properties that change endianness is the wrong one.
>
>   /// The number of bits equal to 1 in this value's binary representation.
>   ///
>   /// For example, in a fixed-width integer type with a `bitWidth` value
> of 8,
>   /// the number 31 has five bits equal to 1.
>   ///
>   /// let x: Int8 = 0b0001_
>   /// // x == 31
>   /// // x.popcount == 5
>   var popcount: Int { get
>  }
>
>
> Is this property actually useful enough to put into a protocol? I know
> it's defaulted, but it's already an esoteric operation; it seems unlikely
> that one would need it in a generic context. (It's also definable for
> arbitrary UnsignedIntegers as well as arbitrary FixedWidthIntegers.)
>
>
> The whole point is that you want to dispatch down to an LLVM instruction
> for this and not rely on the optimizer to collapse your loop into one.
>
>
> (I'm also still not happy with the non-Swifty name, but I see
> "populationCount" or "numberOfOneBits" would probably be worse.)
>

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

[Howard Lovatt via swift-evolution]

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

>
> https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md
>
>
>- What is your evaluation of the proposal?
>
> Good idea. A good compromise between backward compatibility and usability.

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

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

>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> Yes, I have found other dictionary implementations more performance and
more flexible (e.g. Java's Map)


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

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

[John McCall via swift-evolution]

> On Feb 21, 2017, at 5:39 PM, Dave Abrahams  wrote:
> Sent from my moss-covered three-handled family gradunza
> 
> On Feb 21, 2017, at 10:08 AM, John McCall  > wrote:
> 
>> 
>>> On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
>>> On Feb 21, 2017, at 9:04 AM, Jordan Rose >> > wrote:
>>> 
 [Proposal: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
  
 ]
 
 Hi, Max (and Dave). I did have some questions about this revision:
 
> Arithmetic and SignedArithmetic protocols have been renamed to Number and 
> SignedNumber.
 
 What happens to NSNumber here? It feels like the same problem as Character 
 and (NS)CharacterSet.
 
 
> Endian-converting initializers and properties were added to the 
> FixedWidthInteger protocol.
 
 This is the thing I have the biggest problem with. Endian conversions 
 aren't numeric operations, and you can't meaningfully mix numbers of 
 different endianness. That implies to me that numbers with different 
 endianness should have different types. I think there's a design to 
 explore with LittleEndian and BigEndian, and explicitly using 
 those types whenever you need to convert.
>>> 
>>> I disagree. Nobody actually wants to compute with numbers in the wrong 
>>> endianness for the machine. This is just used for corrections at the ends 
>>> of wire protocols, where static type has no meaning.
>> 
>> I think Jordan's suggestion is not that LittleEndian or BigEndian 
>> would be artihmetic types, but that they would be different types, primarily 
>> opaque, that can be explicitly converted to/from Int.  When you read 
>> something off the wire, you ask for the bytes as one of those two types (as 
>> appropriate) and then convert to the underlying type.  Ideally, Int doesn't 
>> even conform to the "this type can be read off the wire" protocol, 
>> eliminating the common mistake of serializing something using native 
>> endianness.
> 
> Still, you have to implement those somehow. How do you do that without this 
> functionality in the Integer API?  Turtles have to stop somewhere. We could 
> de-emphasize these APIs by making them static, but "x." already is a 
> place of reduced emphasis for integers.

That's fair.  I don't object to having methods for these as long as they aren't 
the encouraged way of working with byte-swapped integers.

John.

> 
>> John.
>> 
>>> 
 Here's a sketch of such a thing:
 
 struct LittleEndian {
   private var storage: Value
 
   public var value: Value {
 #if little_endian
 return storage
 #else
 return swapBytes(storage)
 #endif
   }
 
   public var bitPattern: Value {
 return storage
   }
 
   public var asBigEndian: BigEndian {
 return BigEndian(value: self.value)
   }
 
   public init(value: Value) {
 #if little_endian
 storage = value
 #else
 storage = swapBytes(value)
 #endif
   }
 
   public init(bitPattern: Value) {
 storage = bitPattern
   }
 }
 
 I'm not saying this is the right solution, just that I suspect adding 
 Self-producing properties that change endianness is the wrong one.
 
>   /// The number of bits equal to 1 in this value's binary representation.
>   ///
>   /// For example, in a fixed-width integer type with a `bitWidth` value 
> of 8,
>   /// the number 31 has five bits equal to 1.
>   ///
>   /// let x: Int8 = 0b0001_
>   /// // x == 31
>   /// // x.popcount == 5
>   var popcount: Int { get
>  }
 
 Is this property actually useful enough to put into a protocol? I know 
 it's defaulted, but it's already an esoteric operation; it seems unlikely 
 that one would need it in a generic context. (It's also definable for 
 arbitrary UnsignedIntegers as well as arbitrary FixedWidthIntegers.)
>>> 
>>> The whole point is that you want to dispatch down to an LLVM instruction 
>>> for this and not rely on the optimizer to collapse your loop into one. 
>>> 
 
 (I'm also still not happy with the non-Swifty name, but I see 
 "populationCount" or "numberOfOneBits" would probably be worse.)
 
 
 Thanks in advance,
 Jordan
>>> ___
>>> 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 16, 2017, at 09:03, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> # Pure Functions
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md)
> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Some functions are, essentially, only meant to be transformations of their 
> input and–as such–do not and should not reference any variables other than 
> those passed in. These same functions are not meant to have any effects other 
> than the aforementioned transformation of input. Currently, Swift cannot 
> assist the developer and confirm that any given function is one of these 
> 'pure' functions. To facilitate this, this proposal adds syntax to signal 
> that a function is 'pure'.
> 
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
> 
> ## Motivation
> 
> Consider the following example where `_computeNullability(of:)` is meant to 
> create its output solely based on the provided recognizer.
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real 
> potential to accidentally reference `self` in its body and the mistake, 
> depending on circumstance, can be terribly subtle. Converting 
> `_computeNullability(of:)` to a `static` function is an option but obfuscates 
> the fact that it is *only* to be called within `isNullable`.
> 
> 
> ## Proposed solution
> 
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
> function, the developer gains assurance from the tooling that it doesn't 
> reference anything or cause any side effects.
> 
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> 
> ## Detailed design
> 
> This proposal introduces a new annotation `=>`, which is to be accepted 
> everywhere `->` currently is. Members created using this kewyord must follow 
> the rules listed in the introduction.
> 
> ## Impact on existing code
> 
> This is an additive feature unless alternative 2 is chosen and, as such, 
> should not require an effect on existing code. It could be used to annotate 
> closures accepted by methods in the standard library such as `map`, `filter`, 
> and `reduce`. While this would fit well with their typical use, such a change 
> is not necessarily part of this proposal.
> 
> ## Alternatives considered
> 
> It should be noted that neither of these alternatives can remain consistent 
> for inline closures.
> 1. keyword `pfunc` (pronounciation: pifəŋk) for 'pure' functions. 
> 2. `proc` keyword for 'impure' functions and 'func' for 'pure' functions. 
> This would be a massively source breaking change and, as such, is unlikely to 
> have any feasibility. It is, however, the most clean semantically, in my 
> opinion.

Could we use pure functions as the basis of "type functions"? That is, 
functions that operate on, and return, types rather than variables. For 
example, the "N+P" part of the return type in:
func append  (lhs: Matrix, rhs: Matrix) -> Matrix {...}
(where M,N, and P all conform to "Length" or something, since Int literals 
can't be generic parameters yet.) Because something like that would come in 
real handy for matrix and vector types.

I know this feature would have to be a separate proposal... I was just thinking 
of potential applications of pure functions, since somebody was asking earlier 
in the thread.

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

True.
In my proposal I mention how NS_STRING_ENUM doesn't produce an swift enum.

So one solution is to merely "go the other way" which would produce what
Kevin N. suggested.

Is it not odd that that the objc version is so different from the swift
version?

Would it not be better to offer a somewhat similar API experience between
the two languages?

@objcstring would "promote" the swift enum to an objective-c class to make
the API experience similar.

I understand that maybe @objcstring is too niche to get its own annotation.
Instead @objc should become more powerful.

I think @objc should make an enum become a class with swift-enum like
abilities. This would allow enum functions to be bridged over to
objective-c as well.
On Tue, Feb 21, 2017 at 1:32 PM Michael Ilseman  wrote:

> A quick note addressing a misconception that you’ll want to clean up for a
> formal proposal:
>
> NS_[EXTENSIBLE_]STRING_ENUMs both generate Swift structs, the difference
> is only in the explicitness of the rawValue initializer. To use the “other
> direction” analogy, you’d similarly want them to apply for rawValue-ed
> structs alone. The reasons are the same: only the structs are
> layout-compatible because enums are integers.
>
> Once you go down this route, perhaps it doesn’t make sense to annotate the
> struct decls themselves anymore. Maybe you just want more @objc control
> over bridging the types. For example, maybe you want to introduce a feature
> so that static members that are layout-compatible with String are bridged
> as global strings with the supplied name.
>
>
>
>
> 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

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

[Howard Lovatt via swift-evolution]

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

>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>
> • What is your evaluation of the proposal?
>

Well worth while. Few nit picks:

  1. Number.init? Description should say BinaryInteger not floating-point.
  2. Number should document that mutating versions of operators can
overflow.
  3. SignedNumber should document that negate and unary `-` can overflow.
  4. SignedNumber, it is weird that `signum` is a function when other
similar things, e.g. `magnitude`, are properties.
  5. Not worth representing `DoubleWidth` as an enumeration, it is obscure
and therefore will only confuse people.
  6. It would be better to put the 'extra' operations into the protocols
and provide default implementations, otherwise they are difficult to find.

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

Yes, the current design has not served my purpose on more than one occasion

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

Yes

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

Yes, this proposal is similar to what other languages provide, e.g. Scala.
In Scala however they tackle the `conversion problem as well in their
`traits heirarchy. I guess this could be added at a later date.

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

Read the proposal, have used similar features in other languages, and have
had trouble with Swift's current heirarchy.
-- 
-- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Feb 21, 2017, at 2:04 PM, Karl Wagner  wrote:
> 
> 
>> On 21 Feb 2017, at 21:39, Max Moiseev > > wrote:
>> 
>> 
>>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> I assume the “SignedNumber” protocol is the same as the existing one in the 
>>> standard library. That is to say, Strideable.Stride will now conform to 
>>> Number and have operators.
>> SignedNumber will *not* be the same. It is just the same name.
>> Stride will have operators, yes. Strideable in general will not, unless it’s 
>> a _Pointer. (you can find the current implementation prototype here 
>> ).
> 
> Currently, it’s difficult to work with Strideable because you can calculate 
> distances between them (as type Strideable.Stride), but you can’t add those 
> distances because Strideable.Stride is only constrained to conform to 
> “SignedNumber”, which is a pretty useless protocol.
> 
> In the prototype, Strideable.Stride has now been changed, so it is 
> constrained to “SignedArithmetic” (which, apparently, is to be renamed 
> “SignedNumber”). So essentially, the existing SignedNumber has been 
> re-parented to “Number” and gains operations such as addition. That’s great!
Ah.. I see what you mean. Thanks for the explanation. I think we usually just 
used Bound : Strideable, Bound.Stride : SignedInteger, but yes, you’re right, 
it will be simpler now.

> I think it would be worth including Strideable in the “big picture” in the 
> proposal/manifesto, showing how it fits in..
That can be a valuable addition, indeed. Thanks!

> 
>>> 
>>> Also minor nitpick, would it be too onerous to require Number.Magnitude to 
>>> be Comparable? Currently it’s only Equatable and 
>>> ExpressibleByIntegerLiteral.
>> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it 
>> ends up being called), but the recursive constraints feature is missing, 
>> therefore we constrained it with the protocols that Arithmetic itself 
>> refines.
>> 
>> Why would you want Comparable?
>> 
>> Max
>> 
> 
> I suppose that leads me on to the question of why Number itself only requires 
> that conformers be (Equatable & ExpressibleByIntegerLiteral) and does not 
> require that they be Comparable.
> 
> If I must be able to create any “Number" out of thin air with an integer 
> literal, is it not reasonable to also require that I am able to compare two 
> instances?
> 
> Are there Number types which can’t be Comparable?


> 
> - Karl

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

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

[Jose Cheyo Jimenez via swift-evolution]

Sorry to beat this like a drum :

How is swift 3 extensibility harmful exactly? 

Do you have specific examples when extensibility was harmful in a project? 

This probably deserves its own thread if the examples are substantial. 




> On Feb 21, 2017, at 1:27 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
> 
>>> Le 21 févr. 2017 à 05:21, David Waite  a 
>>> écrit :
>>> 
>>> 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”.
> 
> Indeed, I could agree with that but…
> 
> Before 'open' was added to indicate extensibility of a publicly visible 
> class, we used to have 'public' to indicate that the class was visible 
> anywhere and 'final' to restrict inheritance/overriding.
> 
> With classes, 'final' was good enough to indicate that a type and/or its 
> members should not be extensible.
> 
> But in the Swift world, we now have the ability to extend almost any type, 
> except Any and AnyObject, which appear to be protected by some deep and dark 
> mechanism within the compiler.  So, just as those two protocols cannot be 
> extended, should we not be looking at some generally available mechanism to 
> prevent extensibility of any type?
> 
> And, I am not talking visibility here, just extensibility ; somehow those two 
> concerns are often conflated and, I believe, this is the cause of much of the 
> "lively" discussion on visibility specifiers.
> 
>> 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
> 
> Indeed. I do wonder if some folks approach visibility control as an exercise 
> in "what can I see" whereas, demonstrated by C++ friends, it becomes obvious 
> that it is more about "what do I want to allow to be seen"
> 
> Is there not a value in forking this discussion into which keywords are truly 
> about visibility control and which are about extensibility control?
> 
>> 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”?
> 
> This is somewhere where I have to bring up my learning and experience with 
> other languages. Albeit only with classes, private always meant what it said 
> on the tin - from outside of a class, it doesn't exist, don't touch!
> 
> Which is why I am very wary of reverting file scope to private.
> 
> 'fileprivate' is a keyword that allows, not extensibility but visibility.
> 
> Extensibility control for non-class types is more akin to using or not using 
> 'final' to control inheritance/overriding with classes.
> 
> Maybe, instead of looking at extending visibility by adding yet another 
> visibility specifier (extensible), we should be looking at adding a specifier 
> that limits extensibility for any type?
> 
> This would be additive and would have the advantage of not breaking so much 
> code.
> 
> OK, how does this sound?
> 
> Extend the 'final' concept, currently used only in classes, to protect any, 
> non-protocol, type from being extended.
> 
> That way, folks who are not so "purist" about access control can continue as 
> before, leaving those of us who want that control to be able to exercise it.
> 
> So, for example :
> 
> final struct DontExtendMe
> {
>  …
> }
> 
> extension DontExtendMe // error : final type cannot be extended
> {
>  …
> }
> 
> I am not suggesting that 'final' should be applicable to members of non-class 
> types. Members of class types should continue to be markable as 'final' for 
> inheritance control reasons.
> 
> --
> 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] [Draft] Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

Well-written as-is.

Overall, my feedback is that solution 2 should not be on the table (though
there are people who clamor for it), and not because I don't agree with it.
However, simply as a matter of following an appropriate process, solution 2
was originally proposed in SE-0025, fully considered, and modified by the
core team to the current design. One can disagree whether `scoped` is more
appropriate than `private` as a name for that access modifier, and one is
likely to say that `private` looks nicer than `fileprivate`, but that's
neither here nor there. The appropriateness or niceness of these terms is
unchanged from last year. Re-submitting SE-0025 cannot be the solution for
fixing SE-0025.


On Tue, Feb 21, 2017 at 12:58 AM, David Hart  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 

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

[Dave Abrahams via swift-evolution]

Sent from my moss-covered three-handled family gradunza

> On Feb 21, 2017, at 10:08 AM, John McCall  wrote:
> 
> 
>> On Feb 21, 2017, at 2:15 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my moss-covered three-handled family gradunza
>> 
>>> On Feb 21, 2017, at 9:04 AM, Jordan Rose  wrote:
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md]
>>> 
>>> Hi, Max (and Dave). I did have some questions about this revision:
>>> 
 Arithmetic and SignedArithmetic protocols have been renamed to Number and 
 SignedNumber.
>>> 
>>> What happens to NSNumber here? It feels like the same problem as Character 
>>> and (NS)CharacterSet.
>>> 
>>> 
 Endian-converting initializers and properties were added to the 
 FixedWidthInteger protocol.
>>> 
>>> This is the thing I have the biggest problem with. Endian conversions 
>>> aren't numeric operations, and you can't meaningfully mix numbers of 
>>> different endianness. That implies to me that numbers with different 
>>> endianness should have different types. I think there's a design to explore 
>>> with LittleEndian and BigEndian, and explicitly using those types 
>>> whenever you need to convert.
>> 
>> I disagree. Nobody actually wants to compute with numbers in the wrong 
>> endianness for the machine. This is just used for corrections at the ends of 
>> wire protocols, where static type has no meaning.
> 
> I think Jordan's suggestion is not that LittleEndian or BigEndian 
> would be artihmetic types, but that they would be different types, primarily 
> opaque, that can be explicitly converted to/from Int.  When you read 
> something off the wire, you ask for the bytes as one of those two types (as 
> appropriate) and then convert to the underlying type.  Ideally, Int doesn't 
> even conform to the "this type can be read off the wire" protocol, 
> eliminating the common mistake of serializing something using native 
> endianness.

Still, you have to implement those somehow. How do you do that without this 
functionality in the Integer API?  Turtles have to stop somewhere. We could 
de-emphasize these APIs by making them static, but "x." already is a place 
of reduced emphasis for integers. 

> John.
> 
>> 
>>> Here's a sketch of such a thing:
>>> 
>>> struct LittleEndian {
>>>   private var storage: Value
>>> 
>>>   public var value: Value {
>>> #if little_endian
>>> return storage
>>> #else
>>> return swapBytes(storage)
>>> #endif
>>>   }
>>> 
>>>   public var bitPattern: Value {
>>> return storage
>>>   }
>>> 
>>>   public var asBigEndian: BigEndian {
>>> return BigEndian(value: self.value)
>>>   }
>>> 
>>>   public init(value: Value) {
>>> #if little_endian
>>> storage = value
>>> #else
>>> storage = swapBytes(value)
>>> #endif
>>>   }
>>> 
>>>   public init(bitPattern: Value) {
>>> storage = bitPattern
>>>   }
>>> }
>>> 
>>> I'm not saying this is the right solution, just that I suspect adding 
>>> Self-producing properties that change endianness is the wrong one.
>>> 
   /// The number of bits equal to 1 in this value's binary representation.
   ///
   /// For example, in a fixed-width integer type with a `bitWidth` value 
 of 8,
   /// the number 31 has five bits equal to 1.
   ///
   /// let x: Int8 = 0b0001_
   /// // x == 31
   /// // x.popcount == 5
   var popcount: Int { get
  }
>>> 
>>> Is this property actually useful enough to put into a protocol? I know it's 
>>> defaulted, but it's already an esoteric operation; it seems unlikely that 
>>> one would need it in a generic context. (It's also definable for arbitrary 
>>> UnsignedIntegers as well as arbitrary FixedWidthIntegers.)
>> 
>> The whole point is that you want to dispatch down to an LLVM instruction for 
>> this and not rely on the optimizer to collapse your loop into one. 
>> 
>>> 
>>> (I'm also still not happy with the non-Swifty name, but I see 
>>> "populationCount" or "numberOfOneBits" would probably be worse.)
>>> 
>>> 
>>> Thanks in advance,
>>> Jordan
>> ___
>> 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] [Fake-Proposal] Remove enums with associated objects

[Tino Heth via swift-evolution]

Thanks for the thorough explanation - hope it will spawn some enum-proposals in 
the future ;-)

> This has been discussed several times in the past. If T is itself 
> Optional, then T | Void | Void == T | Void, meaning you can't safely use 
> Optional to model potential failure in any generic situation that could 
> itself produce Optional in normal circumstances.
In general, I'd consider this to be an advantage of union types:
Using try? with a function that may throw as well as return nil feels quite 
complicated to me, because I just would use "try" if I cared about wether an 
error happened or not. 
Luckily, I never encountered more than two levels of optionality, and I guess 
this won't happen often in real-world code.

> Having Optional not exist may seem superficially easy, but 
> generates a bunch of downstream complexity, since you now need ad-hoc rules 
> like "NSArrays can't contain nil".
I never questioned the rules of NSArray and NSNull... is this actually because 
id is like object | nil? (more or less rhetorical question - to tired to think 
it through :)

> It's no coincidence that so many languages grow multiple null-like values in 
> response to this situation—ObjC with NSNull; Javascript with null and undef; 
> VB with Null, Nothing, Missing, and None; and so on.
Does VB really have union types?
The only language I know which modeled optionals as (Type | Null) is Ceylon, 
which seems to have a favor for union types - but have no idea if its designers 
are happy with that decision.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 11:08 AM, Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Feb 21, 2017, at 11:47 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I joined the list primarily because I really wanted that change. After
> it was accepted, I stopped following, partially because I cannot keep up
> with all the emails. I saw this thread completely by accident when I was
> going to unsubscribe! I hope to be back when the discussion moves to
> Discourse, but if accepted proposals are not treated as final decisions
> (unless something significant comes up), I don't know if I will. I am sure
> that my absence will not be noticed, but there could be many people like
> me. People on this list represent a very small percentage of the actual
> group who use the language, but from what I read here, there seems to be an
> assumption that people on the list is an accurate representation of the
> entire group of programmers using Swift. It's not, and there could be a
> large number of people who silently disagree with any particular proposal,
> and the actual usage statistics could be different from what people here
> may think. Also, some people may not know about particular features, and it
> may be a matter of education rather than a feature not carrying its own
> weight. If you looked at GitHub, you could say that nobody is using feature
> X, so it's not useful or needed, but it could also be that if X were
> publicized better, GitHub would show much more adoption. I really hope that
> features get decided on the merit of their usefulness and not by vote of
> people on this list.
>
> Swift shouldn’t be unnecessarily burdened by the opinions of people who
> feel the need to spend all their time on a mailing list. A language’s
> features should be useful in their own right. If “nobody" knows how to use
> a feature appropriately, then random code from GitHub _is_ data that it
> might not necessarily be well thought out. Proposals can’t be written in
> stone because we can’t see the future. I’m sorry you no longer want to
> participate, but the world will keep on turning.
>

So, clearly, both of these positions have merit, IMO. For this process to
work, people have to understand that there is a designated time to share
viewpoints surrounding a proposal; then, a decision is taken, and that
decision should be taken as the considered opinion of the Swift community
and core team. Surely, we want to encourage people to write quality prose
to explain their thoughts and ideas to the fullest extent, but no one has
the time or energy to do that repeatedly on the same topic with no end in
sight. Therefore, it's antithetical to fostering an environment of critical
thinking to have the same topic brought up ad nauseam. That's partly
reflected in the existence of a "commonly rejected proposals" document.

Now, of course, if implementation runs into a roadblock, or if real-world
experience after implementation contradicts some fundamental assumptions of
the initial proposal, then revision or retraction may be necessary. But, to
use a legal analogy, that should be the equivalent of re-opening a case
after new evidence comes forward that places the original verdict into
serious doubt. Revisiting a topic should *not* be the equivalent of
appealing a court case after an unfavorable decision.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Feb 21, 2017, at 3:52 PM, Rod Brown  wrote:
> 
> It still holds the fundamental oddities of NSProgress that I find weird. Like 
> "current progress" always strikes me as very odd concept.

The “current progress” bit is there mainly for source compatibility. I’d expect 
it would not be the norm for new code.

> I'd be interested to see what Tony Parker and the Core Team think!

So would I.

Charles

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Feb 21, 2017 at 4:04 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 21 Feb 2017, at 21:39, Max Moiseev  wrote:
>
>
> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I assume the “SignedNumber” protocol is the same as the existing one in
> the standard library. That is to say, Strideable.Stride will now conform to
> Number and have operators.
>
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless
> it’s a _Pointer. (you can find the current implementation prototype here
> 
> ).
>
>
> Currently, it’s difficult to work with Strideable because you can
> calculate distances between them (as type Strideable.Stride), but you can’t
> add those distances because Strideable.Stride is only constrained to
> conform to “SignedNumber”, which is a pretty useless protocol.
>
> In the prototype, Strideable.Stride has now been changed, so it is
> constrained to “SignedArithmetic” (which, apparently, is to be renamed
> “SignedNumber”). So essentially, the existing SignedNumber has been
> re-parented to “Number” and gains operations such as addition. That’s great!
>
> I think it would be worth including Strideable in the “big picture” in the
> proposal/manifesto, showing how it fits in..
>
>
> Also minor nitpick, would it be too onerous to require Number.Magnitude to
> be Comparable? Currently it’s only Equatable and
> ExpressibleByIntegerLiteral.
>
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it
> ends up being called), but the recursive constraints feature is missing,
> therefore we constrained it with the protocols that Arithmetic itself
> refines.
>
> Why would you want Comparable?
>
> Max
>
>
> I suppose that leads me on to the question of why Number itself only
> requires that conformers be (Equatable & ExpressibleByIntegerLiteral) and
> does not require that they be Comparable.
>
> If I must be able to create any “Number" out of thin air with an integer
> literal, is it not reasonable to also require that I am able to compare two
> instances?
>
> Are there Number types which can’t be Comparable?
>

Complex numbers. I believe `Number` is designed to allow a complex number
type to conform.


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

[Karl Wagner via swift-evolution]

> On 21 Feb 2017, at 21:39, Max Moiseev  wrote:
> 
> 
>> On Feb 18, 2017, at 12:02 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> I assume the “SignedNumber” protocol is the same as the existing one in the 
>> standard library. That is to say, Strideable.Stride will now conform to 
>> Number and have operators.
> SignedNumber will *not* be the same. It is just the same name.
> Stride will have operators, yes. Strideable in general will not, unless it’s 
> a _Pointer. (you can find the current implementation prototype here 
> ).

Currently, it’s difficult to work with Strideable because you can calculate 
distances between them (as type Strideable.Stride), but you can’t add those 
distances because Strideable.Stride is only constrained to conform to 
“SignedNumber”, which is a pretty useless protocol.

In the prototype, Strideable.Stride has now been changed, so it is constrained 
to “SignedArithmetic” (which, apparently, is to be renamed “SignedNumber”). So 
essentially, the existing SignedNumber has been re-parented to “Number” and 
gains operations such as addition. That’s great!

I think it would be worth including Strideable in the “big picture” in the 
proposal/manifesto, showing how it fits in..

>> 
>> Also minor nitpick, would it be too onerous to require Number.Magnitude to 
>> be Comparable? Currently it’s only Equatable and ExpressibleByIntegerLiteral.
> Magnitude is supposed to conform to Arithmetic (or Number, or whatever it 
> ends up being called), but the recursive constraints feature is missing, 
> therefore we constrained it with the protocols that Arithmetic itself refines.
> 
> Why would you want Comparable?
> 
> Max
> 

I suppose that leads me on to the question of why Number itself only requires 
that conformers be (Equatable & ExpressibleByIntegerLiteral) and does not 
require that they be Comparable.

If I must be able to create any “Number" out of thin air with an integer 
literal, is it not reasonable to also require that I am able to compare two 
instances?

Are there Number types which can’t be Comparable?

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