Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Andrew Trick via swift-evolution]

> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>  wrote:
> 
> Replace isUniquelyReferenced by 
> isUniquelyReferencedUnsafe and remove the NonObjectiveCBase 
> class from the standard library.
> 
> 

So we’ll have:

- isUniquelyReferencedNonObjC(object): true iff object is uniquely referenced 
and NonObjC

- isUniquelyReferencedUnsafe(object): true iff object is uniquely reference, 
assert NonObjC

I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If you 
think this is an unsafe API then it should be:
“unsafeIsUniquelyReferenced”.

But I don’t really see how it is unsafe in the usual sense. If you want to 
convey that the programmer needs to satisfy some precondition, which is not 
generally associated with unsafety, then it should be:
“isUniquelyReferencedAssumingNonObjC”

Frankly, the type was a nicer way to do this, by I understand removing it from 
the API surface.

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

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold via swift-evolution]

Sent from my iPhone

> On Jul 16, 2016, at 9:41 PM, Arnold  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 16, 2016, at 9:23 PM, Andrew Trick  wrote:
>> 
>> 
>>> On Jul 16, 2016, at 9:17 PM, Arnold  wrote:
>>> 
>>> 
>>> 
>>> On Jul 16, 2016, at 8:45 PM, Andrew Trick  wrote:
>>> 
 
> On Jul 16, 2016, at 8:36 PM, Arnold  wrote:
> 
> Thank you for the feedback. Answers online.
> 
> Sent from my iPhone
> 
>> On Jul 16, 2016, at 7:38 PM, Andrew Trick  wrote:
>> 
>> 
>>> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>>>  wrote:
>>> 
>>> Replace isUniquelyReferenced by 
>>> isUniquelyReferencedUnsafe and remove the 
>>> NonObjectiveCBase class from the standard library.
>>> 
>> 
>> So we’ll have:
>> 
>> - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
>> referenced and NonObjC
>> 
>> - isUniquelyReferencedUnsafe(object): true iff object is uniquely 
>> reference, assert NonObjC
>> 
>> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If 
>> you think this is an unsafe API then it should be:
>> “unsafeIsUniquelyReferenced”.
>> 
>> But I don’t really see how it is unsafe in the usual sense. If you want 
>> to convey that the programmer needs to satisfy some precondition, which 
>> is not generally associated with unsafety, then it should be:
>> “isUniquelyReferencedAssumingNonObjC”
> 
> Makes sense to me. I think it is unsafe in the sense if you don't satisfy 
> the precondition the resulting behavior is undefined in modes other than 
> -Onone and not checked by a precondition predicate that traps.
> 
>> unsafeIsUniquelyReferenced
> 
> I find it kind of nice to recognize a predicate by the 'is' prefix. All 
> unsafe APIs start with the word unsafe though. I could not find an unsafe 
> freestanding predicate.
> 
> [As the implementor of the underlying builtin you may remember that it is 
> not actually undefined and will return a implementation defined value 
> (false) for objc classes. But we might not want to guarantee this going 
> forward.]
 
 
 Oh yeah. I think I only kept the two versions for fear of breaking the 
 API. Since you’re renaming the second one anyway, why not just delete it 
 with a fixit that it's renamed to isUniquelyReferencedNonObjC?
 
 The “assuming” version of the API is extremely confusing in addition to 
 being useless.
>>> 
>>> The unsafe version would allow us to emit more efficient code (in the 
>>> future) for a static unknown object type but we know it is a native type 
>>> (but not which so we can't just cast it, this is public API so we can't 
>>> cast to Builtin.NativeObject).
>>> 
>>>   var self: AnyObject // really: AnyNativeObject
>>>   ...
>>>   if (!unsafeIsUniquelyReferenced())
>>> self = self.copy()
>>>   }
>>> 
>>> I admit this is somewhat contrived and am happy to just nuke the API if we 
>>> agree there is no value in the use case above.
>> 
>> There is no sense advertising this API under some new name if it hasn’t even 
>> been implemented. The API can be added when it makes sense.
>> 
>> +1 for eliminating it.
> 
> Today you can implement something similar using NonObjectiveCBase as your 
> base class:
> 
>  var self: NonObjectiveCBase
>  ...
>  if (isUniquelyReferenced() {...}
> 
> And get the runtime performance of the native check.

Actually, this code could just implement their own 'class NonObjCBase' base 
class and just use isUniquelyReferencedNonObj for the same performance as 
before ...
> 
> If we implemented 'unsafeIsUniquelyReferenced' we would just unsafeBitCast 
> the 'object' argument to Builtin.NativeObject and get the same performance.
> 
> I admit that this may be far fetched but I am trying to anticipated possible 
> use cases that work today.
> 
> That use case will still work after nuking the API using the 'NonObjC' 
> variant albeit slightly slower.
> 
> If we need to support it with best performance we can always bring the API 
> back as you said.
> 
> +1 for nuking it from me
> 
> I will change the proposal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Károly Lőrentey via swift-evolution]

For what it’s worth, I renamed OrderedSet to SortedSet in the Swift 3 version 
of BTree, so the original instance of this issue is hopefully no more.

Prohibiting modules from containing a symbol of the same name would require a 
mass renaming of many microframeworks. Besides BTree, I also have BigInt, Deque 
and RedBlackTree; I know Rob Rix has Result, Box, Either, Memo, Delay, Stream, 
BinaryTree, etc.; and there are oodles more. Renaming them is certainly doable, 
but it definitely would be a pain in the neck for everyone involved. I’m not 
even sure what naming convention we should use: most of these packages 
essentially consist of the type that they’re named after, and naming them like 
this was the most obvious option. (These names work well at the point of use, 
too: you want to use Result, so you need to import Result). Requiring/allowing 
reverse DNS-style module names (e.g. com.apple.Foundation) would be one way to 
solve the naming issue, but this seems hard to incorporate into the language at 
this point.)

I’d much prefer having “import Foo as Bar” as a (hopefully) easy-to-implement 
stop-gap solution than to give up on these nice microframework names. This 
would not break existing code.

I like the idea to allow absolute naming to resolve ambiguous names, but using 
_ for the root symbol seems very different to its usual meaning. Perhaps it's 
worth spending the # character on this: #.BTree.OrderedSet. Or how about 
"<>.BTree.OrderedSet”? None of these would be intuitively clear to read, 
though (and they need special magic to make sure a “.BTree.” prefix is 
resolved to mean the module, not the struct.). If nested modules are in the 
cards for a future Swift, not having a delimiter at the end of the module path 
could become an issue.

What if we allowed type expressions like “(OrderedSet in BTree)” or 
“(OrderedSet from Foundation)”? The swapped order sure is strange though, 
and I have no idea if such a construct would fit in the grammar. But at least 
the meaning of it is reasonably clear, and the same scheme could also support 
the extension method case: e.g., "foo.(bar in MyModule)()”.

C# has a somewhat similar issue with its namespaces: 
https://blogs.msdn.microsoft.com/ericlippert/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one/
 
.
 They have "global::” to refer to their root namespace, and they discourage 
(but not prohibit) naming a class the same as its enclosing namespace. I think 
Java's concept of obscured names is also relevant, but I’ll leave it to someone 
else to decipher the specification. :-)

-- 
Karoly
@lorentey

> On 2016-07-17, at 01:07, Félix Cloutier via swift-evolution 
>  wrote:
> 
> There is a lot of potential for it to be a breaking change. Currently, you 
> can do module qualification with Module.Symbol. This causes problems. The two 
> most obvious solutions (change the "operator" between Module and Symbol, or 
> prevent symbols from having the same name as their module) are breaking 
> changes.
> 
> Félix
> 
>> Le 16 juil. 2016 à 16:01:28, David Hart > > a écrit :
>> 
>> I don't see anything source breaking here. I'm fairly sure it's 100% 
>> additive and will therefore wait for after Swift 3.
>> 
>> On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>>> There is about 2 weeks left for source-breaking proposals, and this is 
>>> going to be one of them. How is progress going? Do you think that you'll 
>>> have enough time to push it out of the door?
>>> 
>>> Félix
>>> 
 Le 20 juin 2016 à 17:33:03, Paulo Faria > a écrit :
 
 Yeah! I’m working on a formal proposal that would solve the same problem. 
 Jordan, the problem he described is exactly like the one you explained to 
 me, haha. Now I’m a bit confused about how the proposal should be called. 
 Have any suggestions? What title could fit the two use cases we mentioned. 
 By the way, can you see any other use case that would be solved with the 
 same solution?
 
 
> On Jun 20, 2016, at 9:25 PM, Jordan Rose  > wrote:
> 
> I've been encouraging Paulo Faria to mention this case in his push for a 
> way to disambiguate extension methods, with the thought being we could 
> then use the same syntax to differentiate top-level names as well.
> 
> I'd also be happy with the "import as" syntax. The underscore syntax 
> seems a little opaque, but I suppose it wouldn't come up very often.
> 
> Jordan
> 
> 
>> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
>> 

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>* What is your evaluation of the proposal?

Part of a series of increasingly compelling arguments for switching other 
languages for writting ios/osx application, provided that that is not also 
prohibited in the various stores in the near future

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

No. I'll self censor the rest as it is not flatering

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

Feel: not surewhat the feel of swifft is supposed to be anymore
Direction: yes... training wheels all around, limited abilitiy to organize & 
structure code (other key features missing for that & plenty of real life 
examples on github to show this is actually the case)

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

The bulk my professional experience has been mostly with asm x86, c, c++, perl, 
java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and recently 
TypeScript. None have something equivalent. I recently started toying with 
kotlin, that looks at inheritence in a similar light, but do not have enough 
real life experience yet to speak.
As for TypeScript, I only recently started writing large amounts of it 
professionally, and I am absolutely blown away: it has been the easiest 
language to learn and become extremely productive with, thanks to the most 
sound generic type system I have ever used (for bkgrnd, I love and makes very 
heavy use of the java/c# generics). 

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

A lot.

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

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Wrong thread ;) If you think it’s ill-prepared than provide some feedback 
> instead of just watching and waiting to throw negative feedback during review 
> process.
> 
> There is a lot done, but it’s not visible to the public thread yet. Will be 
> soon (by tomorrow I’d guess).
> 
> Thanks.
> 

A question i regularly ponder on with modern opensource is how it went so fast 
from stallman writting gcc to today's anything-goes, where there seems to be an 
expectatation that throwing even the worst unfinished piece of code in the 
public should implicitely gag others, and only compel them to have to fix it. 
There has always been great as well as ludicrous ideas in the history of 
mankind, and it would be a rare privilege of the opensource movement that the 
latter ought not to be singled out as such, and have them become by their mere 
presence in the public, everyone's responsibility to improve upon. 
This proposal was based on a lack of understanding of extensions. My understand 
of the process is that the initial discussion phase is there to evaluate an 
idea leaving, only the promissing ones reach proposal stage.
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalko...@gmail.com) 
> schrieb:
> 
>> To me this is reminicent of what is happening with the T.Type / Type 
>> story, where there seems to be a rush to throw a proposal under the cut-off 
>> date even if it is ill-prepared, or based on misunderstandinds.
>> Regards
>> (From mobile)
>> 
>> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>>> I tried to tackle the ability to write extensions where everyone would be 
>>> forced to write access modifier on member level. That’s what I had in my 
>>> mind all the time. But the respond on this was, as you can see purely 
>>> negative. :D
>>> 
>>> Making all extensions public when there is protocol conformance makes no 
>>> sense, because you could extend your type with an internal protocol, or the 
>>> extended type might be not public.
>>> 
>>> Anyways, I’m withdrawing this proposal. :)
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:
>>> 
 Because of all this, I have stopped using extension-level access modifiers 
 altogether, instead always specifying access at the member level. I would 
 be interested in a proposal to improve the current model — perhaps, for 
 example, making “public extension” apply only to a protocol conformance, 
 and disabling access modifiers on extensions that don’t have a protocol 
 conformance.
>>> ___
>>> 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: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold via swift-evolution]

Sent from my iPhone

> On Jul 16, 2016, at 8:45 PM, Andrew Trick  wrote:
> 
> 
>> On Jul 16, 2016, at 8:36 PM, Arnold  wrote:
>> 
>> Thank you for the feedback. Answers online.
>> 
>> Sent from my iPhone
>> 
>>> On Jul 16, 2016, at 7:38 PM, Andrew Trick  wrote:
>>> 
>>> 
 On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
  wrote:
 
 Replace isUniquelyReferenced by 
 isUniquelyReferencedUnsafe and remove the NonObjectiveCBase 
 class from the standard library.
 
>>> 
>>> So we’ll have:
>>> 
>>> - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
>>> referenced and NonObjC
>>> 
>>> - isUniquelyReferencedUnsafe(object): true iff object is uniquely 
>>> reference, assert NonObjC
>>> 
>>> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If you 
>>> think this is an unsafe API then it should be:
>>> “unsafeIsUniquelyReferenced”.
>>> 
>>> But I don’t really see how it is unsafe in the usual sense. If you want to 
>>> convey that the programmer needs to satisfy some precondition, which is not 
>>> generally associated with unsafety, then it should be:
>>> “isUniquelyReferencedAssumingNonObjC”
>> 
>> Makes sense to me. I think it is unsafe in the sense if you don't satisfy 
>> the precondition the resulting behavior is undefined in modes other than 
>> -Onone and not checked by a precondition predicate that traps.
>> 
>>> unsafeIsUniquelyReferenced
>> 
>> I find it kind of nice to recognize a predicate by the 'is' prefix. All 
>> unsafe APIs start with the word unsafe though. I could not find an unsafe 
>> freestanding predicate.
>> 
>> [As the implementor of the underlying builtin you may remember that it is 
>> not actually undefined and will return a implementation defined value 
>> (false) for objc classes. But we might not want to guarantee this going 
>> forward.]
> 
> 
> Oh yeah. I think I only kept the two versions for fear of breaking the API. 
> Since you’re renaming the second one anyway, why not just delete it with a 
> fixit that it's renamed to isUniquelyReferencedNonObjC?
> 
> The “assuming” version of the API is extremely confusing in addition to being 
> useless.

The unsafe version would allow us to emit more efficient code (in the future) 
for a static unknown object type but we know it is a native type (but not which 
so we can't just cast it, this is public API so we can't cast to 
Builtin.NativeObject).

  var self: AnyObject // really: AnyNativeObject
  ...
  if (!unsafeIsUniquelyReferenced())
self = self.copy()
  }

I admit this is somewhat contrived and am happy to just nuke the API if we 
agree there is no value in the use case above.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold via swift-evolution]

Sent from my iPhone

> On Jul 16, 2016, at 9:23 PM, Andrew Trick  wrote:
> 
> 
>> On Jul 16, 2016, at 9:17 PM, Arnold  wrote:
>> 
>> 
>> 
>> On Jul 16, 2016, at 8:45 PM, Andrew Trick  wrote:
>> 
>>> 
 On Jul 16, 2016, at 8:36 PM, Arnold  wrote:
 
 Thank you for the feedback. Answers online.
 
 Sent from my iPhone
 
> On Jul 16, 2016, at 7:38 PM, Andrew Trick  wrote:
> 
> 
>> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>>  wrote:
>> 
>> Replace isUniquelyReferenced by 
>> isUniquelyReferencedUnsafe and remove the 
>> NonObjectiveCBase class from the standard library.
>> 
> 
> So we’ll have:
> 
> - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
> referenced and NonObjC
> 
> - isUniquelyReferencedUnsafe(object): true iff object is uniquely 
> reference, assert NonObjC
> 
> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If 
> you think this is an unsafe API then it should be:
> “unsafeIsUniquelyReferenced”.
> 
> But I don’t really see how it is unsafe in the usual sense. If you want 
> to convey that the programmer needs to satisfy some precondition, which 
> is not generally associated with unsafety, then it should be:
> “isUniquelyReferencedAssumingNonObjC”
 
 Makes sense to me. I think it is unsafe in the sense if you don't satisfy 
 the precondition the resulting behavior is undefined in modes other than 
 -Onone and not checked by a precondition predicate that traps.
 
> unsafeIsUniquelyReferenced
 
 I find it kind of nice to recognize a predicate by the 'is' prefix. All 
 unsafe APIs start with the word unsafe though. I could not find an unsafe 
 freestanding predicate.
 
 [As the implementor of the underlying builtin you may remember that it is 
 not actually undefined and will return a implementation defined value 
 (false) for objc classes. But we might not want to guarantee this going 
 forward.]
>>> 
>>> 
>>> Oh yeah. I think I only kept the two versions for fear of breaking the API. 
>>> Since you’re renaming the second one anyway, why not just delete it with a 
>>> fixit that it's renamed to isUniquelyReferencedNonObjC?
>>> 
>>> The “assuming” version of the API is extremely confusing in addition to 
>>> being useless.
>> 
>> The unsafe version would allow us to emit more efficient code (in the 
>> future) for a static unknown object type but we know it is a native type 
>> (but not which so we can't just cast it, this is public API so we can't cast 
>> to Builtin.NativeObject).
>> 
>>   var self: AnyObject // really: AnyNativeObject
>>   ...
>>   if (!unsafeIsUniquelyReferenced())
>> self = self.copy()
>>   }
>> 
>> I admit this is somewhat contrived and am happy to just nuke the API if we 
>> agree there is no value in the use case above.
> 
> There is no sense advertising this API under some new name if it hasn’t even 
> been implemented. The API can be added when it makes sense.
> 
> +1 for eliminating it.

Today you can implement something similar using NonObjectiveCBase as your base 
class:

 var self: NonObjectiveCBase
 ...
 if (isUniquelyReferenced() {...}

And get the runtime performance of the native check.

If we implemented 'unsafeIsUniquelyReferenced' we would just unsafeBitCast the 
'object' argument to Builtin.NativeObject and get the same performance.

I admit that this may be far fetched but I am trying to anticipated possible 
use cases that work today.

That use case will still work after nuking the API using the 'NonObjC' variant 
albeit slightly slower.

If we need to support it with best performance we can always bring the API back 
as you said.

+1 for nuking it from me

I will change the proposal.


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

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Andrew Trick via swift-evolution]

> On Jul 16, 2016, at 9:17 PM, Arnold  wrote:
> 
> 
> 
> On Jul 16, 2016, at 8:45 PM, Andrew Trick  > wrote:
> 
>> 
>>> On Jul 16, 2016, at 8:36 PM, Arnold >> > wrote:
>>> 
>>> Thank you for the feedback. Answers online.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jul 16, 2016, at 7:38 PM, Andrew Trick >> > wrote:
>>> 
 
> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
> > wrote:
> 
> Replace isUniquelyReferenced by 
> isUniquelyReferencedUnsafe and remove the NonObjectiveCBase 
> class from the standard library.
> 
> 
 
 So we’ll have:
 
 - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
 referenced and NonObjC
 
 - isUniquelyReferencedUnsafe(object): true iff object is uniquely 
 reference, assert NonObjC
 
 I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If 
 you think this is an unsafe API then it should be:
 “unsafeIsUniquelyReferenced”.
 
 But I don’t really see how it is unsafe in the usual sense. If you want to 
 convey that the programmer needs to satisfy some precondition, which is 
 not generally associated with unsafety, then it should be:
 “isUniquelyReferencedAssumingNonObjC”
 
>>> 
>>> Makes sense to me. I think it is unsafe in the sense if you don't satisfy 
>>> the precondition the resulting behavior is undefined in modes other than 
>>> -Onone and not checked by a precondition predicate that traps.
>>> 
 unsafeIsUniquelyReferenced
>>> 
>>> I find it kind of nice to recognize a predicate by the 'is' prefix. All 
>>> unsafe APIs start with the word unsafe though. I could not find an unsafe 
>>> freestanding predicate.
>>> 
>>> [As the implementor of the underlying builtin you may remember that it is 
>>> not actually undefined and will return a implementation defined value 
>>> (false) for objc classes. But we might not want to guarantee this going 
>>> forward.]
>> 
>> 
>> Oh yeah. I think I only kept the two versions for fear of breaking the API. 
>> Since you’re renaming the second one anyway, why not just delete it with a 
>> fixit that it's renamed to isUniquelyReferencedNonObjC?
>> 
>> The “assuming” version of the API is extremely confusing in addition to 
>> being useless.
> 
> The unsafe version would allow us to emit more efficient code (in the future) 
> for a static unknown object type but we know it is a native type (but not 
> which so we can't just cast it, this is public API so we can't cast to 
> Builtin.NativeObject).
> 
>   var self: AnyObject // really: AnyNativeObject
>   ...
>   if (!unsafeIsUniquelyReferenced())
> self = self.copy()
>   }
> 
> I admit this is somewhat contrived and am happy to just nuke the API if we 
> agree there is no value in the use case above.

There is no sense advertising this API under some new name if it hasn’t even 
been implemented. The API can be added when it makes sense.

+1 for eliminating it.

-Andy

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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

To be clear, I think that you should be allowed to have a symbol that has the 
same name as the module. I was talking about that alternative because other 
people on this thread preferred it, but this does not reflect my opinion at 
all. As Károly writes, one very big reason to dislike it is that there is no 
possible automated migration for users of frameworks that rely on this pattern.

Renaming imports is one additive way to solve the problem. I was asking Paulo 
how his proposal is going, though, because my intuition is that it's headed 
towards something like `object.Module::extensionMethod()` to disambiguate 
extension methods, and we could reuse whatever syntax it has for global module 
symbols too.

Since I suggested _.Module.Class, it was brought to my attention (on this 
thread) that : is not an operator symbol, so there is no risk of ambiguity in 
Module::Class (which I think is better than _.Module.Class).

Félix

> Le 16 juil. 2016 à 19:06:14, Robert Widmann  a 
> écrit :
> 
> I've been wanting to do this kind of overhaul for the last 6 months.  My 
> original spitball thread is here  
> http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394 
>  and I have 
> a draft of a proposal that I hope to put out soon that I can let you view (or 
> even coauthor if you desire) if anybody wishes to ping me off-list.
> 
> ~Robert Widmann
> 
> 2016/07/16 15:19、Félix Cloutier via swift-evolution 
> > のメッセージ:
> 
>> There is about 2 weeks left for source-breaking proposals, and this is going 
>> to be one of them. How is progress going? Do you think that you'll have 
>> enough time to push it out of the door?
>> 
>> Félix
>> 
>>> Le 20 juin 2016 à 17:33:03, Paulo Faria >> > a écrit :
>>> 
>>> Yeah! I’m working on a formal proposal that would solve the same problem. 
>>> Jordan, the problem he described is exactly like the one you explained to 
>>> me, haha. Now I’m a bit confused about how the proposal should be called. 
>>> Have any suggestions? What title could fit the two use cases we mentioned. 
>>> By the way, can you see any other use case that would be solved with the 
>>> same solution?
>>> 
>>> 
 On Jun 20, 2016, at 9:25 PM, Jordan Rose > wrote:
 
 I've been encouraging Paulo Faria to mention this case in his push for a 
 way to disambiguate extension methods, with the thought being we could 
 then use the same syntax to differentiate top-level names as well.
 
 I'd also be happy with the "import as" syntax. The underscore syntax seems 
 a little opaque, but I suppose it wouldn't come up very often.
 
 Jordan
 
 
> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
> > wrote:
> 
> Hello all,
> 
> I recently ran into a bug  
> that leaves me unable to fully-qualify the name of a type. If you import 
> a module named Foo that also contains a type named Foo, attempts to 
> fully-qualify any name in the Foo module will instead attempt to find 
> something inside the Foo type. This bug has already been reported 
> .
> 
> Here's an example with Károly Lőrentey's BTree module (which also 
> contains a BTree type) that I encountered while trying to use the 
> OrderedSet type:
> 
> let set = OrderedSet()
> // error: 'OrderedSet' is ambiguous for type lookup in this context
> // Found this candidate: Foundation.OrderedSet:3:14
> // Found this candidate: BTree.OrderedSet:12:15
> To solve this, you would normally write BTree.OrderedSet, but now Swift 
> thinks that BTree is the BTree type, not the BTree module:
> 
> let set = BTree.OrderedSet()
> // error: reference to generic type 'BTree' requires arguments in <...>
> Any fix will require a change to the language, and as Jordan Rose stated 
> on the bug, it "needs design", so I would like to bring up the issue and 
> discuss possible solutions.
> 
> I can see several options (leaving "do nothing" aside, since I believe 
> that this needs to be resolved):
> 
> Prevent modules from containing a type with the same name
> Allow modules to be imported under different names (`import BTree as 
> BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
> Create a new syntax that indicates that you're naming a module, not a 
> type (like `_.BTree.OrderedSet`)
> 
> Thoughts?
> 
> Félix
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Károly Lőrentey via swift-evolution]

> On 2016. Jul 16., at 16:45, Karl via swift-evolution 
>  wrote:
> Sorry to mail 3 times in a row, but as I finished I remembered a concrete 
> example of where sealed protocols would be helpful:
> 
> UIKit has a UITextInput protocol, which is used by custom text object which 
> want to interact with the keyboard. It has a delegate property, of type 
> UITextInputDelegate (another protocol).
> 
> I have seen lots of people try to have their own objects conform to 
> UITextInputDelegate and set themselves as the delegate on a UITextInput 
> object. That is the wrong usage of the property. You are never supposed to 
> conform to UITextInputDelegate; the system has something which conforms to 
> it, and it will set itself as your delegate at some point during text input. 
> You use it to notify the system about changes to the text content and 
> selection region.
> 
> https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextInputDelegate_Protocol/index.html
> 
> If it was a sealed protocol, the UIKit API authors would be able to more 
> clearly communicate this intention and people wouldn’t be able to fall in 
> this trap. The only other way they could do it would be to use a concrete 
> final type, which evidently they didn’t want to do (possibly because it has 
> internal subclasses and can’t be final).

I think there is at least one legitimate case where you'd still want to 
implement these kinds of protocols: when you're writing unit tests and you want 
to create a mock delegate to verify that your code calls the delegate methods 
correctly.

Also, interface inheritance is much less dangerous than implementation 
inheritance; I can't think of a case where allowing external code to implement 
a protocol could lead to maintenance problems for the framework author like 
subclassing does. (Although I agree the user confusion that you described 
occurs a lot.)

Karoly
@lorentey

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

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold via swift-evolution]

`isUniqueReferencedNonObjC` is useful if our storage could be other a native 
Swift class or an objective-c class instance.
An example of this is Array's storage: It could either be a native Swift class 
instance or if the array was bridged from cocoa an NSArray instance. Before we 
write to the array we check that it is uniquely referenced and not an NSArray. 
If either checks fail we copy the contents to a new native Swift array.
You are correct that semantically we could compose the latter. But, in some 
situations, this code should be fast, for example the array code I mentioned: 
the overhead of two runtime calls vs one matters.

> On Jul 16, 2016, at 3:49 PM, Jaden Geller  wrote:
> 
> Some explanation of the benefit of keeping both `isUniquelyReferencedUnsafe` 
> and `isUniqueReferencedNonObjC` would be useful. I’m not entirely sure why 
> the latter is useful. If it is useful, I’m not sure why we can’t just have 
> `isUniquelyReferencedUnsafe` and `isObjC`.
> 
>> On Jul 16, 2016, at 1:21 PM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> 
>> On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via
>> swift-evolution  wrote:
>>> ## Proposed solution
>>> 
>>> Replace `isUniquelyReferenced` by
>>> `isUniquelyReferencedUnsafe` and remove the 
>>> `NonObjectiveCBase`
>>> class from the standard library.
>> 
>> Thank you for this proposal!
>> 
>> For presentation and clarity, could you show the full family of
>> `isUniquely*` functions in the design section, including those
>> functions that you are not proposing to change?  This will make it
>> easier to see what choices users will get.  It would be also great to
>> include the API of similar ManagedBuffer and ManagedBufferPointer
>> APIs, if any exist.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>> ___
>> 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] Fixing modules that contain a type with the same name

[Robert Widmann via swift-evolution]

I've been wanting to do this kind of overhaul for the last 6 months.  My 
original spitball thread is here  
http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394 and I have a 
draft of a proposal that I hope to put out soon that I can let you view (or 
even coauthor if you desire) if anybody wishes to ping me off-list.

~Robert Widmann

2016/07/16 15:19、Félix Cloutier via swift-evolution  
のメッセージ:

> There is about 2 weeks left for source-breaking proposals, and this is going 
> to be one of them. How is progress going? Do you think that you'll have 
> enough time to push it out of the door?
> 
> Félix
> 
>> Le 20 juin 2016 à 17:33:03, Paulo Faria  a écrit :
>> 
>> Yeah! I’m working on a formal proposal that would solve the same problem. 
>> Jordan, the problem he described is exactly like the one you explained to 
>> me, haha. Now I’m a bit confused about how the proposal should be called. 
>> Have any suggestions? What title could fit the two use cases we mentioned. 
>> By the way, can you see any other use case that would be solved with the 
>> same solution?
>> 
>> 
>>> On Jun 20, 2016, at 9:25 PM, Jordan Rose  wrote:
>>> 
>>> I've been encouraging Paulo Faria to mention this case in his push for a 
>>> way to disambiguate extension methods, with the thought being we could then 
>>> use the same syntax to differentiate top-level names as well.
>>> 
>>> I'd also be happy with the "import as" syntax. The underscore syntax seems 
>>> a little opaque, but I suppose it wouldn't come up very often.
>>> 
>>> Jordan
>>> 
>>> 
 On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
  wrote:
 
 Hello all,
 
 I recently ran into a bug that leaves me unable to fully-qualify the name 
 of a type. If you import a module named Foo that also contains a type 
 named Foo, attempts to fully-qualify any name in the Foo module will 
 instead attempt to find something inside the Foo type. This bug has 
 already been reported.
 
 Here's an example with Károly Lőrentey's BTree module (which also contains 
 a BTree type) that I encountered while trying to use the OrderedSet type:
 
 let set = OrderedSet()
 // error: 'OrderedSet' is ambiguous for type lookup in this context
 // Found this candidate: Foundation.OrderedSet:3:14
 // Found this candidate: BTree.OrderedSet:12:15
 To solve this, you would normally write BTree.OrderedSet, but now Swift 
 thinks that BTree is the BTree type, not the BTree module:
 
 let set = BTree.OrderedSet()
 // error: reference to generic type 'BTree' requires arguments in <...>
 Any fix will require a change to the language, and as Jordan Rose stated 
 on the bug, it "needs design", so I would like to bring up the issue and 
 discuss possible solutions.
 
 I can see several options (leaving "do nothing" aside, since I believe 
 that this needs to be resolved):
 
 Prevent modules from containing a type with the same name
 Allow modules to be imported under different names (`import BTree as 
 BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
 Create a new syntax that indicates that you're naming a module, not a type 
 (like `_.BTree.OrderedSet`)
 
 Thoughts?
 
 Félix
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 17, 2016, at 4:24 AM, L. Mihalkovic  
> wrote:
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. The proposal is available 
>> here:
>> 
>>   
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>   https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>   * What is your evaluation of the proposal?
> 
> Part of a series of increasingly compelling arguments for switching other 
> languages for writting ios/osx application, provided that that is not also 
> prohibited in the various stores in the near future
> 
>>   * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> No. I'll self censor the rest as it is not flatering

The jist is that, as demonstrated by the discussions in the original thread, 
the proposal as it is worded is incomplete, paving the way to a 0111 scenario 
if rushed to approval as is. 

> 
>>   * Does this proposal fit well with the feel and direction of Swift?
> 
> Feel: not surewhat the feel of swifft is supposed to be anymore
> Direction: yes... training wheels all around, limited abilitiy to organize & 
> structure code (other key features missing for that & plenty of real life 
> examples on github to show this is actually the case)
> 
>>   * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> The bulk my professional experience has been mostly with asm x86, c, c++, 
> perl, java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and 
> recently TypeScript. None have something equivalent. I recently started 
> toying with kotlin, that looks at inheritence in a similar light, but do not 
> have enough real life experience yet to speak.
> As for TypeScript, I only recently started writing large amounts of it 
> professionally, and I am absolutely blown away: it has been the easiest 
> language to learn and become extremely productive with, thanks to the most 
> sound generic type system I have ever used (for bkgrnd, I love and makes very 
> heavy use of the java/c# generics). 
> 
>>   * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> A lot.
> 
>> 
>> More information about the Swift evolution process is available at
>> 
>>   https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 7:56 PM, Jose Cheyo Jimenez 
wrote:

> I think you can simplify this proposal by just saying something like this
> and give a couple of examples that are easy to follow:
>
> Disallow explicit public access modifier on non-protocol-conforming type
> extensions.
>

It took me a while to process what you're trying to say here, but this is a
good idea and would go along well with the first draft's proposed solution.
I will spell it out. (If we say that you can use an explicit modifier only
to lower the access level of members, then `public` as an explicit modifier
could be entirely disallowed.)


>
> I think if you only focus on that breaking change then the proposal will
> have a good chance of getting accepted and fixing the immediate issue of
> public. There is a reason why protocol conforming extensions do not allow
> explicitly saying public
> `public extension Type: Protocol {}` // public not allowed
>

Actually, no modifiers are allowed in that scenario, IIUC.

>
> In essence we will be asking for the same behavior for types.
>
> Allowing methods declared inside extensions to have a higher declared
> visibility is not a breaking change and can be introduced later.
>

It is a breaking change in that I am proposing that the rules be harmonized
so that the implicit default access level will be notionally `internal`
(there are follow-on benefits to this change). That cannot be changed later.


> Nobody wants private extensions or implicit internal extensions to go
> away. :)
>

I know that there are people who don't want it to go away. That was why the
first draft proposed keeping them, but it sounds like it would make for an
illogical system. I know that Jordan and John have both indicated that they
don't think it's worth keeping around but don't seem to feel too strongly
about it, and I think I feel the same way (leaning towards not keeping
them, but don't feel very strongly). I will definitely feature this concern
(using extensions as access modifier groups) prominently in the proposal
and hope for a robust discussion to see how it plays out with the community
and core team.



> On Jul 16, 2016, at 4:22 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Jul 16, 2016 at 6:10 PM, David Hart  wrote:
>
>> This proposal really confuses me. Two comments:
>>
>> 1) With the proposal, we loose the ability to use access modifiers on
>> extensions as a way of grouping members by access. That's a huge loss for
>> me.
>>
>
> You lose the ability to group public members only. That part is
> intentional, so that only methods declared with `public func` are public.
>
>
>> 2) If we adopt the proposal, I now have no idea what explicit access
>> modifiers on extensions do.
>>
>
> I propose keeping explicit access modifiers because previous comments on
> this list have said that it's useful for grouping members by access. You
> can continue to use extensions to group fileprivate members of an internal
> type, or internal members of a public type.
>
>
>
>> More generally, I don't understand this proposal as it's trying to apply
>> the same access modifier rules on extensions as for types but extensions
>> are not types. They are just a declaration for extending types which
>> already have an access level.
>>
>> On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> With the impending withdrawal of SE-0119 and the closing window for
>> (most) source-breaking changes, I thought I'd draft up a proposal to
>> address some of the key points raised in that discussion.
>>
>> The proposed changes are deliberately limited in scope to rationalizing
>> access modifier rules without adding any new facilities (such as
>> conformances of lower visibility than the type), which might be more
>> appropriate for the Swift 4 timeline.
>>
>> I hope this will prove satisfactory to the community :)
>>
>>
>> Harmonize access modifiers for extensions
>>
>>- Proposal: SE-
>>
>> 
>>- Author: Xiaodi Wu 
>>- Status: Awaiting review
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> During discussion of SE-0119
>> ,
>> the community articulated the view that access modifiers for extensions
>> were and should continue to be subject to the same rules as access
>> modifiers for types. Unfortunately, it is not factually true today; this
>> proposal aims to make it so.
>>
>> Swift-evolution threads:
>>
>>- [Proposal] Revising access modifiers on extensions
>>
>> 

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Andrew Trick via swift-evolution]

> On Jul 16, 2016, at 8:36 PM, Arnold  wrote:
> 
> Thank you for the feedback. Answers online.
> 
> Sent from my iPhone
> 
> On Jul 16, 2016, at 7:38 PM, Andrew Trick  > wrote:
> 
>> 
>>> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>>> > wrote:
>>> 
>>> Replace isUniquelyReferenced by 
>>> isUniquelyReferencedUnsafe and remove the NonObjectiveCBase 
>>> class from the standard library.
>>> 
>>> 
>> 
>> So we’ll have:
>> 
>> - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
>> referenced and NonObjC
>> 
>> - isUniquelyReferencedUnsafe(object): true iff object is uniquely reference, 
>> assert NonObjC
>> 
>> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If you 
>> think this is an unsafe API then it should be:
>> “unsafeIsUniquelyReferenced”.
>> 
>> But I don’t really see how it is unsafe in the usual sense. If you want to 
>> convey that the programmer needs to satisfy some precondition, which is not 
>> generally associated with unsafety, then it should be:
>> “isUniquelyReferencedAssumingNonObjC”
>> 
> 
> Makes sense to me. I think it is unsafe in the sense if you don't satisfy the 
> precondition the resulting behavior is undefined in modes other than -Onone 
> and not checked by a precondition predicate that traps.
> 
>> unsafeIsUniquelyReferenced
> 
> I find it kind of nice to recognize a predicate by the 'is' prefix. All 
> unsafe APIs start with the word unsafe though. I could not find an unsafe 
> freestanding predicate.
> 
> [As the implementor of the underlying builtin you may remember that it is not 
> actually undefined and will return a implementation defined value (false) for 
> objc classes. But we might not want to guarantee this going forward.]


Oh yeah. I think I only kept the two versions for fear of breaking the API. 
Since you’re renaming the second one anyway, why not just delete it with a 
fixit that it's renamed to isUniquelyReferencedNonObjC?

The “assuming” version of the API is extremely confusing in addition to being 
useless.

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

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold Schwaighofer via swift-evolution]

Thank you Dmitri for your feedback. Updated draft below.

https://github.com/aschwaighofer/swift-evolution/blob/remove_nonobjectivecbase/proposals/-remove-nonobjectivecbase.md

Remove NonObjectiveCBase and replace isUniquelyReferenced by 
isUniquelyReferencedUnsafe

Proposal: SE- 

Author: Arnold Schwaighofer 
Status: Pitch
Review manager: TBD
 
Introduction

Remove NonObjectiveCBase and replace isUniquelyReferenced(_ object: T) byisUniquelyReferencedUnsafe(_ 
object: T). This will remove surface API. Instead of a type check dynamically 
check the non-@objc constraint under -Onone.

Swift-evolution thread: Pitch 

Swift bug: SR-1962 
Branch with change to stdlib: remove_nonobjectivecbase 

 
Motivation

Today we have isUniquelyReferenced which only works on subclasses of 
NonObjectiveCBase, and we have isUniquelyReferencedNonObjC which also works on 
@objc classes.

class SwiftKlazz : NonObjectiveCBase {}
class ObjcKlazz : NSObject {}

expectTrue(isUniquelyReferenced(SwiftKlazz()))
expectFalse(isUniquelyReferencedNonObjC(ObjcKlazz()))

// Would not compile:
expectFalse(isUniquelyReferenced(ObjcKlazz()))
In most cases we expect developers to be using the ManagedBufferPointer type. 
In cases where they want to use a custom class they would use 
isUniquelyReferenced today and can use isUniquelyReferencedUnsafe in the future.

class SwiftKlazz : NonObjectiveCBase {}
class ObjcKlazz : NSObject {}

expectTrue(isUniquelyReferencedUnsafe(SwiftKlazz()))
// Would trap under -Onone:
expectFalse(isUniquelyReferencedUnsafe(ObjcKlazz()))
Replacing isUniquelyReferenced by 
isUniquelyReferencedUnsafe will allow us to remove the 
NonObjectiveCBase class from the standard library thereby shrink API surface. 
We argue that trading type safety for less API surface is a good trade-off to 
make with this low-level API.

 
Proposed
 solution

Replace isUniquelyReferenced by 
isUniquelyReferencedUnsafe and remove the NonObjectiveCBase class 
from the standard library.

 
Detailed
 design

Todays APIs that can be used to check uniqueness is the family of 
isUniquelyReferenced functions.

/// Returns `true` iff `object` is a non-`@objc` class instance with
/// a single strong reference.
///
/// * Does *not* modify `object`; the use of `inout` is an
///   implementation artifact.
/// * If `object` is an Objective-C class instance, returns `false`.
/// * Weak references do not affect the result of this function.
///
/// Useful for implementing the copy-on-write optimization for the
/// deep storage of value types:
///
/// mutating func modifyMe(_ arg: X) {
///   if isUniquelyReferencedNonObjC() {
/// myStorage.modifyInPlace(arg)
///   }
///   else {
/// myStorage = self.createModified(myStorage, arg)
///   }
/// }
public func isUniquelyReferencedNonObjC(_ object: inout T) -> 
Bool
public func isUniquelyReferencedNonObjC(_ object: inout T?) -> 
Bool

/// A common base class for classes that need to be non-`@objc`,
/// recognizably in the type system.
public class NonObjectiveCBase {
  public init() {}
}

public func isUniquelyReferenced(
  _ object: inout T
) -> Bool
And the somewhat higher level APIs that can be used to model a storage with 
several elements ManagedBufferPointer.

/// Contains a buffer object, and provides access to an instance of
/// `Header` and contiguous storage for an arbitrary number of
/// `Element` instances stored in that buffer.
///
/// For most purposes, the `ManagedBuffer` class works fine for this
/// purpose, and can simply be used on its own.  However, in cases
/// where objects of various different classes must serve as storage,
/// `ManagedBufferPointer` is needed.
///
/// A valid buffer class is non-`@objc`, with no declared stored
///   properties.  Its `deinit` must destroy its
///   stored `Header` and any constructed `Element`s.
/// `Header` and contiguous storage for an arbitrary number of
/// `Element` instances stored in that buffer.
public struct ManagedBufferPointer : Equatable {
  /// Create with new storage containing an initial `Header` and 

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Xiaodi Wu via swift-evolution]

Can you elaborate? What understanding of extensions is lacking in this
proposal?
On Sat, Jul 16, 2016 at 22:30 L. Mihalkovic via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Regards
> (From mobile)
>
> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Wrong thread ;) If you think it’s ill-prepared than provide some feedback
> instead of just watching and waiting to throw negative feedback during
> review process.
>
> There is a lot done, but it’s not visible to the public thread yet. Will
> be soon (by tomorrow I’d guess).
>
> Thanks.
>
>
> A question i regularly ponder on with modern opensource is how it went so
> fast from stallman writting gcc to today's anything-goes, where there seems
> to be an expectatation that throwing even the worst unfinished piece of
> code in the public should implicitely gag others, and only compel them to
> have to fix it.
> There has always been great as well as ludicrous ideas in the history of
> mankind, and it would be a rare privilege of the opensource movement that
> the latter ought not to be singled out as such, and have them become by
> their mere presence in the public, everyone's responsibility to improve
> upon.
> This proposal was based on a lack of understanding of extensions. My
> understand of the process is that the initial discussion phase is there to
> evaluate an idea leaving, only the promissing ones reach proposal stage.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalko...@gmail.com)
> schrieb:
>
> To me this is reminicent of what is happening with the T.Type / Type
> story, where there seems to be a rush to throw a proposal under the cut-off
> date even if it is ill-prepared, or based on misunderstandinds.
> Regards
> (From mobile)
>
> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I tried to tackle the ability to write extensions where everyone would be
> forced to write access modifier on member level. That’s what I had in my
> mind all the time. But the respond on this was, as you can see purely
> negative. :D
>
> Making all extensions public when there is protocol conformance makes no
> sense, because you could extend your type with an internal protocol, or the
> extended type might be not public.
>
> Anyways, I’m withdrawing this proposal. :)
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:
>
> Because of all this, I have stopped using extension-level access modifiers
> altogether, instead always specifying access at the member level. I would
> be interested in a proposal to improve the current model — perhaps, for
> example, making “public extension” apply only to a protocol conformance,
> and disabling access modifiers on extensions that don’t have a protocol
> conformance.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold via swift-evolution]

Thank you for the feedback. Answers online.

Sent from my iPhone

> On Jul 16, 2016, at 7:38 PM, Andrew Trick  wrote:
> 
> 
>> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>>  wrote:
>> 
>> Replace isUniquelyReferenced by 
>> isUniquelyReferencedUnsafe and remove the NonObjectiveCBase 
>> class from the standard library.
>> 
> 
> So we’ll have:
> 
> - isUniquelyReferencedNonObjC(object): true iff object is uniquely referenced 
> and NonObjC
> 
> - isUniquelyReferencedUnsafe(object): true iff object is uniquely reference, 
> assert NonObjC
> 
> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If you 
> think this is an unsafe API then it should be:
> “unsafeIsUniquelyReferenced”.
> 
> But I don’t really see how it is unsafe in the usual sense. If you want to 
> convey that the programmer needs to satisfy some precondition, which is not 
> generally associated with unsafety, then it should be:
> “isUniquelyReferencedAssumingNonObjC”
> 

Makes sense to me. I think it is unsafe in the sense if you don't satisfy the 
precondition the resulting behavior is undefined in modes other than -Onone and 
not checked by a precondition predicate that traps.

> unsafeIsUniquelyReferenced

I find it kind of nice to recognize a predicate by the 'is' prefix. All unsafe 
APIs start with the word unsafe though. I could not find an unsafe freestanding 
predicate.

[As the implementor of the underlying builtin you may remember that it is not 
actually undefined and will return a implementation defined value (false) for 
objc classes. But we might not want to guarantee this going forward.]

> Frankly, the type was a nicer way to do this, by I understand removing it 
> from the API surface.
> 
> -Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold Schwaighofer via swift-evolution]

Updated proposal:

Remove NonObjectiveCBase and isUniquelyReferenced

Proposal: SE- 

Author: Arnold Schwaighofer 
Status: Pitch
Review manager: TBD
 
Introduction

Remove NonObjectiveCBase and isUniquelyReferenced(_ 
object: T). isUniquelyReferenced can be replaced by 
isUniquelyReferencedNonObjC(_ object: T). This replacement is as 
performant as the call to isUniquelyReferenced in cases where the compiler has 
static knowledge that the type of object is a native Swift class. This change 
will remove surface API.

Swift-evolution thread: Pitch 

Swift bug: SR-1962 
Branch with change to stdlib: remove_nonobjectivecbase 

 
Motivation

Today we have isUniquelyReferenced which only works on subclasses of 
NonObjectiveCBase, and we have isUniquelyReferencedNonObjC which also works on 
@objc classes.

class SwiftKlazz : NonObjectiveCBase {}
class ObjcKlazz : NSObject {}

expectTrue(isUniquelyReferenced(SwiftKlazz()))
expectFalse(isUniquelyReferencedNonObjC(ObjcKlazz()))

// Would not compile:
expectFalse(isUniquelyReferenced(ObjcKlazz()))
In most cases we expect developers to be using the ManagedBufferPointer type. 
In cases where they want to use a custom class they would use 
isUniquelyReferenced today and can use isUniquelyReferencedNonObjC in the 
future.

class SwiftKlazz {}

expectTrue(isUniquelyReferencedNonObjC(SwiftKlazz()))
Removing isUniquelyReferenced will allow us to remove 
the NonObjectiveCBase class from the standard library thereby further shrinking 
API surface.

 
Proposed
 solution

Remove isUniquelyReferenced and remove the 
NonObjectiveCBase class from the standard library. Clients of the the 
isUniquelyReferenced API can be migrated to use isUniquelyReferencedNonObjC. In 
most cases -- where the type of the object parameter is statically known to be 
a native non-@objc class -- the resulting code will have identical performance 
characteristics. In cases where the type is statically not known it will have 
the slight overhead of first checking that the dynamic type is not an @objc 
class.

 
Detailed
 design

Todays APIs that can be used to check uniqueness is the family of 
isUniquelyReferenced functions.

/// Returns `true` iff `object` is a non-`@objc` class instance with
/// a single strong reference.
///
/// * Does *not* modify `object`; the use of `inout` is an
///   implementation artifact.
/// * If `object` is an Objective-C class instance, returns `false`.
/// * Weak references do not affect the result of this function.
///
/// Useful for implementing the copy-on-write optimization for the
/// deep storage of value types:
///
/// mutating func modifyMe(_ arg: X) {
///   if isUniquelyReferencedNonObjC() {
/// myStorage.modifyInPlace(arg)
///   }
///   else {
/// myStorage = self.createModified(myStorage, arg)
///   }
/// }
public func isUniquelyReferencedNonObjC(_ object: inout T) -> 
Bool
public func isUniquelyReferencedNonObjC(_ object: inout T?) -> 
Bool

/// A common base class for classes that need to be non-`@objc`,
/// recognizably in the type system.
public class NonObjectiveCBase {
  public init() {}
}

public func isUniquelyReferenced(
  _ object: inout T
) -> Bool
And the somewhat higher level APIs that can be used to model a storage with 
several elements ManagedBufferPointer.

/// Contains a buffer object, and provides access to an instance of
/// `Header` and contiguous storage for an arbitrary number of
/// `Element` instances stored in that buffer.
///
/// For most purposes, the `ManagedBuffer` class works fine for this
/// purpose, and can simply be used on its own.  However, in cases
/// where objects of various different classes must serve as storage,
/// `ManagedBufferPointer` is needed.
///
/// A valid buffer class is non-`@objc`, with no declared stored
///   properties.  Its `deinit` must destroy its
///   stored `Header` and any constructed `Element`s.
/// `Header` and contiguous storage for an arbitrary number of
/// `Element` instances stored in that buffer.
public struct ManagedBufferPointer : Equatable {
  /// Create with new storage containing an initial `Header` and space
  /// for at least `minimumCapacity` `element`s.
  ///
  /// - parameter bufferClass: The class of the 

Re: [swift-evolution] Fixing modules that contain a type with the same name

[David Hart via swift-evolution]

I don't see anything source breaking here. I'm fairly sure it's 100% additive 
and will therefore wait for after Swift 3.

> On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution 
>  wrote:
> 
> There is about 2 weeks left for source-breaking proposals, and this is going 
> to be one of them. How is progress going? Do you think that you'll have 
> enough time to push it out of the door?
> 
> Félix
> 
>> Le 20 juin 2016 à 17:33:03, Paulo Faria  a écrit :
>> 
>> Yeah! I’m working on a formal proposal that would solve the same problem. 
>> Jordan, the problem he described is exactly like the one you explained to 
>> me, haha. Now I’m a bit confused about how the proposal should be called. 
>> Have any suggestions? What title could fit the two use cases we mentioned. 
>> By the way, can you see any other use case that would be solved with the 
>> same solution?
>> 
>> 
>>> On Jun 20, 2016, at 9:25 PM, Jordan Rose  wrote:
>>> 
>>> I've been encouraging Paulo Faria to mention this case in his push for a 
>>> way to disambiguate extension methods, with the thought being we could then 
>>> use the same syntax to differentiate top-level names as well.
>>> 
>>> I'd also be happy with the "import as" syntax. The underscore syntax seems 
>>> a little opaque, but I suppose it wouldn't come up very often.
>>> 
>>> Jordan
>>> 
>>> 
 On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
  wrote:
 
 Hello all,
 
 I recently ran into a bug that leaves me unable to fully-qualify the name 
 of a type. If you import a module named Foo that also contains a type 
 named Foo, attempts to fully-qualify any name in the Foo module will 
 instead attempt to find something inside the Foo type. This bug has 
 already been reported.
 
 Here's an example with Károly Lőrentey's BTree module (which also contains 
 a BTree type) that I encountered while trying to use the OrderedSet type:
 
 let set = OrderedSet()
 // error: 'OrderedSet' is ambiguous for type lookup in this context
 // Found this candidate: Foundation.OrderedSet:3:14
 // Found this candidate: BTree.OrderedSet:12:15
 To solve this, you would normally write BTree.OrderedSet, but now Swift 
 thinks that BTree is the BTree type, not the BTree module:
 
 let set = BTree.OrderedSet()
 // error: reference to generic type 'BTree' requires arguments in <...>
 Any fix will require a change to the language, and as Jordan Rose stated 
 on the bug, it "needs design", so I would like to bring up the issue and 
 discuss possible solutions.
 
 I can see several options (leaving "do nothing" aside, since I believe 
 that this needs to be resolved):
 
 Prevent modules from containing a type with the same name
 Allow modules to be imported under different names (`import BTree as 
 BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
 Create a new syntax that indicates that you're naming a module, not a type 
 (like `_.BTree.OrderedSet`)
 
 Thoughts?
 
 Félix
 
 ___
 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] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

There is a lot of potential for it to be a breaking change. Currently, you can 
do module qualification with Module.Symbol. This causes problems. The two most 
obvious solutions (change the "operator" between Module and Symbol, or prevent 
symbols from having the same name as their module) are breaking changes.

Félix

> Le 16 juil. 2016 à 16:01:28, David Hart  a écrit :
> 
> I don't see anything source breaking here. I'm fairly sure it's 100% additive 
> and will therefore wait for after Swift 3.
> 
> On 17 Jul 2016, at 00:19, Félix Cloutier via swift-evolution 
> > wrote:
> 
>> There is about 2 weeks left for source-breaking proposals, and this is going 
>> to be one of them. How is progress going? Do you think that you'll have 
>> enough time to push it out of the door?
>> 
>> Félix
>> 
>>> Le 20 juin 2016 à 17:33:03, Paulo Faria >> > a écrit :
>>> 
>>> Yeah! I’m working on a formal proposal that would solve the same problem. 
>>> Jordan, the problem he described is exactly like the one you explained to 
>>> me, haha. Now I’m a bit confused about how the proposal should be called. 
>>> Have any suggestions? What title could fit the two use cases we mentioned. 
>>> By the way, can you see any other use case that would be solved with the 
>>> same solution?
>>> 
>>> 
 On Jun 20, 2016, at 9:25 PM, Jordan Rose > wrote:
 
 I've been encouraging Paulo Faria to mention this case in his push for a 
 way to disambiguate extension methods, with the thought being we could 
 then use the same syntax to differentiate top-level names as well.
 
 I'd also be happy with the "import as" syntax. The underscore syntax seems 
 a little opaque, but I suppose it wouldn't come up very often.
 
 Jordan
 
 
> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
> > wrote:
> 
> Hello all,
> 
> I recently ran into a bug  
> that leaves me unable to fully-qualify the name of a type. If you import 
> a module named Foo that also contains a type named Foo, attempts to 
> fully-qualify any name in the Foo module will instead attempt to find 
> something inside the Foo type. This bug has already been reported 
> .
> 
> Here's an example with Károly Lőrentey's BTree module (which also 
> contains a BTree type) that I encountered while trying to use the 
> OrderedSet type:
> 
> let set = OrderedSet()
> // error: 'OrderedSet' is ambiguous for type lookup in this context
> // Found this candidate: Foundation.OrderedSet:3:14
> // Found this candidate: BTree.OrderedSet:12:15
> To solve this, you would normally write BTree.OrderedSet, but now Swift 
> thinks that BTree is the BTree type, not the BTree module:
> 
> let set = BTree.OrderedSet()
> // error: reference to generic type 'BTree' requires arguments in <...>
> Any fix will require a change to the language, and as Jordan Rose stated 
> on the bug, it "needs design", so I would like to bring up the issue and 
> discuss possible solutions.
> 
> I can see several options (leaving "do nothing" aside, since I believe 
> that this needs to be resolved):
> 
> Prevent modules from containing a type with the same name
> Allow modules to be imported under different names (`import BTree as 
> BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
> Create a new syntax that indicates that you're naming a module, not a 
> type (like `_.BTree.OrderedSet`)
> 
> Thoughts?
> 
> Félix
> 
> ___
> 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] Harmonize access modifiers for extensions

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 6:10 PM, David Hart  wrote:

> This proposal really confuses me. Two comments:
>
> 1) With the proposal, we loose the ability to use access modifiers on
> extensions as a way of grouping members by access. That's a huge loss for
> me.
>

You lose the ability to group public members only. That part is
intentional, so that only methods declared with `public func` are public.


> 2) If we adopt the proposal, I now have no idea what explicit access
> modifiers on extensions do.
>

I propose keeping explicit access modifiers because previous comments on
this list have said that it's useful for grouping members by access. You
can continue to use extensions to group fileprivate members of an internal
type, or internal members of a public type.



> More generally, I don't understand this proposal as it's trying to apply
> the same access modifier rules on extensions as for types but extensions
> are not types. They are just a declaration for extending types which
> already have an access level.
>
> On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> With the impending withdrawal of SE-0119 and the closing window for (most)
> source-breaking changes, I thought I'd draft up a proposal to address some
> of the key points raised in that discussion.
>
> The proposed changes are deliberately limited in scope to rationalizing
> access modifier rules without adding any new facilities (such as
> conformances of lower visibility than the type), which might be more
> appropriate for the Swift 4 timeline.
>
> I hope this will prove satisfactory to the community :)
>
>
> Harmonize access modifiers for extensions
>
>- Proposal: SE-
>
> 
>- Author: Xiaodi Wu 
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> During discussion of SE-0119
> ,
> the community articulated the view that access modifiers for extensions
> were and should continue to be subject to the same rules as access
> modifiers for types. Unfortunately, it is not factually true today; this
> proposal aims to make it so.
>
> Swift-evolution threads:
>
>- [Proposal] Revising access modifiers on extensions
>
> 
>- [More to be added here]
>
>
> 
> Motivation
>
> Consider the following:
>
> public struct foo {
>   func frobnicate() { } // implicitly internal
> }
> public extension foo { }
>
> public struct bar { }
> public extension bar {
>   func frobnicate() { } // implicitly public, according to SE-0025
> }
>
> According to SE-0025, a method moved from the body of a public struct into
> a public extension becomes public without modification. This is surprising
> behavior contrary to Swift's general rule of not exposing public API by
> default.
>
> Furthermore, SE-0025 now permits the owner of a type to design access for
> members as though the type will have a higher access level than it
> currently does. For example, users will be able to design public methods
> inside an internaltype before "flipping the switch" and making that type
> public. The same approach is prohibited by SE-0025 for extensions,
> although conceptually it need not be.
>
> Proposed
> solution
>
> The proposed solution is to change access modifier rules for extensions
> with the following effect: if any method (or computed property) declared
> within the body of a type at file scope is moved without modification into
> the body of an extension in the same file, the move will not change its
> accessibility.
>
> In code:
>
> struct foo {
>   // Any method declared here...
> }
> extension foo {
>   // ...should have the same visibility when moved here.
> }
>
> This implies that public API commitments will need to be annotated as
> public at declaration sites inside an extension just as it must be at
> declaration sites inside types.
>
> Detailed
> design
>
>1. Declarations inside the extension will, like declarations inside
>types, have a default access level of internal.
>2. The compiler should not warn when a broader level of access control
>is used for a method (or computed property, etc.) declared within an
>extension with more restrictive access. This allows the owner of the
>extension to design the access level they would use for a method if the

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

[Jose Cheyo Jimenez via swift-evolution]

I think you can simplify this proposal by just saying something like this and 
give a couple of examples that are easy to follow:

Disallow explicit public access modifier on non-protocol-conforming type 
extensions.

I think if you only focus on that breaking change then the proposal will have a 
good chance of getting accepted and fixing the immediate issue of public. There 
is a reason why protocol conforming extensions do not allow explicitly saying 
public 
`public extension Type: Protocol {}` // public not allowed 

In essence we will be asking for the same behavior for types. 

Allowing methods declared inside extensions to have a higher declared 
visibility is not a breaking change and can be introduced later. 

Nobody wants private extensions or implicit internal extensions to go away. :)

> On Jul 16, 2016, at 4:22 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Sat, Jul 16, 2016 at 6:10 PM, David Hart  wrote:
>> This proposal really confuses me. Two comments:
>> 
>> 1) With the proposal, we loose the ability to use access modifiers on 
>> extensions as a way of grouping members by access. That's a huge loss for me.
> 
> You lose the ability to group public members only. That part is intentional, 
> so that only methods declared with `public func` are public.
>  
>> 2) If we adopt the proposal, I now have no idea what explicit access 
>> modifiers on extensions do.
> 
> I propose keeping explicit access modifiers because previous comments on this 
> list have said that it's useful for grouping members by access. You can 
> continue to use extensions to group fileprivate members of an internal type, 
> or internal members of a public type.
> 
>  
>> More generally, I don't understand this proposal as it's trying to apply the 
>> same access modifier rules on extensions as for types but extensions are not 
>> types. They are just a declaration for extending types which already have an 
>> access level.
>> 
>>> On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> With the impending withdrawal of SE-0119 and the closing window for (most) 
>>> source-breaking changes, I thought I'd draft up a proposal to address some 
>>> of the key points raised in that discussion.
>>> 
>>> The proposed changes are deliberately limited in scope to rationalizing 
>>> access modifier rules without adding any new facilities (such as 
>>> conformances of lower visibility than the type), which might be more 
>>> appropriate for the Swift 4 timeline.
>>> 
>>> I hope this will prove satisfactory to the community :)
>>> 
>>> 
>>> Harmonize access modifiers for extensions
>>> 
>>> Proposal: SE-
>>> Author: Xiaodi Wu
>>> Status: Awaiting review
>>> Review manager: TBD
>>> Introduction
>>> 
>>> During discussion of SE-0119, the community articulated the view that 
>>> access modifiers for extensions were and should continue to be subject to 
>>> the same rules as access modifiers for types. Unfortunately, it is not 
>>> factually true today; this proposal aims to make it so.
>>> 
>>> Swift-evolution threads:
>>> 
>>> [Proposal] Revising access modifiers on extensions
>>> [More to be added here]
>>> Motivation
>>> 
>>> Consider the following:
>>> 
>>> public struct foo {
>>>   func frobnicate() { } // implicitly internal
>>> }
>>> public extension foo { }
>>> 
>>> public struct bar { }
>>> public extension bar {
>>>   func frobnicate() { } // implicitly public, according to SE-0025
>>> }
>>> According to SE-0025, a method moved from the body of a public struct into 
>>> a public extension becomes public without modification. This is surprising 
>>> behavior contrary to Swift's general rule of not exposing public API by 
>>> default.
>>> 
>>> Furthermore, SE-0025 now permits the owner of a type to design access for 
>>> members as though the type will have a higher access level than it 
>>> currently does. For example, users will be able to design public methods 
>>> inside an internaltype before "flipping the switch" and making that type 
>>> public. The same approach is prohibited by SE-0025 for extensions, although 
>>> conceptually it need not be.
>>> 
>>> Proposed solution
>>> 
>>> The proposed solution is to change access modifier rules for extensions 
>>> with the following effect: if any method (or computed property) declared 
>>> within the body of a type at file scope is moved without modification into 
>>> the body of an extension in the same file, the move will not change its 
>>> accessibility.
>>> 
>>> In code:
>>> 
>>> struct foo {
>>>   // Any method declared here...
>>> }
>>> extension foo {
>>>   // ...should have the same visibility when moved here.
>>> }
>>> This implies that public API commitments will need to be annotated as 
>>> public at declaration sites inside an extension just as it must be at 
>>> declaration sites inside types.
>>> 
>>> Detailed design
>>> 
>>> Declarations inside the extension 

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Anton Zhilin via swift-evolution]

I took some time to overview the whole idea in general, and I must say
(surprisingly) that I don't support it myself.

* Metatypes are still in the language; it turned out that they *must*
remain in the language
* The new primary `Type` struct duplicates semantics and interface of
metatypes
* But it cannot get extensive native support, so it uses `init?(casting:)`
instead of `as` cast, `is(_:)` method instead of `is`, etc
* `Type` does not add new possibilities right now, although the proposal
promises to add reflection to `Type` in the future
* `Mirror` already does reflection. It wraps `Any.Type` statically, which
is a simpler and more suitable model for reflection

I started thinking in a completely different direction:

* Rename metatypes `T.Type` to `Type`
* Rename `T.self` to `T`
* Allow `Type`
* **Extend `Mirror`** for Swift 4

What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

> * What is your evaluation of the proposal?
>

This is improved from the previous iteration. The code example needs
updating, as both instances of `open func bar()` should be `public open
func bar()` as outlined in the Proposed Design section.


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

Yes, mostly. There is one comment in the code example that describes a
restriction which does not fit with the direction of Swift. It is not the
main focus of the proposal but I think should be changed. Namely, the
proposal comments:

"[The declaration `[public] open func bar()` inside a class not marked
`open`] raises a compilation error: a method can't be marked `open` if the
class it belongs to can't be subclassed."

This is discordant with the direction resolved by the core team in the
SE-0025 revisions, where it was stated with regard to access modifiers:

"The compiler should not warn when a broader level of access control is
used within a type with more restrictive access, such as `internal` within
a `private` type. This allows the owner of the type to design the access
they would use were they to make the type more widely accessible."

Applying the same rationale here would suggest that the compiler should not
raise an error if a method is marked `open` inside a non-`open` type, in
order to allow the owner of the type to design as though to make it
subclassable without actually having to do so.

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

Yes, I've used OOP in other languages. As discussed, this approach is
different from that taken by many of those but is a deliberate step.


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

Followed the discussion, read proposal carefully.


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

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

> Am 16.07.2016 um 03:53 schrieb Susan Cheng :
> 
> How about Polar(r: 0, phi: 0) ?
> It should all equal with any angles if r == 0.

In an earlier post I wrote:

> And I would do the „standard equality“ upfront even if there is a custom 
> implementation
> and if the „standard equality“ says `true`, the custom implementation is not 
> asked.
> This would reduce the possibility of false-negatives.

So, if you’d like to override the "standard equality“ you would be able to do 
this, but with this chain you cannot create false-negatives as easy:

* for heap allocated values (e.g. values bigger than the value buffer in an 
existential container for protocol types) do a `===`. If `true` return `true`.
* for stack allocated values use „standard equality“. If `true` return `true`.
* if „standard equality“ return `false`, execute possible custom equality check 
`==`. Return result.

But If you override `==` in a value type I would warn, because this makes sense 
in only very rare occasions (perhaps with a @suppress annotation or alike). If 
you would like to ignore some values (produce „false“-negatives on purpose) add 
a `transient` keyword or alike. But I wouldn’t allow the latter, but instead 
offer the developer best practices like value types with indirect storage and 
copy-on-write for value semantics, in order to omit the values in the `==` 
implementation of the indirect storage reference type. Last but not least, in a 
far future, when the indirect storage of value types is done automatically 
(potentially) and these values are uniquely stored on the heap (in some kind of 
value pool), you can check for them `===`, too. The latter would **not** be as 
easy, if we allow custom equality because if we store values uniquely in the 
value pool and the equality puts values in the same equivalence class that are 
actually **not** equal from a value types point of view (be it for 
false-positives and false-negatives), it would put the values into the same 
slot, since you don’t have an identity check (`===`) on values.

In summary, IMHO using custom equality for value types is dangerous as it puts 
values that are actually different into the same equivalence class, which make 
their usage in dictionaries very difficult (especially for false-negatives, 
which hold some context information not part of the value) and correspondingly 
the implementation of value pools hard. So, custom equality should be used only 
in exceptional cases and it should be possible to do at most false-positives 
(like in the `Polar(r:0, phi: whatever)` example), but for false-negatives 
(like in the URI example) it should be handled differently, by introducing 
indirection.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Rod Brown via swift-evolution]

Review link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md


* What is your evaluation of the proposal?
+1 for the implementation. +0.5 for the concept. I think this is a clean interface for 
what open should be, and am glad at the simplification. This seems very 
"Swifty", and much better than the first proposal. I'm concerned that this may 
be over-limiting developers, and while everything looks great in theory, I am concerned 
that this may not be a good decision for real-world development. That said, I also think 
there are real wins in the ability to at a later date finalise a class for performance 
reasons, and provides clear structure for how a subclass is designed be used.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
I think that sorting out our inheritance story for public frameworks is 
important if we are going to start seeing public Swift Frameworks in the wild 
more often.

* 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?
I haven't. I've used Obj-C a lot. The ability to fix some issues with patching 
leads me to be concerned that we are overly restricting things here.

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I've been following the threads since this discussion started months back, in 
discussions recently over it, and have read thoroughly both reviews.

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Adrian Zubarev via swift-evolution]

H, currently I’m inserting some changes and tweaks into your last gist 
update.

Metatypes are still in the language; it turned out that they must remain in the 
language
Type wraps around metatypes and will provide better maintenance if ever 
needed, because metatype instantiation will be sealed to Type.metatype or 
typeInstance.metatype.

The new primary Type struct duplicates semantics and interface of metatypes.
True, but properties of a Type instance work with a ‘dynamic’ metatype, 
which can be up- and downcased. However static properties are used for quick 
access and do only with the fixed metatype for T.

But it cannot get extensive native support, so it uses init?(casting:) instead 
of as cast, is(_:) method instead of is, etc.
I believe this is not a huge problem. I’m sure dynamic casts can be teched to 
work with with Type instances. This can be purely additional and added after 
Swift 3.

class A {}
class B: A {}

// In Swift 3
let typeB: Type = B.self
let typeA: Type? = Type(casting: typeB)
let anotherTypeA: Type = Type(casting: typeB)!

// Post Swift 3 - Easy migration and removing `init?(casting:)`
let typeA: Type? = typeB as? Type  
let anotherTypeA: Type = typeB as! Type  
Same for for is:

let typeB: Type = B.self
typeB.`is`(A.self) // true

// Post Swift 3 - Easy migration and removing `func `is`(_:) -> Bool`
// Here the `is` cast extract `A` from `Type` and checks the  
// metatype inside of `typeB` if it's compatible with `A`
typeB is Type // true
The as dynamic cast needs additional teaching post Swift 3 without any regrets. 
Type would be a special case for dynamic casts.

Type does not add new possibilities right now, although the proposal 
promises to add reflection to Type in the future.
This is my personal opinion, but we’d move SE–0101 into a better place tied 
side by side to the (dynamic) metatype. MemoryLayout doesn’t provide an 
instance of itself, it’s purely static.

An instance of Type can be casted and we still can get nicely all the needed 
information and do not need to extract the dynamic metatype.

let typeB: Type = B.self
let typeA: Type? = Type(casting: typeB)
let anotherTypeA: Type = Type(casting: typeB)!

typeB.size
typeA?.size
anotherTypeA.size
Mirror already does reflection. It wraps Any.Type statically, which is a 
simpler and more suitable model for reflection.
I can’t argue on that one. The only thing that I know and have a strong feeling 
about is that Any.Type is broken. There should be AnyMetatype and current 
Any.Type should be the metatype for Any returned from the current Any.self. The 
bug is mentioned in our proposal.

We should move reflection to possible future direction.

Rename metatypes T.Type to Type
I don’t like .Type the way it is right now. T.Metatype makes more sense, which 
would implies (MHO) it should be called Metatype. This is coved in our 
proposal.

Rename T.self to T
It’s not about renaming here. SE–0090 aims to drop .self completely. Okay we 
could go the same way like I already mentioned in some previous examples:

// Only renaming `T.Type` into `Metatype`
let const1: Metatype = T
let const2: T = T()
let const3: T = T.init()
let const4: SomeOtherType = T.staticMember

// My vision
let const1: Type = T
let const2: T = T()
let const3: T = T.init()
let const4: SomeOtherType = T.staticMember
I asked the community if’s possible to make current T.Type conform to Hashable 
protocol. The response was positive, because this would be really handy.

Such a change would need more compiler magic or an internal protocol which I 
believe isn’t the best way to solve this. There I come up with the idea 
wrapping the metatype into a type called Type and make the public T.self 
notation construct an instance of Type instead.

Allow Type
Already possible with our current Type.

Extend Mirror for Swift 4
Maybe, but I would still tackle the proposal for Type. Maybe we’ll find a 
solution which will suit everyone.

PS:

I’m updating your last gist and preparing two refactored up (possible) 
implementation.
I’ll need a few hours, because I’m not that fast. :)
Stay patient.


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Adrian Zubarev via swift-evolution]

One more thing to consider. If we had no Type struct/class there would be no 
way to get the size of a dynamic metatype after SE–0101 and SE–0096.

func dynamicType(_ instance: T) -> Metatype

MemoryLayout.size
We can not check the size of T because then we might end up with the wrong size 
if Metatype was downcasted from Metatype.

Our current Type solves that issue with instance properties which calculate 
the correct value for the dynamic metatype.



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 11:57:33, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

H, currently I’m inserting some changes and tweaks into your last gist 
update.

Metatypes are still in the language; it turned out that they must remain in the 
language
Type wraps around metatypes and will provide better maintenance if ever 
needed, because metatype instantiation will be sealed to Type.metatype or 
typeInstance.metatype.

The new primary Type struct duplicates semantics and interface of metatypes.
True, but properties of a Type instance work with a ‘dynamic’ metatype, 
which can be up- and downcased. However static properties are used for quick 
access and do only with the fixed metatype for T.

But it cannot get extensive native support, so it uses init?(casting:) instead 
of as cast, is(_:) method instead of is, etc.
I believe this is not a huge problem. I’m sure dynamic casts can be teched to 
work with with Type instances. This can be purely additional and added after 
Swift 3.

class A {}
class B: A {}

// In Swift 3
let typeB: Type = B.self
let typeA: Type? = Type(casting: typeB)
let anotherTypeA: Type = Type(casting: typeB)!

// Post Swift 3 - Easy migration and removing `init?(casting:)`
let typeA: Type? = typeB as? Type   
let anotherTypeA: Type = typeB as! Type   
Same for for is:

let typeB: Type = B.self
typeB.`is`(A.self) // true

// Post Swift 3 - Easy migration and removing `func `is`(_:) -> Bool`
// Here the `is` cast extract `A` from `Type` and checks the   
// metatype inside of `typeB` if it's compatible with `A`
typeB is Type // true
The as dynamic cast needs additional teaching post Swift 3 without any regrets. 
Type would be a special case for dynamic casts.

Type does not add new possibilities right now, although the proposal 
promises to add reflection to Type in the future.
This is my personal opinion, but we’d move SE–0101 into a better place tied 
side by side to the (dynamic) metatype. MemoryLayout doesn’t provide an 
instance of itself, it’s purely static.

An instance of Type can be casted and we still can get nicely all the needed 
information and do not need to extract the dynamic metatype.

let typeB: Type = B.self
let typeA: Type? = Type(casting: typeB)
let anotherTypeA: Type = Type(casting: typeB)!

typeB.size
typeA?.size
anotherTypeA.size
Mirror already does reflection. It wraps Any.Type statically, which is a 
simpler and more suitable model for reflection.
I can’t argue on that one. The only thing that I know and have a strong feeling 
about is that Any.Type is broken. There should be AnyMetatype and current 
Any.Type should be the metatype for Any returned from the current Any.self. The 
bug is mentioned in our proposal.

We should move reflection to possible future direction.

Rename metatypes T.Type to Type
I don’t like .Type the way it is right now. T.Metatype makes more sense, which 
would implies (MHO) it should be called Metatype. This is coved in our 
proposal.

Rename T.self to T
It’s not about renaming here. SE–0090 aims to drop .self completely. Okay we 
could go the same way like I already mentioned in some previous examples:

// Only renaming `T.Type` into `Metatype`
let const1: Metatype = T
let const2: T = T()
let const3: T = T.init()
let const4: SomeOtherType = T.staticMember

// My vision
let const1: Type = T
let const2: T = T()
let const3: T = T.init()
let const4: SomeOtherType = T.staticMember
I asked the community if’s possible to make current T.Type conform to Hashable 
protocol. The response was positive, because this would be really handy.

Such a change would need more compiler magic or an internal protocol which I 
believe isn’t the best way to solve this. There I come up with the idea 
wrapping the metatype into a type called Type and make the public T.self 
notation construct an instance of Type instead.

Allow Type
Already possible with our current Type.

Extend Mirror for Swift 4
Maybe, but I would still tackle the proposal for Type. Maybe we’ll find a 
solution which will suit everyone.

PS:

I’m updating your last gist and preparing two refactored up (possible) 
implementation.
I’ll need a few hours, because I’m not that fast. :)
Stay patient.


-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

> 2016/07/16 14:52、Chris Lattner via swift-evolution 
>  のメール：
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
+1 for the improved keywords and purgatory for objc imported modules.

This is much cleaner than the previous proposal, and cant wait to actually get 
to use this (as a framework author it literally makes me giddy).

Like others, I slightly wonder what will happen in The Real World™ (as a 
framework consumer) but if things end up too restrictive, it can always be 
changed down the road I would expect…?

>   * 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?
This seems closer to Kotlin; not that I am much of a user of that language so 
maybe I am unqualified to say, but I think its nice to align with a good design 
that exists elsewhere… 
Objc is of course the exact opposite of this, so it remains to be seen what the 
effect will be in this community...

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
Been following this intensely since last year’s initial discussion, finally 
came out of the shadows to comment when it came up for review, and have been 
weighing and listening to arguments for and against; my only "against" feelings 
came about as a consumer of APIs not as a writer, so I want to make sure its 
apparent that any negatives I had in the past were from that perspective; I 
very much support the spirit of this proposal and appreciate those that took 
time to explain and assuage those concerns! What an amazing process this is. ^o^

---

One thing in the proposal:
The superclass of an open class must be open. . These are conservative 
restrictions that reduce the scope of this proposal; it will be possible to 
revisit them in a later proposal.
Yes, maybe its an anit-pattern, but I definitely have made many private parent 
classes and have the child public… the above would mean that I cant do that, as 
open needs public… it would definitely be appreciated if that is revisited or 
at least the reasoning (e.g we really shouldn't be making subclasses of private 
superclasses public because XYZABC etc).

---

Thanks!!


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

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

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

Dear Susan,

I wrote the former mail in a hurry: the URI example from before is a 
*false-positive* either and can be handled like the `Polar` example. But the 
problem with false-negatives are still valid. Example:

```swift
func ==(lhs: A, rhs: B) {
  if(globalBooleanVarIsDayEven) {
return false
  }
  // do a normal check
}
```

This would not be possible, if you check for equality upfront and omitting 
executing the custom code above if the standard check returns `true` already.

Another **big** problem with using `==` for properties to reference types 
implementing `Equatable` is race conditions and as Matt Wright pointed out in 
his talk [Concurrent Programming with GCD in Swift 3][0] on WWDC 2016, there 
are no harmless cases of concurrency issues. Rationale:

Reference types share state possible with code that runs concurrently in 
different threads. So if you compare via `==` to value types and use `==` to 
compare the object(s) of a reference type property this object(s) may change 
during the check (even if the machine has only one core, if the OS is 
preemptive). And this may happen even if it is the very same (by identity and 
`===`) object that is referenced. A (future) automatic value pool for indirect 
storage with copy-on-write for value semantics would not share this problem, of 
course, since their storage is only shared for reads and not for writes (the 
`===` check on this indirect storage would by definition suffice and be much 
faster than executing the check). This does not hold for properties of 
references types in that indirect storage.

[0]: 
http://devstreaming.apple.com/videos/wwdc/2016/720w6g8t9zhd23va0ai/720/720_concurrent_programming_with_gcd_in_swift_3.pdf
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

[Greg Titus via swift-evolution]

> On Jul 15, 2016, at 10:35 PM, Patrick Pijnappel via swift-dev 
>  wrote:
> 
> Isn't half of this done, or something? I seem to remember seeing code about 
> it, and I think there may even be a hidden switch to enable what is there.
>  
> The parsing code seems to be in place, toggled by the flag 
> Context.LangOpts.EnableProtocolTypealiases:
> https://github.com/apple/swift/blob/master/lib/Parse/ParseDecl.cpp#L2080
> 
> Is this still blocked by support elsewhere?

With the EnableProtocolTypealiases flag turned on, some (most?) of this is 
done. You can see the tests in test/decl/typealias/protocol.swift along with 
the remaining FIXMEs. Slava has cleaned up my attempts at it. :-) The last 
commit (a09986f) in this area is him saying "This will be more generally useful 
once I fix a few more issues in name lookup”.

- Greg

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

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

[Karl via swift-evolution]

> On 15 Jul 2016, at 19:46, Ted Kremenek via swift-dev  
> wrote:
> 
> Hi everyone,
> 
> Swift 3 has shaped up to be a remarkable release — a product of the 
> inspiration, ideas, and hard labor many people from across the Swift open 
> source community. It is now time, however, to talk about the endgame for the 
> release.
> 
> Here are the key points:
> 
> The last day to take planned source-breaking changes for Swift 3 is July 27.
> 
> On that day, there will likely be a set of approved-but-not-implemented 
> proposals for Swift 3 — including proposals for source-breaking changes. Will 
> have an open discussion on that day on the fate of those unimplemented 
> proposals in the context of Swift 3 and future Swift releases.
> 
> Starting on August 1 we will open up discussion about Swift 4. Part of this 
> discussion will likely be guided by important work that was deferred from 
> Swift 3, as well as the a goal of achieving binary stability in Swift 4. 
> Until then, however, discussion should remain focused on Swift 3.
> 
> Note that there is an intentional gap of a few days between the last planned 
> day to take source-breaking changes for Swift 3 and when we start talking 
> about Swift 4. The idea is to provide some time for the community to take 
> stock of where things have ended up for Swift 3.
> 
> The final branching plan for Swift 3 development is to be determined, but the 
> final convergence branch is likely to be cut from master around that date or 
> shortly after. Part of it comes down to the discussion on July 27 on how to 
> handle the remaining unimplemented proposals for Swift 3.
> 
> The final release date for Swift 3 is TBD, but essentially after July 27 the 
> intent is that Swift 3 is in full convergence and not in active development.
> 
> With these dates in mind, I want to call attention to some 
> approved-but-not-yet-implemented proposals that currently I have nobody on 
> Apple's Swift team able to tackle in the next couple weeks:
> 
> SE-0042: Flattening the function type of unapplied method references 
> 
> SE-0068: Expanding Swift Self to class members and value types 
> 
> SE-0075: Adding a Build Configuration Import Test 
> 
> SE-0096: Converting dynamicType from a property to an operator 
> 
> SE-0077: Improved operator declarations 
> 
> SE-0092: Typealiases in protocols and protocol extensions 
> 
> SE-0110: Distinguish between single-tuple and multiple-argument function 
> types 
> 
> Some proposals — like SE-0075 
> 
>  — are things we can add at any time, but many of the others tie into the 
> goal of achieving some degree of source-stability for Swift in Swift 3. I'm 
> letting the community know that these proposals currently have no 
> implementation traction in case there is interest in helping make them happen 
> in time for Swift 3.
> 
> Related, I'd like to call out a special thanks to the community for getting 
> implementation traction on SE-0095:
> 
> SE-0095: Replace protocol syntax with P1 & P2 syntax 
> 
> Currently there is a JIRA issue  and 
> pull request  tracking work on 
> implementing this proposal.
> 
> In addition to these language proposals, there is also an assortment of 
> outstanding work for the Standard Library that would be great to do for Swift 
> 3. There is a gist summarizing those tasks:
> 
> https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d 
> 
> These tasks are broken down in relative order of difficulty, with a JIRA 
> issue associated with each one of them. If a JIRA isssue is currently not 
> assigned to anyone, please consider them fair game to tackle if you are 
> interested. API changes that have currently not gone through the evolution 
> process will still need an evolution proposal, even if they are listed in the 
> gist. If you take on a specific task, please assign the JIRA issue to 
> yourself so others know it is being tackled.
> 
> Thank you to everyone — and I mean everyone — who has contributed to making 
> Swift 3 happen.
> 

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Taras Zakharko via swift-evolution]

>   * What is your evaluation of the proposal?

+1. Looks much better than the previous version and makes a lot of sense to me. 

A quick clarification question (I didn’t find any mention of this in the 
proposal, but I might have missed it): what happens if a class is declared 
open, but does not contain any open member declarations? Is this legal? 

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

Most likely

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

Yes

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

A quick reading. I was also following the previous discussion. 


> On 16 Jul 2016, at 07:52, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Anton Zhilin via swift-evolution]

I tried to better describe my alternative solution here
.

The problem with Mirror is that it can only carry a metatype around and
thats it. You may be able to extract it from there and than what? You’ll
cast it the old fashion way.

Could you please explain, what Mirror can’t do? If you only mean
dispatching static members, then see below.

As I may recall I asked the community in the following thread about Hashable
ability, which isn’t implementable without compiler magic and special
internal protocols.

I suggest to move hashability of metatypes to Mirror. Mirror can be Hashable
the same way as your Type.

Your last API for Type doesn’t solve any problems

I suggest to add size etc to Mirror. Static stuff will be handled by my
version of Type and dynamic stuff — by Mirror.

You’re talking about the lack of the ability of dispatching static members
(you also forget initializer)

Could you please cite, where I wrote about that? All 5 solutions I
presented provide this feature using metatypes.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Paul Cantrell via swift-evolution]

Like others, I do find the details of this proposal hard to follow. It doesn’t 
seem like a simpler mental model for developers.

However, I also find the current rules around extension access modifiers hard 
to follow. It’s confusing that “public extension” changes the default for 
members, when “public class” and “public struct” don’t. And this is not ideal:

extension String: Fungible  // Extension not “public”, but the conformance is 
public?

IMO, every public API commitment a module makes should include the word 
“public” at the declaration site.

Because of all this, I have stopped using extension-level access modifiers 
altogether, instead always specifying access at the member level. I would be 
interested in a proposal to improve the current model — perhaps, for example, 
making “public extension” apply only to a protocol conformance, and disabling 
access modifiers on extensions that don’t have a protocol conformance.

Cheers, P

> On Jul 16, 2016, at 11:36 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> If it’s possible I’d like to withdraw this proposal. I’m convinced by the 
> feedback from the community. Feel free to reject it. ;)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>>> On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> As Jordan mentioned, I don't (and I think other people don't) think of 
>>> extensions as their own entities, as they can't be referred to and have no 
>>> runtime representation. In that mental model, there isn't such a thing as 
>>> "an extension being public." Instead, the access modifier is just a 
>>> shorthand default for the properties and methods it contains, which is 
>>> teachable but unique to extensions. It is a matter of opinion whether that 
>>> uniqueness is a feature or a bug.
>> 
>> I would say that it's interesting but ultimately not worth the confusion 
>> about the nature of extensions.
>> 
>> John.
>> 
>>> 
>>> On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez >> > wrote:
>>> 
>>> 
>>> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 
 
 On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution 
 > wrote:
 Proposal link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md
  
 
 
> * What is your evaluation of the proposal?
 -1. Extensions appear to me to follow the access control of the rest of 
 Swift: Implicit to the type you are extending, and you can either / both 
 declare as part of the extension declaration or on the method. I don’t see 
 how this is confusing, and I expect people will be more confused that 
 extensions don’t follow the convention of the rest of Swift for Access 
 Control.
 
 So, actually, the proposal is correct that extensions (at least once 
 fileprivate/private is implemented) don't follow the access control rules 
 for the rest of Swift. There is a problem to be addressed. However, I 
 agree that this proposal hasn't identified the issue or adequately 
 explained how the solution solves it. Here's the problem I'm thinking of:
 
 ```
 public struct foo {
   func frobnicate() { } // implicitly internal
 }
 
 public struct bar { }
 public extension bar {
   func frobnicate() { } // implicitly public
   // at least, according to the revised rules explained in SE-0025
 }
 ```
>>> 
>>> There is definitely a difference, I think that is a good thing. They look 
>>> similar but they are completely different. 
>>> 
>>> public Type // the type is public
>>> public extension Type //  the extension is public 
>>> 
>>> For extensions, public is just a modifier on extension, not the type. The 
>>> default scope inside the extension is that of the "modifier" keyword on the 
>>> extension. 
>>> 
>>> This is easy to explain to someone new. 
>>> 
>>> 
 
 This is an inconsistency that may (and IMO, really is) worth addressing. 
 If there's adequate interest, I can circulate a draft with a proposed 
 solution I have in mind.
  
 
> * Is the problem being addressed significant enough to warrant a change 
> to Swift?
 I don’t think this warrants a change.
 
> * Does this proposal fit well with the feel and direction of Swift?
 No. This seems to go against the direction of Swift.
 
> * If you have used other languages or libraries with a 

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 12:33 AM, Taras Zakharko via swift-evolution 
>  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> +1. Looks much better than the previous version and makes a lot of sense to 
> me. 
> 
> A quick clarification question (I didn’t find any mention of this in the 
> proposal, but I might have missed it): what happens if a class is declared 
> open, but does not contain any open member declarations? Is this legal? 

Yes.  Subclasses can extend the API of the class and add new properties, but 
they can't modify the core behavior of the superclass.  That's not an 
implausible class design, especially as a first step, since it would still be 
source/binary-compatible to make a method open in a later release.

John.

> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Most likely
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> A quick reading. I was also following the previous discussion. 
> 
> 
>> On 16 Jul 2016, at 07:52, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. The proposal is available 
>> here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 12:59 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> * What is your evaluation of the proposal?
> 
> This is improved from the previous iteration. The code example needs 
> updating, as both instances of `open func bar()` should be `public open func 
> bar()` as outlined in the Proposed Design section.

Good catch.  I'll fix this.
 
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, mostly. There is one comment in the code example that describes a 
> restriction which does not fit with the direction of Swift. It is not the 
> main focus of the proposal but I think should be changed. Namely, the 
> proposal comments:
> 
> "[The declaration `[public] open func bar()` inside a class not marked 
> `open`] raises a compilation error: a method can't be marked `open` if the 
> class it belongs to can't be subclassed."
> 
> This is discordant with the direction resolved by the core team in the 
> SE-0025 revisions, where it was stated with regard to access modifiers:
> 
> "The compiler should not warn when a broader level of access control is used 
> within a type with more restrictive access, such as `internal` within a 
> `private` type. This allows the owner of the type to design the access they 
> would use were they to make the type more widely accessible."
> 
> Applying the same rationale here would suggest that the compiler should not 
> raise an error if a method is marked `open` inside a non-`open` type, in 
> order to allow the owner of the type to design as though to make it 
> subclassable without actually having to do so.

That's true.  We'll consider this.

John.

> 
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> Yes, I've used OOP in other languages. As discussed, this approach is 
> different from that taken by many of those but is a deliberate step.
>  
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> Followed the discussion, read proposal carefully.
>  
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Draft] Harmonize access modifiers for extensions

[Xiaodi Wu via swift-evolution]

With the impending withdrawal of SE-0119 and the closing window for (most)
source-breaking changes, I thought I'd draft up a proposal to address some
of the key points raised in that discussion.

The proposed changes are deliberately limited in scope to rationalizing
access modifier rules without adding any new facilities (such as
conformances of lower visibility than the type), which might be more
appropriate for the Swift 4 timeline.

I hope this will prove satisfactory to the community :)


Harmonize access modifiers for extensions

   - Proposal: SE-
   

   - Author: Xiaodi Wu 
   - Status: Awaiting review
   - Review manager: TBD


Introduction

During discussion of SE-0119
,
the community articulated the view that access modifiers for extensions
were and should continue to be subject to the same rules as access
modifiers for types. Unfortunately, it is not factually true today; this
proposal aims to make it so.

Swift-evolution threads:

   - [Proposal] Revising access modifiers on extensions
   

   - [More to be added here]


Motivation

Consider the following:

public struct foo {
  func frobnicate() { } // implicitly internal
}
public extension foo { }

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public, according to SE-0025
}

According to SE-0025, a method moved from the body of a public struct into
a public extension becomes public without modification. This is surprising
behavior contrary to Swift's general rule of not exposing public API by
default.

Furthermore, SE-0025 now permits the owner of a type to design access for
members as though the type will have a higher access level than it
currently does. For example, users will be able to design public methods
inside an internaltype before "flipping the switch" and making that type
public. The same approach is prohibited by SE-0025 for extensions, although
conceptually it need not be.
Proposed
solution

The proposed solution is to change access modifier rules for extensions
with the following effect: if any method (or computed property) declared
within the body of a type at file scope is moved without modification into
the body of an extension in the same file, the move will not change its
accessibility.

In code:

struct foo {
  // Any method declared here...
}
extension foo {
  // ...should have the same visibility when moved here.
}

This implies that public API commitments will need to be annotated as public at
declaration sites inside an extension just as it must be at declaration
sites inside types.
Detailed
design

   1. Declarations inside the extension will, like declarations inside
   types, have a default access level of internal.
   2. The compiler should not warn when a broader level of access control
   is used for a method (or computed property, etc.) declared within an
   extension with more restrictive access. This allows the owner of the
   extension to design the access level they would use for a method if the
   type or extension were to be made more widely accessible.
   3. An extension declared without an explicit access modifier will have
   the same access level as the type being extended.
   4. An extension declared without protocol conformance may optionally use
   an explicit access modifier to provide an upper bound for the visibility of
   its members.

Alternatives
considered

   - One alternative, still open for consideration, is to eliminate #4 and
   disallow explicit access modifiers on extensions. As an advantage, this
   would clarify the mental model that extensions are not their own entities,
   as they cannot be referred to by name and have no runtime representation.
   As a disadvantage, extensions cease to be an access modifier grouping
   construct, which some users really like.


Acknowledgments

Thanks to all discussants on the list, especially Adrian Zubarev and Jose
Cheyo Jimenez.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[T.J. Usiyan via swift-evolution]

"open is invalid on declarations that are not also public (see the
Alternatives discussion for rationale)."
+

"If an open class inherits an open method from a superclass, that method
remains open. If it overrides an open method from a superclass, the
override is implicitly open if it is not final."

I understand that the intent is probably not to say that subclasses are
public by default. My point is that those two statements, without an
explicit spelling out of the implicit access level, could lead me to
believe that subclasses are implicitly public by default. It is open to
interpretation. Neither the prose nor the code examples address it.


On Sat, Jul 16, 2016 at 1:35 PM, John McCall  wrote:

> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> Sent from my iPhone
>
> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Yes, sorry, my point was that this consideration isn't spelled out.
>
> Another question is whether or not making a subclass of an open class
> public by default is what we want. I see why it would be, I just think that
> it is a wrinkle to default to internal otherwise but not here.
>
>
> I can't think of any good reason to assume a specific class should be
> public just because it is a subclass of an open class.  The internal
> default would still be the right default in this case.
>
>
> Right, there's no new restriction here.  Of course you can make a private
> or internal subclass of a public open class — otherwise, you'd have to
> publicize every subclass of (say) UIViewController.
>
> John.
>
>
>
> On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:
>
>>
>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > What happens if I want an `internal` subclass of an `open` class?
>>
>> That should be allowable. You may want some optimised implementations,
>> similar to how Apple used class-clusters in Obj-C. I don’t think that same
>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’
>> in its initialiser, or at least it couldn’t in Swift 1). But the same
>> principle applies - you may want a public class which you don’t allow
>> others to subclass, but you might have a static method or other function
>> which returns an internal optimised implementation.
>>
>> If you used a protocol rather than a concrete type in that case,
>> theoretically others could conform to it and throw their own objects back
>> at your code, which goes against the point of this proposal.
>>
>> We might think about creating ‘sealed’ protocols, too.
>>
>> 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
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan  wrote:
> "open is invalid on declarations that are not also public (see the 
> Alternatives discussion for rationale)."
> 
> +
> 
> "If an open class inherits an open method from a superclass, that method 
> remains open. If it overrides an open method from a superclass, the override 
> is implicitly open if it is not final."
> 
> I understand that the intent is probably not to say that subclasses are 
> public by default. My point is that those two statements, without an explicit 
> spelling out of the implicit access level, could lead me to believe that 
> subclasses are implicitly public by default. It is open to interpretation. 
> Neither the prose nor the code examples address it.

I see your general point.  I'll think about how to re-word this; it may be 
sufficient to just remove the requirement that open methods appear in open 
classes.  Suffice it for me to say now, officially, that this proposal does not 
require classes to be public or open just because they override open methods 
from an open superclass.

John.

> 
> 
> On Sat, Jul 16, 2016 at 1:35 PM, John McCall  > wrote:
>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> Sent from my iPhone
>> 
>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>>> Yes, sorry, my point was that this consideration isn't spelled out. 
>>> 
>>> Another question is whether or not making a subclass of an open class 
>>> public by default is what we want. I see why it would be, I just think that 
>>> it is a wrinkle to default to internal otherwise but not here.
>> 
>> I can't think of any good reason to assume a specific class should be public 
>> just because it is a subclass of an open class.  The internal default would 
>> still be the right default in this case.
> 
> Right, there's no new restriction here.  Of course you can make a private or 
> internal subclass of a public open class — otherwise, you'd have to publicize 
> every subclass of (say) UIViewController.
> 
> John.
> 
>> 
>>> 
>>> On Sat, Jul 16, 2016 at 10:32 AM, Karl >> > wrote:
>>> 
>>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
>>> > > wrote:
>>> >
>>> > What happens if I want an `internal` subclass of an `open` class?
>>> 
>>> That should be allowable. You may want some optimised implementations, 
>>> similar to how Apple used class-clusters in Obj-C. I don’t think that same 
>>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’ 
>>> in its initialiser, or at least it couldn’t in Swift 1). But the same 
>>> principle applies - you may want a public class which you don’t allow 
>>> others to subclass, but you might have a static method or other function 
>>> which returns an internal optimised implementation.
>>> 
>>> If you used a protocol rather than a concrete type in that case, 
>>> theoretically others could conform to it and throw their own objects back 
>>> at your code, which goes against the point of this proposal.
>>> 
>>> We might think about creating ‘sealed’ protocols, too.
>>> 
>>> 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 
>> 
> 

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

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 1:13 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Have you by any chance meant this?
>
> You can extend a class, structure, or enumeration in any access context in
> which the class, structure, or enumeration is available. Any type members
> added in an extension have the same default access level as type members
> declared in the original type being extended. If you extend a public or
> internal type, any new type members you add will have a default access
> level of internal. If you extend a private type, any new type members you
> add will have a default access level of private.
>
> [HERE]: *Alternatively, you can mark an extension with an explicit access
> level modifier (for example, private extension) to set a new default access
> level for all members defined within the extension.*
>
> This new default can still be overridden within the extension for
> individual type members.
>
> Source
> 
>
> This is not according SE–0025 to me. It’s how access control on extensions
> worked all the time (which I misunderstood when posting my first draft).
>

Ah right; it is how it's always worked. I will amend the Motivation section
to say that.

Am 16. Juli 2016 um 20:04:38, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> According to SE-0025, a method moved from the body of a public struct into
> a public extension becomes public without modification. This is surprising
> behavior contrary to Swift's general rule of not exposing public API by
> default.
>
>
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 9:09 AM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift has always gone towards making declarations explicit to read. Having
> open on thé class declaration makes it so you don't have to go hunting into
> its members to see if it contains an open member.
>
> Other comments inline:
>
> On 16 Jul 2016, at 14:49, Andre via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 2016/07/16 21:37、Jean-Daniel Dupas  のメール：
>
> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> 2016/07/15 16:37、Riley Testut via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
>
> FWIW, I'm still against this proposal, but since it will be accepted
> regardless, here are my thoughts:
>
> • Open keyword is significantly better.
> • Members should be *open* by default, and final should be opt-in. If
> you're opening up a class for subclassing, my gut says you should allow the
> client to do as they wish.
>
> If you have a class that was not open yet, just making it open wouldn't
> expose any members: it would then just be subclassable.
>
> If the act of making the class open doesn't implicitly make overriding
> possible, well all you can do then is add methods, and that can be done
> with extensions anyways, so it's not as useful and makes the *public open
> class {}* pattern *just* by itself not so useful imho... 
>
> Also, the keyword 'open' itself may imply 'hey I'm open, please do what
> you want with my public members', whereas 'subclassable' is more specific
> in intention...  (but that's just me, so n=1 and all that)
>
> TLDR; +1 to the above: simpler is better and defaulting to overridable for
> public members on an open class is simpler... invariants can be protected
> by the 'final' keyword.
>
> If we were to default to non-overridable, a more consistent 'open' on the
> method is preferred over overridable for me... open class, open method...
> much better imho...
>
>
> Do we really need an open keyword ?
>
> As already said, if open does nothing more than allowing the class to be
> subclassed, why not simply make the class subclassable if it contains at
> least one overridable member ?
>
> Thats a good point actually… but looks like Review #2 has already started…
> and 'open' is available for both class and method there… I suppose its the
> whole "default to safe", just in case someone made one method 'open' they
> may not have intended to actually make the whole class open… (also see
> below)
>
> In case we require an open keyword, what would happen if someone mark a
> member overridable, but does not make the class open ? Will the compiler
> emit an error, or make the class implicitly « open » ?
>
> In proposal #2 looks like it would generate an error, but Xiaodi Wu has
> said that it should be allowed and not generate an error per SE-0025
> 
> .
>
> Take
> a look at
> :
> "The compiler should not warn when a broader level of access control is
> used within a type with more restrictive access, such as internal within
> a private type."
>
>
> I'm fairly sure that does not apply to open as it's fairly orthogonal to
> other access control modifiers.
>

I agree that the statement in SE-0025 by itself doesn't necessary apply to
`open` because they are somewhat orthogonal. But the stated rationale in
SE-0025 applies equally to `open`, so I think this proposal would be
improved by having `open` behave similarly in this respect. Here's why:

The rationale stated in SE-0025 is that it allows a person who controls the
type to design as though it will have broader access than it actually does.
For instance, I can design an internal class as though it will be public,
and when I'm satisfied with it, I can flip the switch and actually make it
public by adding a single access modifier. That rationale falls down for
classes if I cannot design a `public open` class without already making it
`public open`.

> - Andre
>
> ___
> 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] Seal `T.Type` into `Type`

[Anton Zhilin via swift-evolution]

It looks like Github does not send notifications. Just in case, I’ve
responded here
.

By the way, I very much like how you recommend to use
someType.metatype.staticMethod() and avoid any other usage of metatypes.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 16, 2016, at 9:18 AM, Taras Zakharko  wrote:
> 
> 
>> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution 
>> > wrote:
>> 
>> I agree with Kevin Ballard on being open by default for methods/ properties 
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
>> 
>> 
>> If we are open by default for methods/properties then we could simplify 
>> things by just using final for methods that need to be sealed; I don’t see 
>> the need to have sealed methods/properties outside of the module ONLY. 
> 
> The proposal (and additional comments) explain this point fairly well. 
> Usually, it makes sense to be overridable only for few select members — and 
> compiler can’t easily figure out which entry points these are as the API 
> invariants are not explicit. By making members sealed by default, the API 
> contracts are made more clear.  Second (and a very important reason) is 
> performance — if everything is open by default, the compiler can’t 
> devirtualize property accessors even though it would be appropriate most of 
> the time. The compiler can infer the ‚final‘ status of definitions within a 
> module easily and optimise accordingly, which wot work if these definitions 
> can be overridden externally. To put it differently, its much easier for the 
> compiler to determine what can be safely considered final than what can be 
> safely considered sealed. The design choices in the proposal follow naturally 
> from these considerations. 

The compiler is welcome to optimize my sealed classes but once I slap `open` on 
the class, I am telling the compiler that I am not interested in the automatic 
optimizations imo.

> 
> The final keyword still has its use, although I think its utility will be 
> somewhat diminished after this proposal. You can still use it for things that 
> can’t be overridden internally. Like classes that are intended only to be 
> used as ‚structs  with reference semantics’. 
struct with reference semantics is what sealed classes are, but once I make the 
class open, i’d like for it to act like a regular subclassable class.


> 
> — T
> 
> 
> 

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

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Adrian Zubarev via swift-evolution]

I tried to tackle the ability to write extensions where everyone would be 
forced to write access modifier on member level. That’s what I had in my mind 
all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, 
because you could extend your type with an internal protocol, or the extended 
type might be not public.

Anyways, I’m withdrawing this proposal. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers 
altogether, instead always specifying access at the member level. I would be 
interested in a proposal to improve the current model — perhaps, for example, 
making “public extension” apply only to a protocol conformance, and disabling 
access modifiers on extensions that don’t have a protocol conformance.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Adrian Zubarev via swift-evolution]

I’m responding anything that is related to your last version directly on gist 
rather than here, because it’s me not understanding a few things of that 
version.

That’s why our main version tackles the whole calculation inside Type rather 
than splitting it into the Mirror type.

I’m totally fine to consider in the alternative section. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 18:59:59, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

It looks like Github does not send notifications. Just in case, I’ve responded 
here.

By the way, I very much like how you recommend to use 
someType.metatype.staticMethod() and avoid any other usage of metatypes.

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution 
>  wrote:
> Sent from my iPhone
> 
> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution 
> > wrote:
> 
>> Yes, sorry, my point was that this consideration isn't spelled out. 
>> 
>> Another question is whether or not making a subclass of an open class public 
>> by default is what we want. I see why it would be, I just think that it is a 
>> wrinkle to default to internal otherwise but not here.
> 
> I can't think of any good reason to assume a specific class should be public 
> just because it is a subclass of an open class.  The internal default would 
> still be the right default in this case.

Right, there's no new restriction here.  Of course you can make a private or 
internal subclass of a public open class — otherwise, you'd have to publicize 
every subclass of (say) UIViewController.

John.

> 
>> 
>> On Sat, Jul 16, 2016 at 10:32 AM, Karl > > wrote:
>> 
>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
>> > > wrote:
>> >
>> > What happens if I want an `internal` subclass of an `open` class?
>> 
>> That should be allowable. You may want some optimised implementations, 
>> similar to how Apple used class-clusters in Obj-C. I don’t think that same 
>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’ 
>> in its initialiser, or at least it couldn’t in Swift 1). But the same 
>> principle applies - you may want a public class which you don’t allow others 
>> to subclass, but you might have a static method or other function which 
>> returns an internal optimised implementation.
>> 
>> If you used a protocol rather than a concrete type in that case, 
>> theoretically others could conform to it and throw their own objects back at 
>> your code, which goes against the point of this proposal.
>> 
>> We might think about creating ‘sealed’ protocols, too.
>> 
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 9:05 AM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> +1 as before but I do have concerns
> 
>   * Why do open classes need to have also have open superclasses?

I talk about this in the proposal; this is a possible avenue of future 
extension.  I wanted to keep this proposal small, and requiring the whole 
hierarchy to be open avoids a number of design problems.
 
>   * I don’t think sealed methods/properties as default is the right 
> default. 
>   * If the default was open for methods/properties, then do we really 
> need the sealed keyword? Could’t we just use final for that?

There is no "sealed" keyword in the proposal.

Since we're naming open "open", if we need a reverse, we would probably use 
"closed" or "nonopen" for it.  "sealed" is a common term for this kind of 
feature, and it's the one we've been using in this discussion, but 
unfortunately "sealed" is not a natural opposite of "open".

John.

> 
>>  * 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?
> 
> Requiring super classes to also be Open seems wrong. 
> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 
> 
> We already have to mark all public methods/properties as public, if I need 
> something not the be overridable then I can just use final. This would work 
> the same across all classes. 
> 
> If I was a framework author that initially just had a library that was sealed 
> but then somebody asked me to make it open; All I would want to do is add 
> open to the class only, I would not want to spend the time to go back an add 
> open to all public methods/properties specially if I am already using final. 
> I think having method/properties open by default is the best compromised. I 
> can see framework authors switching a class to be open and expecting that 
> everything in the class in open and if they don’t open any methods, then what 
> possible use is a subclass than an extension could not provide? I think that 
> is an overreach to make the framework author have to add open to every public 
> method in addition to having to open every super class. As a framework author 
> if I think my clients could use subclassing, all I want to do is flip a 
> switch on the classes that I want to make subclass able  and then just push a 
> new version. As a framework user I want to be able to tell my framework 
> author “can you just add open to classes abs and deca etc.” I think it is 
> more likely that I will get my request if it is easy vs it the framework 
> author needs to touch every class in the hierarchy. 
> 
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> n/a
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> reviewed previously and followed the update. 
> 
> ___
> 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] Harmonize access modifiers for extensions

[Adrian Zubarev via swift-evolution]

Have you by any chance meant this?

You can extend a class, structure, or enumeration in any access context in 
which the class, structure, or enumeration is available. Any type members added 
in an extension have the same default access level as type members declared in 
the original type being extended. If you extend a public or internal type, any 
new type members you add will have a default access level of internal. If you 
extend a private type, any new type members you add will have a default access 
level of private.

[HERE]: Alternatively, you can mark an extension with an explicit access level 
modifier (for example, private extension) to set a new default access level for 
all members defined within the extension.

This new default can still be overridden within the extension for individual 
type members.

Source
This is not according SE–0025 to me. It’s how access control on extensions 
worked all the time (which I misunderstood when posting my first draft).



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 20:04:38, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

According to SE-0025, a method moved from the body of a public struct into a 
public extension becomes public without modification. This is surprising 
behavior contrary to Swift's general rule of not exposing public API by default.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan  wrote:
>
> "open is invalid on declarations that are not also public (see the
> Alternatives discussion for rationale)."
> +
>
> "If an open class inherits an open method from a superclass, that method
> remains open. If it overrides an open method from a superclass, the
> override is implicitly open if it is not final."
>
> I understand that the intent is probably not to say that subclasses are
> public by default. My point is that those two statements, without an
> explicit spelling out of the implicit access level, could lead me to
> believe that subclasses are implicitly public by default. It is open to
> interpretation. Neither the prose nor the code examples address it.
>
>
> I see your general point.  I'll think about how to re-word this; it may be
> sufficient to just remove the requirement that open methods appear in open
> classes.  Suffice it for me to say now, officially, that this proposal does
> not require classes to be public or open just because they override open
> methods from an open superclass.
>

It might be barely sufficient solely to remove the requirement that open
methods appear in open classes. However, if my subclass is internal, I
shouldn't be required to declare a `public override` of an open method just
to satisfy the rules for `open`, which would be forced by the rule that
`open` is invalid on declarations that are not also `public` combined with
the rule that overrides of an open method are by default open.

This would degrade the developer experience significantly, since a
beginning developer writing only internal subclasses for their own app
would now be required to litter either `public override` or `final
override` throughout their code in the ordinary course of subclassing. On
reconsideration, it might be best if overrides are not implicitly open.


> John.
>
>
>
> On Sat, Jul 16, 2016 at 1:35 PM, John McCall  wrote:
>
>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> Sent from my iPhone
>>
>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Yes, sorry, my point was that this consideration isn't spelled out.
>>
>> Another question is whether or not making a subclass of an open class
>> public by default is what we want. I see why it would be, I just think that
>> it is a wrinkle to default to internal otherwise but not here.
>>
>>
>> I can't think of any good reason to assume a specific class should be
>> public just because it is a subclass of an open class.  The internal
>> default would still be the right default in this case.
>>
>>
>> Right, there's no new restriction here.  Of course you can make a private
>> or internal subclass of a public open class — otherwise, you'd have to
>> publicize every subclass of (say) UIViewController.
>>
>> John.
>>
>>
>>
>> On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:
>>
>>>
>>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> > What happens if I want an `internal` subclass of an `open` class?
>>>
>>> That should be allowable. You may want some optimised implementations,
>>> similar to how Apple used class-clusters in Obj-C. I don’t think that same
>>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’
>>> in its initialiser, or at least it couldn’t in Swift 1). But the same
>>> principle applies - you may want a public class which you don’t allow
>>> others to subclass, but you might have a static method or other function
>>> which returns an internal optimised implementation.
>>>
>>> If you used a protocol rather than a concrete type in that case,
>>> theoretically others could conform to it and throw their own objects back
>>> at your code, which goes against the point of this proposal.
>>>
>>> We might think about creating ‘sealed’ protocols, too.
>>>
>>> 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
>>
>>
>>
>
>
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Karl via swift-evolution]

> On 15 Jul 2016, at 12:46, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> To sum this all up, the core team is rejecting this proposal and requesting 
>> a revision to change the concrete syntax to “public open class Foo” instead 
>> of “subclassable class Foo".  
> 
> Minor point, but if we're going with the idea of public open and public final 
> for declaration, is it worth re-raising the idea of bracketed accessibility 
> modifiers? When fileprivate vs private was being discussed I was heavily in 
> favour of private(file), private(scope) and private(module) (plus 
> private(type) if we get that) to avoid polluting the language with more 
> accessibility-specific keywords. This seems like a good time to mention it 
> again, as we're now looking at even more keyword pollution:
> 
>   public(open)
>   public(sealed)  // Probably not actually defined, but the 
> default for a plain "public" declaration
>   public(final)
>   private(module) // Replaces internal
>   private(file)
>   private(scope)  // Default for plain private
> 
> If we get a private(type) that's seven different keyword combinations for one 
> feature, so I still very much prefer it being reduced to just public/private 
> plus a modifier ;)

I think it makes sense to have it bracketed, but I’m not sure about replacing 
internal/private/fileprivate.

I’m thinking it should be:

public(open) class XYZ {}
public internal(open) class XYZ {}

Etc

I view it along the same lines as mutability for properties - I.e. “public 
private(set)”.

In that case, it would make sense to do the same for overridable members. You 
can only override members of an open class, so it makes sense to just use the 
“open” name in both places to denote that you may create your own versions of 
these things. An overriden method “is” an instance of the original method in 
the same way a derived class “is” an instance of its base class. My overriden 
“viewDidLoad” or whatever “is” the viewDidLoad for this class.

So to summarise, I think it should look like this (just showing off features, 
obviously it wouldn’t be okay to have public(open) members in an internal(open) 
class...):

public internal(open) XYZ {

public private(set) var nonOverridable : Something
public(open) var overridable : Something

public(open) private(set) var getterOverridable : UIColor?   // In this 
case, the subclass can provide a value in its getter (e.g. backgroundColor) -

  // if it doesn’t (I.e. The type is optional), the base class 
may have a default value stored. I’m not sure… it’s an awkward one.

public(open) func overridePointForSubclasses() {
// Don’t you see so many functions named or documented like this? It’s 
nice that we’ll have them marked-up explicitly.
}
}

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Karl via swift-evolution]

> On 16 Jul 2016, at 16:32, Karl  wrote:
> 
> 
>> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> What happens if I want an `internal` subclass of an `open` class? 
> 
> That should be allowable. You may want some optimised implementations, 
> similar to how Apple used class-clusters in Obj-C. I don’t think that same 
> pattern is exactly possible in Swift (I don’t think a class can set ‘self’ in 
> its initialiser, or at least it couldn’t in Swift 1). But the same principle 
> applies - you may want a public class which you don’t allow others to 
> subclass, but you might have a static method or other function which returns 
> an internal optimised implementation.
> 
> If you used a protocol rather than a concrete type in that case, 
> theoretically others could conform to it and throw their own objects back at 
> your code, which goes against the point of this proposal.
> 
> We might think about creating ‘sealed’ protocols, too.
> 
> Karl

Sorry to mail 3 times in a row, but as I finished I remembered a concrete 
example of where sealed protocols would be helpful:

UIKit has a UITextInput protocol, which is used by custom text object which 
want to interact with the keyboard. It has a delegate property, of type 
UITextInputDelegate (another protocol).

I have seen lots of people try to have their own objects conform to 
UITextInputDelegate and set themselves as the delegate on a UITextInput object. 
That is the wrong usage of the property. You are never supposed to conform to 
UITextInputDelegate; the system has something which conforms to it, and it will 
set itself as your delegate at some point during text input. You use it to 
notify the system about changes to the text content and selection region.

https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextInputDelegate_Protocol/index.html

If it was a sealed protocol, the UIKit API authors would be able to more 
clearly communicate this intention and people wouldn’t be able to fall in this 
trap. The only other way they could do it would be to use a concrete final 
type, which evidently they didn’t want to do (possibly because it has internal 
subclasses and can’t be final).

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

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Taras Zakharko via swift-evolution]

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 

The proposal (and additional comments) explain this point fairly well. Usually, 
it makes sense to be overridable only for few select members — and compiler 
can’t easily figure out which entry points these are as the API invariants are 
not explicit. By making members sealed by default, the API contracts are made 
more clear.  Second (and a very important reason) is performance — if 
everything is open by default, the compiler can’t devirtualize property 
accessors even though it would be appropriate most of the time. The compiler 
can infer the ‚final‘ status of definitions within a module easily and optimise 
accordingly, which wot work if these definitions can be overridden externally. 
To put it differently, its much easier for the compiler to determine what can 
be safely considered final than what can be safely considered sealed. The 
design choices in the proposal follow naturally from these considerations. 

The final keyword still has its use, although I think its utility will be 
somewhat diminished after this proposal. You can still use it for things that 
can’t be overridden internally. Like classes that are intended only to be used 
as ‚structs  with reference semantics‘. 

— T



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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Adrian Zubarev via swift-evolution]

The problem with Mirror is that it can only carry a metatype around and thats 
it. You may be able to extract it from there and than what? You’ll cast it the 
old fashion way.

As I may recall I asked the community in the following thread about Hashable 
ability, which isn’t implementable without compiler magic and special internal 
protocols: [Discussion] Can we make .Type Hashable?

Your last API for Type doesn’t solve any problems:

var size: Int { return sizeof(T.self) } is the wrong way to go.
If you extract a dynamic metatype from your Mirror, you still won’t be able to 
use Type to calculate the right size for it. Not possible with such design.
Static properties do the same as instance properties. With this we could just 
leave MemoryLayout and don’t need Type at all.
You’re talking about the lack of the ability of dispatching static members (you 
also forget initializer), which is not right. We don’t remove the ability to do 
so. It just gets a bottleneck property metatype.

I’m busy completing your last gist with all the mentioned facts. Here is the 
last portion I just finished:

Metatypes

Current metatypes T.Type have one additional feature that Type will not have 
(directly). They can invoke static methods and initializer of types they 
reflect.

Thus, we cannot drop metatypes. But they will be renamed: old T.Type will 
become Metatype and old internal T.self will become T.metatype, where the 
public T.self returns an instance of Type.

Example in Swift 2.2:

protocol HasStatic   { static func staticMethod() -> String }
struct A : HasStatic { static func staticMethod() -> String { return "A" } }
struct B : HasStatic { static func staticMethod() -> String { return "B" } }

func callStatic(_ metatype: HasStatic.Type) {
// `Type` cannot do this, but there will be a  
// bottleneck property `metatype` to achieve this.
let result = metatype.staticMethod()   
print(result)
}

let a = A.self
let b = B.self
callStatic(a)  //=> A
callStatic(b)  //=> B
In other words, metatypes (continue to) allow dynamic polymorphism for static 
methods.

After this proposal we will have two distinct ways to achieve the same result:

// Version 1:
func callStatic(_ metatype: Metatype) {
let result = metatype.staticMethod()   
print(result)
}

let a = A.self.metatype
let b = B.self.metatype
callStatic(a)  //=> A
callStatic(b)  //=> B

// Version 2:
func callStatic(_ type: Type) {
let result = type.metatype.staticMethod()   
print(result)
}

let a = Type(casting: A.self)!
let b = Type(casting: B.self)!
callStatic(a)  //=> A
callStatic(b)  //=> B
Everything is still possible, only the casting becomes a little clumsy. 
Therefore I’ll add section about dynamic casts such as as, as?, as! and is 
which needs a little tweaking. As I already showed in my last post. It’s 
totally safe to introduce this tweaking post Swift 3.

Please stay patient and let me finish the addition.



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 14:19:08, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

My suggestion 
#2
Allow labelless initialization of 
Mirror from metatype or from value
Move dynamic 
size, 
stride, 
alignment to 
Mirror

T.self and future type literals will create instances of 
Type
struct Type {
init()

var size: Int { return sizeof(T.self) }
var stride: Int { return strideof(T.self) }
var alignment: Int { return alignof(T.self) }
static var size: Int { return sizeof(T.self) }
static var stride: Int { return strideof(T.self) }
static var alignment: Int { return alignof(T.self) }

var metatype: Metatype { return T.metatype }
static var metatype: Metatype { return T.metatype }

// Nothing more; no fields!
}
Metatypes will be typically created using 
Type.metatype and 
dynamicType

Pro Both static and dynamic 
size, 
stride, 
alignment are in logically suited contexts

Pro Metatypes (with which few people will work) are separated from static types 
(which are used for function specialization etc)

Con Additional entity 
Type, but I think it’s the most elegant of all solutions that introduce 
additional types
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[T.J. Usiyan via swift-evolution]

Yes, sorry, my point was that this consideration isn't spelled out.

Another question is whether or not making a subclass of an open class
public by default is what we want. I see why it would be, I just think that
it is a wrinkle to default to internal otherwise but not here.


On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:

>
> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > What happens if I want an `internal` subclass of an `open` class?
>
> That should be allowable. You may want some optimised implementations,
> similar to how Apple used class-clusters in Obj-C. I don’t think that same
> pattern is exactly possible in Swift (I don’t think a class can set ‘self’
> in its initialiser, or at least it couldn’t in Swift 1). But the same
> principle applies - you may want a public class which you don’t allow
> others to subclass, but you might have a static method or other function
> which returns an internal optimised implementation.
>
> If you used a protocol rather than a concrete type in that case,
> theoretically others could conform to it and throw their own objects back
> at your code, which goes against the point of this proposal.
>
> We might think about creating ‘sealed’ protocols, too.
>
> Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Jose Cheyo Jimenez via swift-evolution]

>   * What is your evaluation of the proposal?

+1 as before but I do have concerns

* Why do open classes need to have also have open superclasses? 
* I don’t think sealed methods/properties as default is the right 
default. 
* If the default was open for methods/properties, then do we really 
need the sealed keyword? Could’t we just use final for that?

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

Requiring super classes to also be Open seems wrong. 

I agree with Kevin Ballard on being open by default for methods/ properties 
http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 


If we are open by default for methods/properties then we could simplify things 
by just using final for methods that need to be sealed; I don’t see the need to 
have sealed methods/properties outside of the module ONLY. 

We already have to mark all public methods/properties as public, if I need 
something not the be overridable then I can just use final. This would work the 
same across all classes. 

If I was a framework author that initially just had a library that was sealed 
but then somebody asked me to make it open; All I would want to do is add open 
to the class only, I would not want to spend the time to go back an add open to 
all public methods/properties specially if I am already using final. I think 
having method/properties open by default is the best compromised. I can see 
framework authors switching a class to be open and expecting that everything in 
the class in open and if they don’t open any methods, then what possible use is 
a subclass than an extension could not provide? I think that is an overreach to 
make the framework author have to add open to every public method in addition 
to having to open every super class. As a framework author if I think my 
clients could use subclassing, all I want to do is flip a switch on the classes 
that I want to make subclass able  and then just push a new version. As a 
framework user I want to be able to tell my framework author “can you just add 
open to classes abs and deca etc.” I think it is more likely that I will get my 
request if it is easy vs it the framework author needs to touch every class in 
the hierarchy. 


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
n/a
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

reviewed previously and followed the update. 

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

Re: [swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

[Hooman Mehr via swift-evolution]

+1 

Same answers.

> On Jul 15, 2016, at 10:54 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> * What is your evaluation of the proposal?
> 
> +1
>  
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> 
> Yes, minor but important.
>  
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, it's consistent with other existing APIs, and it's intuitive.
> 
>  
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> N/A
>  
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> Quick reading of the proposal. 
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> Yes, sorry, my point was that this consideration isn't spelled out. 
> 
> Another question is whether or not making a subclass of an open class public 
> by default is what we want. I see why it would be, I just think that it is a 
> wrinkle to default to internal otherwise but not here.

I can't think of any good reason to assume a specific class should be public 
just because it is a subclass of an open class.  The internal default would 
still be the right default in this case.

> 
>> On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:
>> 
>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
>> >  wrote:
>> >
>> > What happens if I want an `internal` subclass of an `open` class?
>> 
>> That should be allowable. You may want some optimised implementations, 
>> similar to how Apple used class-clusters in Obj-C. I don’t think that same 
>> pattern is exactly possible in Swift (I don’t think a class can set ‘self’ 
>> in its initialiser, or at least it couldn’t in Swift 1). But the same 
>> principle applies - you may want a public class which you don’t allow others 
>> to subclass, but you might have a static method or other function which 
>> returns an internal optimised implementation.
>> 
>> If you used a protocol rather than a concrete type in that case, 
>> theoretically others could conform to it and throw their own objects back at 
>> your code, which goes against the point of this proposal.
>> 
>> We might think about creating ‘sealed’ protocols, too.
>> 
>> 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] [Review] SE-0119: Remove access modifiers from extensions

[Adrian Zubarev via swift-evolution]

If it’s possible I’d like to withdraw this proposal. I’m convinced by the 
feedback from the community. Feel free to reject it. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution 
(swift-evolution@swift.org) schrieb:

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution 
 wrote:
As Jordan mentioned, I don't (and I think other people don't) think of 
extensions as their own entities, as they can't be referred to and have no 
runtime representation. In that mental model, there isn't such a thing as "an 
extension being public." Instead, the access modifier is just a shorthand 
default for the properties and methods it contains, which is teachable but 
unique to extensions. It is a matter of opinion whether that uniqueness is a 
feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about 
the nature of extensions.

John.


On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez  wrote:


On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution 
 wrote:



On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution 
 wrote:
Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md

* What is your evaluation of the proposal?
-1. Extensions appear to me to follow the access control of the rest of Swift: 
Implicit to the type you are extending, and you can either / both declare as 
part of the extension declaration or on the method. I don’t see how this is 
confusing, and I expect people will be more confused that extensions don’t 
follow the convention of the rest of Swift for Access Control.

So, actually, the proposal is correct that extensions (at least once 
fileprivate/private is implemented) don't follow the access control rules for 
the rest of Swift. There is a problem to be addressed. However, I agree that 
this proposal hasn't identified the issue or adequately explained how the 
solution solves it. Here's the problem I'm thinking of:

```
public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}
```

There is definitely a difference, I think that is a good thing. They look 
similar but they are completely different. 

public Type // the type is public
public extension Type //  the extension is public 

For extensions, public is just a modifier on extension, not the type. The 
default scope inside the extension is that of the "modifier" keyword on the 
extension. 

This is easy to explain to someone new. 



This is an inconsistency that may (and IMO, really is) worth addressing. If 
there's adequate interest, I can circulate a draft with a proposed solution I 
have in mind.
 

* Is the problem being addressed significant enough to warrant a change to 
Swift?
I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?
No. This seems to go against the direction of Swift.

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

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


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


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

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

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

[Anton Zhilin via swift-evolution]

I will now talk about general design, not specific methods or
implementation details. This touches SE-0101.

The following are niches for metatype-like types:

   1. Explicit specialization of functions and expressing specific static
   types
   2. Dynamic dispatch of static methods
   3. Passing around information about dynamic type; reflection
   4. Container for size, stride, alignment

Basic thoughs on each of them (trying to be objective!):

   1. We must have a generic type. Even struct Type { } would be enough
   (I’m not suggesting it). Current T.Type can also do that
   2. Only metatypes (current T.Type) can do that
   3. Is best expressed using a non-generic type like Mirror
   4. Can be dropped on top of metatypes (global functions), or Mirror
   (properties plus global functions) or whatever custom type (properties).

So, we give (2) to metatypes, because we must do so, and give (3) to Mirror.
Now to opinionated side. The following are solutions I could come up with:

   1. Current state of things
  - Metatypes do (1)
  - Global functions on metatypes do (4)
  - Pro No extra entities, just metatypes and Mirror
  - Pro Functions on metatypes are not perfect, but they are “good
  enough”
  - Con Mixed static type instances and metatypes. Value of passed
  metatypes is often ignored
  - Con Some people hate global functions (although they are right
  solution for “methods of metatypes”)
   2. Proposal of this thread; Type struct
  - Type is a wrapper for metatypes
  - The shortest syntax (.self and type literals) is passed from
  metatypes to Type
  - Type does (1) and (4)
  - Pro Groups of size, stride, alignment in a logical context
  - Con Again, mixed static type instances and Type
  - Con Additional entity Type
  - Con Type partially takes work of Mirror (dynamic size, stride,
  align)
   3. MemoryLayout proposal
  - Metatypes do (1)
  - MemoryLayout contains size, stride, alignment
  - Con Again, mixed static type instances and metatypes
  - Con Additional MemoryLayout entity, which only hosts 3 functions
  - Con MemoryLayout is not able to get size of dynamicType by design
   4. My suggestion #1
  - Allow labelless initialization of Mirror from metatype or from value
  - Move dynamic size, stride, alignment to Mirror
  - Leave static size, stride, alignment as global functions
  - Pro Does not introduce new entities
  - Pro I feel like this is the perfect place for dynamic size, stride,
  alignment
  - Con Again, mixed static type instances and metatypes
  - Con Global functions. I’m fine with them, but some people don’t
  like them
   5. My suggestion #2
  - Allow labelless initialization of Mirror from metatype or from value
  - Move dynamic size, stride, alignment to Mirror
  - T.self and future type literals will create instances of Type

struct Type {
init()

var size: Int { return sizeof(T.self) }
var stride: Int { return strideof(T.self) }
var alignment: Int { return alignof(T.self) }
static var size: Int { return sizeof(T.self) }
static var stride: Int { return strideof(T.self) }
static var alignment: Int { return alignof(T.self) }

var metatype: Metatype { return T.metatype }
static var metatype: Metatype { return T.metatype }

// Nothing more; no fields!
}


   - Metatypes will be typically created using Type.metatype and
   dynamicType
   - Pro Both static and dynamic size, stride, alignment are in logically
   suited contexts
   - Pro Metatypes (with which few people will work) are separated from
   static types (which are used for function specialization etc)
   - Con Additional entity Type, but I think it’s the most elegant of
   all solutions that introduce additional types

I will prepare a separate proposal with this last option.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution 
>  a écrit :
> 
> 2016/07/15 16:37、Riley Testut via swift-evolution  > のメッセージ:
> 
>> FWIW, I'm still against this proposal, but since it will be accepted 
>> regardless, here are my thoughts:
>> 
>> • Open keyword is significantly better. 
>> • Members should be *open* by default, and final should be opt-in. If you're 
>> opening up a class for subclassing, my gut says you should allow the client 
>> to do as they wish.
> If you have a class that was not open yet, just making it open wouldn't 
> expose any members: it would then just be subclassable.
> 
> If the act of making the class open doesn't implicitly make overriding 
> possible, well all you can do then is add methods, and that can be done with 
> extensions anyways, so it's not as useful and makes the public open class {} 
> pattern just by itself not so useful imho... 
> 
> Also, the keyword 'open' itself may imply 'hey I'm open, please do what you 
> want with my public members', whereas 'subclassable' is more specific in 
> intention...  (but that's just me, so n=1 and all that)
> 
> TLDR; +1 to the above: simpler is better and defaulting to overridable for 
> public members on an open class is simpler... invariants can be protected by 
> the 'final' keyword.
> 
> If we were to default to non-overridable, a more consistent 'open' on the 
> method is preferred over overridable for me... open class, open method... 
> much better imho...

Do we really need an open keyword ?

As already said, if open does nothing more than allowing the class to be 
subclassed, why not simply make the class subclassable if it contains at least 
one overridable member ?

In case we require an open keyword, what would happen if someone mark a member 
overridable, but does not make the class open ? Will the compiler emit an 
error, or make the class implicitly « open » ? 

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Andre via swift-evolution]

> 2016/07/16 21:37、Jean-Daniel Dupas  のメール：
> 
>> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution 
>> > a écrit :
>> 
>> 2016/07/15 16:37、Riley Testut via swift-evolution > > のメッセージ:
>> 
>>> FWIW, I'm still against this proposal, but since it will be accepted 
>>> regardless, here are my thoughts:
>>> 
>>> • Open keyword is significantly better. 
>>> • Members should be *open* by default, and final should be opt-in. If 
>>> you're opening up a class for subclassing, my gut says you should allow the 
>>> client to do as they wish.
>> If you have a class that was not open yet, just making it open wouldn't 
>> expose any members: it would then just be subclassable.
>> 
>> If the act of making the class open doesn't implicitly make overriding 
>> possible, well all you can do then is add methods, and that can be done with 
>> extensions anyways, so it's not as useful and makes the public open class {} 
>> pattern just by itself not so useful imho... 
>> 
>> Also, the keyword 'open' itself may imply 'hey I'm open, please do what you 
>> want with my public members', whereas 'subclassable' is more specific in 
>> intention...  (but that's just me, so n=1 and all that)
>> 
>> TLDR; +1 to the above: simpler is better and defaulting to overridable for 
>> public members on an open class is simpler... invariants can be protected by 
>> the 'final' keyword.
>> 
>> If we were to default to non-overridable, a more consistent 'open' on the 
>> method is preferred over overridable for me... open class, open method... 
>> much better imho...
> 
> Do we really need an open keyword ?
> 
> As already said, if open does nothing more than allowing the class to be 
> subclassed, why not simply make the class subclassable if it contains at 
> least one overridable member ?
Thats a good point actually… but looks like Review #2 has already started… and 
'open' is available for both class and method there… I suppose its the whole 
"default to safe", just in case someone made one method 'open' they may not 
have intended to actually make the whole class open… (also see below)

> In case we require an open keyword, what would happen if someone mark a 
> member overridable, but does not make the class open ? Will the compiler emit 
> an error, or make the class implicitly « open » ? 
In proposal #2 looks like it would generate an error, but Xiaodi Wu has said 
that it should be allowed and not generate an error per SE-0025 
.
 
Take
 a look at 
:
 "The compiler should not warn when a broader level of access control is used 
within a type with more restrictive access, such as internal within a private 
type."

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

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

Dear Saagar,

> Am 15.07.2016 um 19:05 schrieb Saagar Jha :
> 
> Equatable, where the == operator is defined, will not let you compare two 
> things of a different type. 

This is not true for reference types. Consider the following **bad** (but 
compiling code):

```swift
class A: Equatable {}

class Aa: A {
let a: Int

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

func ==(lhs: A, rhs: A) -> Bool {
return lhs === rhs
}

func ==(lhs: Aa, rhs: Aa) -> Bool {
return lhs.a == rhs.a
}
```

Now let us use this:

```swift
let a = A()
let a2 = A()
let aa = Aa(a: 0)
let aa2 = Aa(a: 1)
let aa3 = Aa(a: 1)

// prints `true`
print(a == a)

// prints `false`
print(a == a2)

// prints `false`
print(a == aa)

// prints `false`
print(a == aa3)

// prints `false`
print(aa == aa2)

// prints `true` because it compares the `a: Int` values.
print(aa2 == aa3)

// now mixed-type comparison (returns `false`)
print(a == aa2)
```

Hence, you can do mixed-type equality checks in Swift. Even worse is, you can 
do this:

```swift
let aa2AsA: A = aa2,
aa3AsA: A = aa3

// prints `true` because it compares the `a: Int` values.
print(aa2 == aa3)

// prints `false`, because the equals method of `A` is used
print(aa2AsA == aa3AsA)
```

Just by assigning an object to a variable that is typed differently the result 
is completely different. This is because method parameters are dispatched 
statically. This is fast, but results in really unintended results, you can do 
a **lot** of things breaking the contract of `==` with that. This is why I 
wanted to add a `default` clause (in *3.* of my original proposal) for such 
methods involving two references to `Self`. Further on, I wanted to add the 
keyword `dispatch` for method (and operator) parameters, where dispatching is 
necessary (see *2.* of my original proposal).

I think these changes are crucial for the safety of the language. Now you can 
write really bad code and the compiler/IDE doesn’t help you. You may do the 
dynamic dispatch manually, but this is error-prone (and many developers aren’t 
even aware of the issue).

All the best
Johannes
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[David Hart via swift-evolution]

Swift has always gone towards making declarations explicit to read. Having open 
on thé class declaration makes it so you don't have to go hunting into its 
members to see if it contains an open member.

Other comments inline:

> On 16 Jul 2016, at 14:49, Andre via swift-evolution 
>  wrote:
> 
> 
>> 2016/07/16 21:37、Jean-Daniel Dupas  のメール：
>> 
>>> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution 
>>>  a écrit :
>>> 
>>> 2016/07/15 16:37、Riley Testut via swift-evolution 
>>>  のメッセージ:
>>> 
 FWIW, I'm still against this proposal, but since it will be accepted 
 regardless, here are my thoughts:
 
 • Open keyword is significantly better. 
 • Members should be *open* by default, and final should be opt-in. If 
 you're opening up a class for subclassing, my gut says you should allow 
 the client to do as they wish.
>>> If you have a class that was not open yet, just making it open wouldn't 
>>> expose any members: it would then just be subclassable.
>>> 
>>> If the act of making the class open doesn't implicitly make overriding 
>>> possible, well all you can do then is add methods, and that can be done 
>>> with extensions anyways, so it's not as useful and makes the public open 
>>> class {} pattern just by itself not so useful imho... 
>>> 
>>> Also, the keyword 'open' itself may imply 'hey I'm open, please do what you 
>>> want with my public members', whereas 'subclassable' is more specific in 
>>> intention...  (but that's just me, so n=1 and all that)
>>> 
>>> TLDR; +1 to the above: simpler is better and defaulting to overridable for 
>>> public members on an open class is simpler... invariants can be protected 
>>> by the 'final' keyword.
>>> 
>>> If we were to default to non-overridable, a more consistent 'open' on the 
>>> method is preferred over overridable for me... open class, open method... 
>>> much better imho...
>> 
>> Do we really need an open keyword ?
>> 
>> As already said, if open does nothing more than allowing the class to be 
>> subclassed, why not simply make the class subclassable if it contains at 
>> least one overridable member ?
> Thats a good point actually… but looks like Review #2 has already started… 
> and 'open' is available for both class and method there… I suppose its the 
> whole "default to safe", just in case someone made one method 'open' they may 
> not have intended to actually make the whole class open… (also see below)
> 
>> In case we require an open keyword, what would happen if someone mark a 
>> member overridable, but does not make the class open ? Will the compiler 
>> emit an error, or make the class implicitly « open » ? 
> In proposal #2 looks like it would generate an error, but Xiaodi Wu has said 
> that it should be allowed and not generate an error per SE-0025.
> Take a look at: "The compiler should not warn when a broader level of access 
> control is used within a type with more restrictive access, such as internal 
> within a private type."

I'm fairly sure that does not apply to open as it's fairly orthogonal to other 
access control modifiers.

> - Andre
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[T.J. Usiyan via swift-evolution]

What happens if I want an `internal` subclass of an `open` class?

On Sat, Jul 16, 2016 at 10:09 AM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift has always gone towards making declarations explicit to read. Having
> open on thé class declaration makes it so you don't have to go hunting into
> its members to see if it contains an open member.
>
> Other comments inline:
>
> On 16 Jul 2016, at 14:49, Andre via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 2016/07/16 21:37、Jean-Daniel Dupas  のメール：
>
> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> 2016/07/15 16:37、Riley Testut via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
>
> FWIW, I'm still against this proposal, but since it will be accepted
> regardless, here are my thoughts:
>
> • Open keyword is significantly better.
> • Members should be *open* by default, and final should be opt-in. If
> you're opening up a class for subclassing, my gut says you should allow the
> client to do as they wish.
>
> If you have a class that was not open yet, just making it open wouldn't
> expose any members: it would then just be subclassable.
>
> If the act of making the class open doesn't implicitly make overriding
> possible, well all you can do then is add methods, and that can be done
> with extensions anyways, so it's not as useful and makes the *public open
> class {}* pattern *just* by itself not so useful imho... 
>
> Also, the keyword 'open' itself may imply 'hey I'm open, please do what
> you want with my public members', whereas 'subclassable' is more specific
> in intention...  (but that's just me, so n=1 and all that)
>
> TLDR; +1 to the above: simpler is better and defaulting to overridable for
> public members on an open class is simpler... invariants can be protected
> by the 'final' keyword.
>
> If we were to default to non-overridable, a more consistent 'open' on the
> method is preferred over overridable for me... open class, open method...
> much better imho...
>
>
> Do we really need an open keyword ?
>
> As already said, if open does nothing more than allowing the class to be
> subclassed, why not simply make the class subclassable if it contains at
> least one overridable member ?
>
> Thats a good point actually… but looks like Review #2 has already started…
> and 'open' is available for both class and method there… I suppose its the
> whole "default to safe", just in case someone made one method 'open' they
> may not have intended to actually make the whole class open… (also see
> below)
>
> In case we require an open keyword, what would happen if someone mark a
> member overridable, but does not make the class open ? Will the compiler
> emit an error, or make the class implicitly « open » ?
>
> In proposal #2 looks like it would generate an error, but Xiaodi Wu has
> said that it should be allowed and not generate an error per SE-0025
> 
> .
>
> Take
> a look at
> :
> "The compiler should not warn when a broader level of access control is
> used within a type with more restrictive access, such as internal within
> a private type."
>
>
> I'm fairly sure that does not apply to open as it's fairly orthogonal to
> other access control modifiers.
>
> - Andre
>
> ___
> 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] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Johannes Neubauer via swift-evolution]

In order to prevent false-negatives for reference types, I would like to add a 
5th. point to my proposals:

5. Identity (i.e. `===`) should be checked even for reference types upfront and 
only if it returns `false` the custom `==` function of the developer is 
executed. This way you cannot implement an equals operator, that says two 
objects are **not** equal although they are the very same instance.


> Am 16.07.2016 um 13:50 schrieb Johannes Neubauer via swift-evolution 
> :
> 
> I wrote the former mail in a hurry: the URI example from before is a 
> *false-positive* either and can be handled like the `Polar` example. But the 
> problem with false-negatives are still valid. Example:
> 
> ```swift
> func ==(lhs: A, rhs: B) {
>  if(globalBooleanVarIsDayEven) {
>return false
>  }
>  // do a normal check
> }
> ```
> 
> This would not be possible, if you check for equality upfront and omitting 
> executing the custom code above if the standard check returns `true` already.
> 
> Another **big** problem with using `==` for properties to reference types 
> implementing `Equatable` is race conditions and as Matt Wright pointed out in 
> his talk [Concurrent Programming with GCD in Swift 3][0] on WWDC 2016, there 
> are no harmless cases of concurrency issues. Rationale:
> 
> Reference types share state possible with code that runs concurrently in 
> different threads. So if you compare via `==` to value types and use `==` to 
> compare the object(s) of a reference type property this object(s) may change 
> during the check (even if the machine has only one core, if the OS is 
> preemptive). And this may happen even if it is the very same (by identity and 
> `===`) object that is referenced. A (future) automatic value pool for 
> indirect storage with copy-on-write for value semantics would not share this 
> problem, of course, since their storage is only shared for reads and not for 
> writes (the `===` check on this indirect storage would by definition suffice 
> and be much faster than executing the check). This does not hold for 
> properties of references types in that indirect storage.
> 
> [0]: 
> http://devstreaming.apple.com/videos/wwdc/2016/720w6g8t9zhd23va0ai/720/720_concurrent_programming_with_gcd_in_swift_3.pdf

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

Re: [swift-evolution] Fixing modules that contain a type with the same name

[Félix Cloutier via swift-evolution]

There is about 2 weeks left for source-breaking proposals, and this is going to 
be one of them. How is progress going? Do you think that you'll have enough 
time to push it out of the door?

Félix

> Le 20 juin 2016 à 17:33:03, Paulo Faria  a écrit :
> 
> Yeah! I’m working on a formal proposal that would solve the same problem. 
> Jordan, the problem he described is exactly like the one you explained to me, 
> haha. Now I’m a bit confused about how the proposal should be called. Have 
> any suggestions? What title could fit the two use cases we mentioned. By the 
> way, can you see any other use case that would be solved with the same 
> solution?
> 
> 
>> On Jun 20, 2016, at 9:25 PM, Jordan Rose > > wrote:
>> 
>> I've been encouraging Paulo Faria to mention this case in his push for a way 
>> to disambiguate extension methods, with the thought being we could then use 
>> the same syntax to differentiate top-level names as well.
>> 
>> I'd also be happy with the "import as" syntax. The underscore syntax seems a 
>> little opaque, but I suppose it wouldn't come up very often.
>> 
>> Jordan
>> 
>> 
>>> On Jun 17, 2016, at 19:52, Félix Cloutier via swift-evolution 
>>> > wrote:
>>> 
>>> Hello all,
>>> 
>>> I recently ran into a bug  that 
>>> leaves me unable to fully-qualify the name of a type. If you import a 
>>> module named Foo that also contains a type named Foo, attempts to 
>>> fully-qualify any name in the Foo module will instead attempt to find 
>>> something inside the Foo type. This bug has already been reported 
>>> .
>>> 
>>> Here's an example with Károly Lőrentey's BTree module (which also contains 
>>> a BTree type) that I encountered while trying to use the OrderedSet type:
>>> 
>>> let set = OrderedSet()
>>> // error: 'OrderedSet' is ambiguous for type lookup in this context
>>> // Found this candidate: Foundation.OrderedSet:3:14
>>> // Found this candidate: BTree.OrderedSet:12:15
>>> To solve this, you would normally write BTree.OrderedSet, but now Swift 
>>> thinks that BTree is the BTree type, not the BTree module:
>>> 
>>> let set = BTree.OrderedSet()
>>> // error: reference to generic type 'BTree' requires arguments in <...>
>>> Any fix will require a change to the language, and as Jordan Rose stated on 
>>> the bug, it "needs design", so I would like to bring up the issue and 
>>> discuss possible solutions.
>>> 
>>> I can see several options (leaving "do nothing" aside, since I believe that 
>>> this needs to be resolved):
>>> 
>>> Prevent modules from containing a type with the same name
>>> Allow modules to be imported under different names (`import BTree as 
>>> BTreeModule`, `import BTreeModule = BTree` or any similar syntax)
>>> Create a new syntax that indicates that you're naming a module, not a type 
>>> (like `_.BTree.OrderedSet`)
>>> 
>>> Thoughts?
>>> 
>>> Félix
>>> 
>>> ___
>>> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[John McCall via swift-evolution]

> On Jul 16, 2016, at 11:48 AM, Xiaodi Wu  wrote:
> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution 
> > wrote:
>> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan > > wrote:
>> "open is invalid on declarations that are not also public (see the 
>> Alternatives discussion for rationale)."
>> 
>> +
>> 
>> "If an open class inherits an open method from a superclass, that method 
>> remains open. If it overrides an open method from a superclass, the override 
>> is implicitly open if it is not final."
>> 
>> I understand that the intent is probably not to say that subclasses are 
>> public by default. My point is that those two statements, without an 
>> explicit spelling out of the implicit access level, could lead me to believe 
>> that subclasses are implicitly public by default. It is open to 
>> interpretation. Neither the prose nor the code examples address it.
> 
> I see your general point.  I'll think about how to re-word this; it may be 
> sufficient to just remove the requirement that open methods appear in open 
> classes.  Suffice it for me to say now, officially, that this proposal does 
> not require classes to be public or open just because they override open 
> methods from an open superclass.
> 
> It might be barely sufficient solely to remove the requirement that open 
> methods appear in open classes. However, if my subclass is internal, I 
> shouldn't be required to declare a `public override` of an open method just 
> to satisfy the rules for `open`, which would be forced by the rule that 
> `open` is invalid on declarations that are not also `public`

This rule only applies to explicit uses of "open".  A method that is implicitly 
open due to overriding does not have this restriction.

In general, my intent in writing this proposal was to cover the important 
interactions, not to write a fully precise specification.  The general rule 
about overrides having to be at least as accessible as the minimum of their 
class and their overridden method still applies, superseded only by the rule 
that it is acceptable to drop the "open" on a public open override.

> combined with the rule that overrides of an open method are by default open.

> This would degrade the developer experience significantly, since a beginning 
> developer writing only internal subclasses for their own app would now be 
> required to litter either `public override` or `final override` throughout 
> their code in the ordinary course of subclassing. On reconsideration, it 
> might be best if overrides are not implicitly open.

I continue to think "override" is sufficient communication here.  We're not 
going to have a model where the inherited open API of the superclass becomes 
non-open in the subclass.  We don't want the mere existence of an override in 
the subclass to change that because it's a fairly core goal that the existence 
of an override (at least one which doesn't covariantly refine the type) in a 
subclass should not affect source/binary compatibility.

John.


> 
> 
> John.
> 
>> 
>> 
>> On Sat, Jul 16, 2016 at 1:35 PM, John McCall > > wrote:
>>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> Sent from my iPhone
>>> 
>>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution 
>>> > wrote:
>>> 
 Yes, sorry, my point was that this consideration isn't spelled out. 
 
 Another question is whether or not making a subclass of an open class 
 public by default is what we want. I see why it would be, I just think 
 that it is a wrinkle to default to internal otherwise but not here.
>>> 
>>> I can't think of any good reason to assume a specific class should be 
>>> public just because it is a subclass of an open class.  The internal 
>>> default would still be the right default in this case.
>> 
>> Right, there's no new restriction here.  Of course you can make a private or 
>> internal subclass of a public open class — otherwise, you'd have to 
>> publicize every subclass of (say) UIViewController.
>> 
>> John.
>> 
>>> 
 
 On Sat, Jul 16, 2016 at 10:32 AM, Karl > wrote:
 
 > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
 > > wrote:
 >
 > What happens if I want an `internal` subclass of an `open` class?
 
 That should be allowable. You may want some optimised implementations, 
 similar to how Apple used class-clusters in Obj-C. I don’t think that same 
 pattern is exactly possible in Swift (I don’t think a class can set ‘self’ 
 in its initialiser, or at least it couldn’t 

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

Makes sense. Thanks for clarifying.


On Sat, Jul 16, 2016 at 14:17 John McCall  wrote:

> On Jul 16, 2016, at 11:48 AM, Xiaodi Wu  wrote:
> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan  wrote:
>>
>> "open is invalid on declarations that are not also public (see the
>> Alternatives discussion for rationale)."
>> +
>>
>> "If an open class inherits an open method from a superclass, that method
>> remains open. If it overrides an open method from a superclass, the
>> override is implicitly open if it is not final."
>>
>> I understand that the intent is probably not to say that subclasses are
>> public by default. My point is that those two statements, without an
>> explicit spelling out of the implicit access level, could lead me to
>> believe that subclasses are implicitly public by default. It is open to
>> interpretation. Neither the prose nor the code examples address it.
>>
>>
>> I see your general point.  I'll think about how to re-word this; it may
>> be sufficient to just remove the requirement that open methods appear in
>> open classes.  Suffice it for me to say now, officially, that this proposal
>> does not require classes to be public or open just because they override
>> open methods from an open superclass.
>>
>
> It might be barely sufficient solely to remove the requirement that open
> methods appear in open classes. However, if my subclass is internal, I
> shouldn't be required to declare a `public override` of an open method just
> to satisfy the rules for `open`, which would be forced by the rule that
> `open` is invalid on declarations that are not also `public`
>
>
> This rule only applies to explicit uses of "open".  A method that is
> implicitly open due to overriding does not have this restriction.
>
> In general, my intent in writing this proposal was to cover the important
> interactions, not to write a fully precise specification.  The general rule
> about overrides having to be at least as accessible as the minimum of their
> class and their overridden method still applies, superseded only by the
> rule that it is acceptable to drop the "open" on a public open override.
>
> combined with the rule that overrides of an open method are by default
> open.
>
>
> This would degrade the developer experience significantly, since a
> beginning developer writing only internal subclasses for their own app
> would now be required to litter either `public override` or `final
> override` throughout their code in the ordinary course of subclassing. On
> reconsideration, it might be best if overrides are not implicitly open.
>
>
> I continue to think "override" is sufficient communication here.  We're
> not going to have a model where the inherited open API of the superclass
> becomes non-open in the subclass.  We don't want the mere existence of an
> override in the subclass to change that because it's a fairly core goal
> that the existence of an override (at least one which doesn't covariantly
> refine the type) in a subclass should not affect source/binary
> compatibility.
>
> John.
>
>
>
>
>> John.
>>
>>
>>
>> On Sat, Jul 16, 2016 at 1:35 PM, John McCall  wrote:
>>
>>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> Sent from my iPhone
>>>
>>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Yes, sorry, my point was that this consideration isn't spelled out.
>>>
>>> Another question is whether or not making a subclass of an open class
>>> public by default is what we want. I see why it would be, I just think that
>>> it is a wrinkle to default to internal otherwise but not here.
>>>
>>>
>>> I can't think of any good reason to assume a specific class should be
>>> public just because it is a subclass of an open class.  The internal
>>> default would still be the right default in this case.
>>>
>>>
>>> Right, there's no new restriction here.  Of course you can make a
>>> private or internal subclass of a public open class — otherwise, you'd have
>>> to publicize every subclass of (say) UIViewController.
>>>
>>> John.
>>>
>>>
>>>
>>> On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:
>>>

 > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
 swift-evolution@swift.org> wrote:
 >
 > What happens if I want an `internal` subclass of an `open` class?

 That should be allowable. You may want some optimised implementations,
 similar to how Apple used class-clusters in Obj-C. I don’t think that same
 pattern is exactly possible in Swift (I don’t think a class can set ‘self’
 in its initialiser, or at least it couldn’t in Swift 1). But the same
 principle applies - you may want a public class which you don’t allow
 others to 

Re: [swift-evolution] adding Obj-C syntax to Swift?

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution 
>  wrote:
> 
> My reply didn’t go to the list… my apologies…
> 
> On Jul 11, 2016, at 8:19 PM, Ford Prefect 
> > wrote:
> 
> People say nearly every WWDC code example was Swift. That says to newcomers 
> "learn Swift, not Obj C".
> Swift is being ported on other platforms but Objective C is not.
> Google has talked about switching to it, which may be unrelated but likely 
> not since the Valley is a small place.
> 
> More people using Swift is great. But C is still used. C++ is used. Why does 
> Obj-C need to go away for Swift to gain a larger dev base?
> 
> If Google starts to use Swift, do you see Java going away?

As of 2 years ago the google source code repo had more than 10Mloc of java. It 
might take a while to replace. Assuming they would adopt swift for android, i 
give it no more than 2 years for them to come with a fork having all the 
type-system enhancements apple does not want to add, in the spirit of how they 
did to the webkit code some of the refectoring the apple team did not want to 
do (i remember when they did the reorg many wanted or introduced the out of 
proc loading model first)

> 
> Obj-C has been here for awhile. Certainly before iOS and even before OS X. I 
> don’t see it going away any time soon, even in those eco-systems.
> 
> Best,
> 
> Josh
> 
> 
> Sent: Monday, July 11, 2016 at 8:03 PM
> From: "Josh Parmenter" 
> >
> To: "Ford Prefect" >
> Subject: Re: [swift-evolution] adding Obj-C syntax to Swift?
> Where is this wall with writing you speak of?
> My feeling is, if you want Obj-C syntax, why not use Obj-C? I actually don't 
> get the feeling that access to it as a development language is really going 
> away.
> Best
> Josh
> 
> Sent from my iPhone
> 
> On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution 
> >
>  wrote:
> 
> Perhaps one of the most disliked aspects of Swift
> is the Rust-like syntax, which requires that each coder resign himself to
> grin-and-bear-it in order to obtain the benefits of Swift.
> Since "the writing is on the wall" that Objective C
> is in its last days at least as far as app writers go
> (maybe within Apple it will endure), is there any
> chance of sweetening the pill a bit by giving us
> back the more readable syntax of Objective C, in particular
> the method call syntax? It just made more sense to
> format a method call like Smalltalk.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[Adrian Zubarev via swift-evolution]

Wrong thread ;) If you think it’s ill-prepared than provide some feedback 
instead of just watching and waiting to throw negative feedback during review 
process.

There is a lot done, but it’s not visible to the public thread yet. Will be 
soon (by tomorrow I’d guess).

Thanks.



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalko...@gmail.com) 
schrieb:

To me this is reminicent of what is happening with the T.Type / Type story, 
where there seems to be a rush to throw a proposal under the cut-off date even 
if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution 
 wrote:

I tried to tackle the ability to write extensions where everyone would be 
forced to write access modifier on member level. That’s what I had in my mind 
all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, 
because you could extend your type with an internal protocol, or the extended 
type might be not public.

Anyways, I’m withdrawing this proposal. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers 
altogether, instead always specifying access at the member level. I would be 
interested in a proposal to improve the current model — perhaps, for example, 
making “public extension” apply only to a protocol conformance, and disabling 
access modifiers on extensions that don’t have a protocol conformance.
___
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] [Update + Commentary] SE-0111: Remove type system significance of function argument labels

[Thorsten Seitz via swift-evolution]

> Am 14.07.2016 um 16:46 schrieb Vladimir.S via swift-evolution 
> :
> 
> Just +100. One more wise decision from the core team. Thank you for all of 
> your work.

Indeed! Thank you!

-Thorsten 


> 
>> On 14.07.2016 7:47, Chris Lattner via swift-evolution wrote:
>> Proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>> 
>> Shortly after SE-0111 was accepted last week, several people newly noticed
>> the proposal and started a discussion about how it appears to be a
>> regression for closure parameters (e.g. callbacks) that could formerly
>> carry labels, but are now not allowed to.  These folks observed that it
>> would be more expressive (and consistent with the rest of Swift) to allow
>> parameter labels in function types, because the invocation site of a
>> closure “should" be required to provide those labels.  The core team has
>> been following the discussion, agrees that this is a concern, and wants to
>> update the community with a path forward.
>> 
>> The reality of the situation is that the current implementation of
>> parameter labels in function types is inherently broken.  Specifically, as
>> one example, there is an implicit conversion from "(a: Int) -> Int” to
>> “(Int) -> Int”.  However, there is also an implicit conversion from "(Int)
>> -> Int” to “(b : Int) -> Int”.  This means that the compiler currently
>> allows converting from “(a: Int) -> Int” to “(b: Int) -> Int”, which
>> doesn’t make sense, introduces surprising behavior, introduces complexity
>> into the compiler implementation, and is generally a problem.  We do have
>> one specific hack to prevent conversion of (e.g.) “(a : Int, b : Int) ->
>> Void” to “(b : Int, a : Int) -> Void”, but this only triggers in specific
>> cases.  There are other more complex cases as well, e.g. when using
>> generics "T<(a : Int)->Int>” cannot be considered compatible with "T<(b :
>> Int)->Int>”.
>> 
>> These problems are what initially motivated SE-0111.  However, given the
>> feedback, the core team went back to the drawing board to determine
>> whether: a) SE-0111 by itself is the right long term answer, b) whether
>> there were alternate models that could solve the same problems in a
>> different way, or c) whether SE-0111 was the right first step to "ultimate
>> glory" in the field of closure parameter labels.  After a long discussion,
>> and many alternatives considered, the core team believes in c), that
>> SE-0111 (with a minor modification) is the right step for Swift 3, because
>> it paves the way for the right model over the long term.
>> 
>> 8<
>> 
>> The specific revision requested by the core team to SE-0111 is that all
>> “cosmetic” labels should be required to include an API name of _.  For
>> example, this would not be allowed:
>> 
>>   var op : (lhs : Int, rhs : Int) -> Int
>> 
>> instead, it should be spelled as:
>> 
>>   var op : (_ lhs : Int, _ rhs : Int) -> Int
>> 
>> With this change, we believe that we have paved the way for a purely
>> additive proposal (and thus, post-Swift 3) that will restore the expressive
>> capability of closures with parameter labels.
>> 
>> 8<
>> 
>> Here is a sketch of how that would work, in two steps:
>> 
>> 
>> First, we extend declaration names for variables, properties, and
>> parameters to allow *parameter names* as part of their declaration name.
>> For example:
>> 
>>   var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>>   x = op(lhs: 1, rhs: 2)   // use of the variable or property.
>> 
>>   // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>>   func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>> x = op(lhs: 1, rhs: 2) // use of the parameter
>>   }
>>   foo(opToUse: +) // call of the function
>> 
>> This will restore the ability to express the idea of a closure parameter
>> that carries labels as part of its declaration, without requiring parameter
>> labels to be part of the type system (allowing, e.g. the operator + to be
>> passed into something that requires parameter labels).
>> 
>> 
>> Second, extend the rules for function types to allow parameter API labels
>> *if and only if* they are used as the type of a declaration that allows
>> parameter labels, and interpret them as a sugar form for providing those
>> labels on the underlying declaration.  This means that the example above
>> could be spelled as:
>> 
>>   var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>>   x = op(lhs: 1, rhs: 2)  // Same as above
>> 
>>   // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>>   func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>> x = op(lhs: 1, rhs: 2) // Same as above.
>>   }
>>   foo(opToUse: +)  // Same as above.
>> 
>> 
>> These two steps will provide the simple and expressive design approach that
>> we have now, without all of 

Re: [swift-evolution] Pitch: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Dmitri Gribenko via swift-evolution]

On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via
swift-evolution  wrote:
> ## Proposed solution
>
> Replace `isUniquelyReferenced` by
> `isUniquelyReferencedUnsafe` and remove the `NonObjectiveCBase`
> class from the standard library.

Thank you for this proposal!

For presentation and clarity, could you show the full family of
`isUniquely*` functions in the design section, including those
functions that you are not proposing to change?  This will make it
easier to see what choices users will get.  It would be also great to
include the API of similar ManagedBuffer and ManagedBufferPointer
APIs, if any exist.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Mike Sanderson via swift-evolution]

On Fri, Jul 15, 2016 at 2:26 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jul 14, 2016, at 10:58 PM, Charles Srstka 
> wrote:
>
> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> - Second is that clients of some other public API vended by a non-Apple
> framework (e.g. a SwiftPM package) may end up in a situation where the
> framework author didn’t consider subclass-ability, but the client desires
> it.  In this situation, the core team feels that a bigger problem happened:
> the vendor of the framework did not completely consider the use cases of
> the framework.  This might have happened due to the framework not using
> sufficient black box unit testing, a failure of the imagination of the
> designer in terms of use cases, or because they have a bug in their
> framework that needs unanticipated subclass-ability in order to “get a job
> done”.
>
>
> Or because the framework was developed in the real world, rather than
> Elysium, and real-world framework developers just about *never* anticipate
> every single way someone might use their framework (Indeed, if developers
> were capable of such a thing, there would be no need for third-party
> software in the first place).
>
>
> I’m not sure what you’re trying to say.  I agree that it is clearly the
> case that a framework author cannot anticipate every single use case of
> their framework.
>
> However, it is just as clearly the case that “unanticipated
> subclassability” isn’t a general solution to that problem.
>

In the case of open-source frameworks, there is a better solution, simply
to fork. Fork, make the alteration, point the dependency manager to the
fork, and if you think it's of general applicability, submit a pull request.

And this does happen all the time. Not just unanticipated use cases, but
general bugs, bugs from a particular way it's used, some tweaks to adjust
some variable, need something fixed to be altered, designers ask for
something to be moved 10 pixels to the left, etc., including things
subclassing wouldn't even be able to fix. I've had to do this more than a
few times, and it actually never occurred to me to make a subclass for this
reason. A proposal that closed off the only way or the best way to handle
these cases would be unwelcome, but this doesn't do that.

It's another topic, but I think having a fork of open-source dependencies
anyway is prudent, as our friends in javascript learned with their recent
Node Package Manager left-pad fiasco. The left-pad fiasco also indicated
that relying on framework authors to be communicative or to be maintaining
their work or even to be not deliberately spiteful, is not good practice.
Fortunately in the case of open-source we do have that control; in the case
of Apple frameworks the assurances offered as part of sending it for
revision are welcome; and if this puts onus on publishers of third-party
close-source frameworks, ok.

-MikeSand



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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Karl via swift-evolution]

> On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> What happens if I want an `internal` subclass of an `open` class? 

That should be allowable. You may want some optimised implementations, similar 
to how Apple used class-clusters in Obj-C. I don’t think that same pattern is 
exactly possible in Swift (I don’t think a class can set ‘self’ in its 
initialiser, or at least it couldn’t in Swift 1). But the same principle 
applies - you may want a public class which you don’t allow others to subclass, 
but you might have a static method or other function which returns an internal 
optimised implementation.

If you used a protocol rather than a concrete type in that case, theoretically 
others could conform to it and throw their own objects back at your code, which 
goes against the point of this proposal.

We might think about creating ‘sealed’ protocols, too.

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

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas via swift-evolution]

> Le 16 juil. 2016 à 18:05, Jose Cheyo Jimenez via swift-evolution 
>  a écrit :
> 
>>  * What is your evaluation of the proposal?
> 
> +1 as before but I do have concerns
> 
>   * Why do open classes need to have also have open superclasses? 
>   * I don’t think sealed methods/properties as default is the right 
> default. 
>   * If the default was open for methods/properties, then do we really 
> need the sealed keyword? Could’t we just use final for that?
> 
>>  * 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?
> 
> Requiring super classes to also be Open seems wrong. 

> 
> I agree with Kevin Ballard on being open by default for methods/ properties 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ 
> 
> 
> If we are open by default for methods/properties then we could simplify 
> things by just using final for methods that need to be sealed; I don’t see 
> the need to have sealed methods/properties outside of the module ONLY. 
> 
> We already have to mark all public methods/properties as public, if I need 
> something not the be overridable then I can just use final. This would work 
> the same across all classes. 
> 
> If I was a framework author that initially just had a library that was sealed 
> but then somebody asked me to make it open; All I would want to do is add 
> open to the class only, I would not want to spend the time to go back an add 
> open to all public methods/properties specially if I am already using final. 
> I think having method/properties open by default is the best compromised. I 
> can see framework authors switching a class to be open and expecting that 
> everything in the class in open and if they don’t open any methods, then what 
> possible use is a subclass than an extension could not provide?

Extensions do not support stored properties (yet?). Subclasses do. That said, I 
agree that having an open class without any open member does not has much 
benefit, but I’m sure we can find a valid use case for such class.

> I think that is an overreach to make the framework author have to add open to 
> every public method in addition to having to open every super class. As a 
> framework author if I think my clients could use subclassing, all I want to 
> do is flip a switch on the classes that I want to make subclass able  and 
> then just push a new version. As a framework user I want to be able to tell 
> my framework author “can you just add open to classes abs and deca etc.” I 
> think it is more likely that I will get my request if it is easy vs it the 
> framework author needs to touch every class in the hierarchy. 
> 
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> n/a
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> reviewed previously and followed the update. 
> 
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu via swift-evolution]

On Sat, Jul 16, 2016 at 1:48 PM, Xiaodi Wu  wrote:

> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan  wrote:
>>
>> "open is invalid on declarations that are not also public (see the
>> Alternatives discussion for rationale)."
>> +
>>
>> "If an open class inherits an open method from a superclass, that method
>> remains open. If it overrides an open method from a superclass, the
>> override is implicitly open if it is not final."
>>
>> I understand that the intent is probably not to say that subclasses are
>> public by default. My point is that those two statements, without an
>> explicit spelling out of the implicit access level, could lead me to
>> believe that subclasses are implicitly public by default. It is open to
>> interpretation. Neither the prose nor the code examples address it.
>>
>>
>> I see your general point.  I'll think about how to re-word this; it may
>> be sufficient to just remove the requirement that open methods appear in
>> open classes.  Suffice it for me to say now, officially, that this proposal
>> does not require classes to be public or open just because they override
>> open methods from an open superclass.
>>
>
> It might be barely sufficient solely to remove the requirement that open
> methods appear in open classes. However, if my subclass is internal, I
> shouldn't be required to declare a `public override` of an open method just
> to satisfy the rules for `open`, which would be forced by the rule that
> `open` is invalid on declarations that are not also `public` combined with
> the rule that overrides of an open method are by default open.
>
> This would degrade the developer experience significantly, since a
> beginning developer writing only internal subclasses for their own app
> would now be required to litter either `public override` or `final
> override` throughout their code in the ordinary course of subclassing. On
> reconsideration, it might be best if overrides are not implicitly open.
>

I should add: independent of the issue above for internal subclasses in
apps that don't vend an API having "public" overrides, it seems to me most
consistent with the general aim of the proposal that open overrides should
be marked as such by the subclass's owner. The same logic that requires
explicit use of `open` for subclass declarations should require them for
overridden methods. (Whereas, clearly, inherited methods that don't show up
at all in the code inside the subclass are a different ballgame.)


>
>
>> John.
>>
>>
>>
>> On Sat, Jul 16, 2016 at 1:35 PM, John McCall  wrote:
>>
>>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> Sent from my iPhone
>>>
>>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Yes, sorry, my point was that this consideration isn't spelled out.
>>>
>>> Another question is whether or not making a subclass of an open class
>>> public by default is what we want. I see why it would be, I just think that
>>> it is a wrinkle to default to internal otherwise but not here.
>>>
>>>
>>> I can't think of any good reason to assume a specific class should be
>>> public just because it is a subclass of an open class.  The internal
>>> default would still be the right default in this case.
>>>
>>>
>>> Right, there's no new restriction here.  Of course you can make a
>>> private or internal subclass of a public open class — otherwise, you'd have
>>> to publicize every subclass of (say) UIViewController.
>>>
>>> John.
>>>
>>>
>>>
>>> On Sat, Jul 16, 2016 at 10:32 AM, Karl  wrote:
>>>

 > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
 swift-evolution@swift.org> wrote:
 >
 > What happens if I want an `internal` subclass of an `open` class?

 That should be allowable. You may want some optimised implementations,
 similar to how Apple used class-clusters in Obj-C. I don’t think that same
 pattern is exactly possible in Swift (I don’t think a class can set ‘self’
 in its initialiser, or at least it couldn’t in Swift 1). But the same
 principle applies - you may want a public class which you don’t allow
 others to subclass, but you might have a static method or other function
 which returns an internal optimised implementation.

 If you used a protocol rather than a concrete type in that case,
 theoretically others could conform to it and throw their own objects back
 at your code, which goes against the point of this proposal.

 We might think about creating ‘sealed’ protocols, too.

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

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[L. Mihalkovic via swift-evolution]

To me this is reminicent of what is happening with the T.Type / Type story, 
where there seems to be a rush to throw a proposal under the cut-off date even 
if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I tried to tackle the ability to write extensions where everyone would be 
> forced to write access modifier on member level. That’s what I had in my mind 
> all the time. But the respond on this was, as you can see purely negative. :D
> 
> Making all extensions public when there is protocol conformance makes no 
> sense, because you could extend your type with an internal protocol, or the 
> extended type might be not public.
> 
> Anyways, I’m withdrawing this proposal. :)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:
> 
>> Because of all this, I have stopped using extension-level access modifiers 
>> altogether, instead always specifying access at the member level. I would be 
>> interested in a proposal to improve the current model — perhaps, for 
>> example, making “public extension” apply only to a protocol conformance, and 
>> disabling access modifiers on extensions that don’t have a protocol 
>> conformance.
> 
> ___
> 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: Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by `isUniquelyReferencedUnsafe`

[Arnold Schwaighofer via swift-evolution]

https://bugs.swift.org/browse/SR-1962

# Remove `NonObjectiveCBase` and replace `isUniquelyReferenced` by 
`isUniquelyReferencedUnsafe`

## Introduction

Remove `NonObjectiveCBase` and replace`isUniquelyReferenced(_ object: T)` by `isUniquelyReferencedUnsafe(_ 
object: T)`. This will remove surface API. Instead of a type check dynamically 
check the non-`@objc` constraint under `-Onone`.

## Motivation

Today we have `isUniquelyReferenced` which only works on subclasses of
NonObjectiveCBase, and we have `isUniquelyReferencedNonObjC` which also works on
`@objc` classes.

```swift
class SwiftKlazz : NonObjectiveCBase {}
class ObjcKlazz : NSObject {}

expectTrue(isUniquelyReferenced(SwiftKlazz()))
expectFalse(isUniquelyReferencedNonObjC(ObjcKlazz()))

// Would not compile:
expectFalse(isUniquelyReferenced(ObjcKlazz()))
```

In most cases we expect developers to be using the ManagedBufferPointer type. In
cases where they want to use a custom class they would use
`isUniquelyReferenced` today and can use `isUniquelyReferencedUnsafe` in the
future.

```swift
class SwiftKlazz : NonObjectiveCBase {}
class ObjcKlazz : NSObject {}

expectTrue(isUniquelyReferencedUnsafe(SwiftKlazz()))
// Would trap under -Onone:
expectFalse(isUniquelyReferencedUnsafe(ObjcKlazz()))
```

Replacing `isUniquelyReferenced` by
`isUniquelyReferencedUnsafe` will allow us to remove the
`NonObjectiveCBase` class from the standard library thereby shrink API surface.
We argue that trading type safety for less API surface is a good trade-off to
make with this low-level API.


## Proposed solution

Replace `isUniquelyReferenced` by
`isUniquelyReferencedUnsafe` and remove the `NonObjectiveCBase`
class from the standard library.

## Detailed design

Remove the `NonObjectiveCBase` class and change
`isUniquelyReferenced(_ object: T>` to:

```swift
/// Returns `true` iff `object` is a non-`@objc` class instance with a single
/// strong reference. `object` is assumed to be a non-`@objc` class instance.
/// In debug mode this function will check this assumption. Otherwise, it is
/// undefined what happens.
///
/// * Does *not* modify `object`; the use of `inout` is an
///   implementation artifact.
/// * Weak references do not affect the result of this function.
///
/// Useful for implementing the copy-on-write optimization for the
/// deep storage of value types:
///
/// mutating func modifyMe(_ arg: X) {
///   if isUniquelyReferencedUnsafe() {
/// myStorage.modifyInPlace(arg)
///   }
///   else {
/// myStorage = myStorage.createModified(arg)
///   }
/// }
///
/// This function is safe to use for `mutating` functions in
/// multithreaded code because a false positive would imply that there
/// is already a user-level data race on the value being mutated.
public func isUniquelyReferencedUnsafe(
  _ object: inout T
) -> Bool {
  _debugPrecondition(
_usesNativeSwiftReferenceCounting(object.dynamicType),
"instance must be a non-@objc class instance")
  return _isUnique()
}
```

Note, that today at -O we would actually not cause undefined behavior but
rather just return false. We don't want to guarantee this in the future so the
comment specifies undefined behavior.

## Impact on existing code

Existing code that uses `isUniquelyReferenced` will need to remove the
`NonObjectiveCBase` base class and replace calls to `isUniquelyReferenced` by
`isUniquelyReferencedUnsafe`. The old API will be marked unavailable to help 
migration.

## Alternatives considered

Leave the status quo and pay for type safety with additional API surface.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution