Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha via swift-evolution]

Ah, I understand now; that’s a good point.

On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe 
wrote:

> To use the parameters, the function would have to check for nil anyways,
> right (or risk a crash at runtime)? If the parameter is changed from an IUO
> to an Optional, the check for nil simply becomes a shadowing with guard.
>
>
> And what if the overridden method returns "T!"? It would become T? in the
> code, while the original API expects a non-nil value. This IMHO adds
> confusion to the language. As I've mentioned previously, these are examples
> that you'd get:
>
> func addObject(object: AnyObject?)
> func objectAtIndex(index: Int) -> AnyObject?
>
> This is from NSArray, but if you had a similar un-audited API, then
> created your subclass of this, you'd get something semantically completely
> different and users of your API would assume you can pass nil to addObject
> and that objectAtIndex can return nil.
>
> In case of addObject, would you just silently ignore the nil, or would you
> crash as NSArray would?
>
> Yes, it's unexpected sometimes to find nil coming from these methods, or
> getting them as arguments, but it's just as unexpected as finding out that
> your app is crashing because it's accessing index out of bounds.
>
>
> Saagar Jha
>
>
>
> On Jul 20, 2016, at 21:10, Chris Lattner  wrote:
>
>
> On Jul 20, 2016, at 5:24 PM, Saagar Jha  wrote:
>
> Sorry for the last email…I didn’t see your response.
>
> I realize that disallowing IUOs in parameters (but not as properties) is
> inconsistent, but IUOs for properties make sense: they must be set during
> initialization, but sometimes this isn’t possible. IUOs make it possible to
> use the property just as any other non-Optional one, *provided the
> property is set before it is used* (see the proposal). This kind of
> guarantee doesn’t work for function parameters and return values.
>
> As for IUOs for non-audited methods; why can’t they just all use Optional
> parameters? It should have the same behavior as before, since you can pass
> in both an Optional as well as a non-Optional even today.
>
>
> Because an override of an unaudited method has to *use* the parameters.
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Dmitri Gribenko via swift-evolution]

On Thu, Jul 21, 2016 at 10:17 PM, Xiaodi Wu  wrote:
> Robert, the gist is notably vague on this point, so I'm hoping you will
> clarify. Are you proposing that FloatingPoint will break with IEEE754
> semantics? What will be the result of `Float.nan == Float.nan`?
>
> (My guess at the sanest outcome is that areSame/Equivalent() and <=> will be
> totally ordered but FloatingPoint types will override == and the standard
> comparison operators to maintain IEEE754 semantics, yes?)

Right, == (and !=, <, >, <=, >=) can be customized with
domain-specific semantics, and floating point does this.  In addition,
floating point protocols will list == as a requirement, so generic
code generic over floating point types will get IEEE 754 semantics
when using == syntax, but code that only has an Equatable requirement
will use the total ordering semantics.

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] [Draft][Proposal] Formalized Ordering

[Xiaodi Wu via swift-evolution]

Robert, the gist is notably vague on this point, so I'm hoping you will
clarify. Are you proposing that FloatingPoint will break with IEEE754
semantics? What will be the result of `Float.nan == Float.nan`?

(My guess at the sanest outcome is that areSame/Equivalent() and <=> will
be totally ordered but FloatingPoint types will override == and the
standard comparison operators to maintain IEEE754 semantics, yes?)


On Thu, Jul 21, 2016 at 11:02 PM Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi,
>
> On Thu, Jul 21, 2016 at 6:11 PM, Robert Widmann via swift-evolution
>  wrote:
> > Hello Swift Community,
> >
> > Harlan Haskins, Jaden Geller, and I have been working on a proposal to
> clean
> > up the semantics of ordering relations in the standard library.
>
> Great work!
>
> As a part of your implementation, are you planning to add <=>
> overloads for tuples, like we do now for comparison operators?  (See
> stdlib/public/core/Tuple.swift.gyb.)
>
> 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] [Meta] Updating the proposal template to prompt backward compatibility concerns

[Brent Royal-Gordon via swift-evolution]

> On Jul 21, 2016, at 9:05 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> With the end of Swift 3 drawing near, we'll need to start designing with an 
> eye toward backward compatibility. To that end, I think we should update the 
> "Impact on existing code" proposal template to start asking writers to 
> consider backward compatibility concerns. Here's some draft verbage to that 
> effect:
> 
> https://github.com/jckarter/swift-evolution/blob/4bdd1b875a8402ec6bbabb3f37151262f130af2b/-template.md#backward-compatibility
> 
> Any concerns, revisions, or objections?

The section title should be sentence-case. Other than that, I think it's a good 
move.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Jose Cheyo Jimenez via swift-evolution]

> On Jul 21, 2016, at 7:15 PM, Duan via swift-evolution 
>  wrote:
> 
> Great proposal. I want to second that areSame may mislead user to think this 
> is about identity.
> 
> I like areEquivalent() but there may be better names.

what about areEqual() ?

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu  wrote:
>>> 
>>> This is nice. Is `areSame()` being proposed because static `==` is the 
>>> status quo and you're trying to make the point that `==` in the future need 
>>> not guarantee the same semantics?
>> 
>> Yep!  Equivalence and equality are strictly very different things.
>> 
>>> 
>>> Nit: I think the more common term in stdlib would be `areEquivalent()`. Do 
>>> you think `same` in that context (independent of the word "ordering") might 
>>> erroneously suggest identity?
>> 
>> There is room for improvement here.  Keep ‘em coming.
>> 
>>> 
>>> 
 On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution 
  wrote:
 Hello Swift Community,
 
 Harlan Haskins, Jaden Geller, and I have been working on a proposal to 
 clean up the semantics of ordering relations in the standard library.  We 
 have a draft that you can get as a gist.  Any feedback you might have 
 about this proposal helps - though please keeps your comments on 
 Swift-Evolution and not on the gist.
 
 Cheers,
 
 ~Robert Widmann
 
 
 
 
 
 ___
 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] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Karl via swift-evolution]

> On 21 Jul 2016, at 22:13, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Thu Jul 21 2016, Matthew Johnson  > wrote:
> 
>>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Thu Jul 21 2016, Matthew Johnson  wrote:
>>> 
>> 
>   * What is your evaluation of the proposal?
 
 +1 to the first design.  I think this is a great solution that
 balances the many considerations that have been raised on all sides of
 this issue.  `open` is 2 characters shorter than `public` so
 complaints about boilerplate are no longer valid.  `internal` is the
 “default” - neither `public` nor `open` are privileged as a “default”
 for publishing API outside of a module.
 
 I am interested in language enhancements such as exhaustive pattern
 matching on classes and protocols which rely on knowledge of the full
 class hierarchy.  Such enhancements will be far more useful if the
 language supports non-open, non-final classes.
 
 There are design techniques that would require additional boilerplate
 if we cannot have non-open, non-final classes.
 
 Most importantly, requiring library authors to choose `public` or
 `open` provides important documentation value.  Users of the library
 will know whether the author intends to support subclasses or not.
>>> 
>>> I think this reasoning is flawed.
>>> 
>>> If you make any methods overridable outside your module (“open”),
>>> obviously you mean to allow subclassing outside the module.  If you have
>>> no open methods, there's absolutely nothing you need to do to “support
>>> subclasses,” and from a design point-of-view, there's no reason to
>>> restrict people from subclassing.
>> 
>> I disagree.  As has been discussed when a class is not open the author
>> does not make a commitment to allow subclasses.  
> 
> Yes, but that argument is based on the *assumption* that disallowing
> subclassing is somehow an important dimension of safety or preserving
> API contracts, independent of overriding.  It isn't.
> 
> Demonstration: we don't make that argument about aggregation: you can't
> prevent someone from making your public struct a stored property in a
> type defined outside the module.  Judgements about programming style
> aside, in the absence of overriding, subclassing and aggregation are
> identical from an encapsulation point-of-view.
> 

IMO, the safety of API contracts is secondary. This is about safety of 
implementation - my code is possibly not "resilient" enough (to to speak) to 
handle overriding arbitrary public members. Not all members are equally 
resilient to being overridden (an implementation detail). It is not driven by 
ideological considerations as much as practical considerations - writing good 
base classes is difficult, and lots of people get it wrong, and we could 
improve reason-ability for all parties involved if we just marked-up what is 
“open” and what isn’t.

That’s also why I think it should apply to internal subclasses as well. I’m not 
supporting this proposal for ideological reasons, but for practical ones. And 
in that sense, I’m -1 (or maybe -0.5) because I don’t think it goes far enough 
and leaves a feeling of inconsistency as a result.

Aggregation is not a problem because the aggregate type does not have an “is” 
relationship with its constituents.

>> The right to make the class final is reserved for the future.  Maybe
>> this is the “nice point of control” you refer to and don’t find
>> compelling?  I would prefer to have library authors acknowledge that
>> they intend to allow subclasses and make that commitment explicit.
> 
> The question is, why?
> 
>> For me it isn’t about control as much as it is about making the API
>> contract explicit and acknowledged.  I have wondered about the intent
>> of library authors enough times to find this explicit statement in the
>> language worthwhile.
> 
> Yeah, but we don't add language features to represent every possible
> author intention, and there's a good argument that any intention that
> can be violated without harm shouldn't be enforced.

It’s the “without harm” that’s debatable. It may not cause harm in a binary 
sense, but it may cause harm in another sense if you pass rogue objects around 
which look like my own objects but can define non-conforming behaviour. The 
only way I can prevent that right now is with “final”, but that prevents even 
myself from subclassing internally.

If we went with the first option (and assuming the library-internal 
optimisation potential in this situation is minor), we could have a flag which 
lets you override the checker and subclass non-open, non-final types in 3rd 
party libraries. We could continue to ensure that it is safe (from a binary 
perspective) to subclass and let you import libraries 

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Xiaodi Wu via swift-evolution]

On Thu, Jul 21, 2016 at 8:32 PM, Robert Widmann  wrote:

>
> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu  wrote:
>
> This is nice. Is `areSame()` being proposed because static `==` is the
> status quo and you're trying to make the point that `==` in the future need
> not guarantee the same semantics?
>
>
> Yep!  Equivalence and equality are strictly very different things.
>
>
> Nit: I think the more common term in stdlib would be `areEquivalent()`. Do
> you think `same` in that context (independent of the word "ordering") might
> erroneously suggest identity?
>
>
> There is room for improvement here.  Keep ‘em coming.
>

Well, since you asked...
Wikipedia reminds me that a ~ b is an appropriate mathematical notation for
equivalence of a and b. We probably wouldn't want to confuse things with
bitwise not, but in the grand tradition of reduplicating to form operators
from their mathematical counterparts, what about infix operator `~~`? [In a
few minutes, I might find this to be a terrible idea.]

On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift Community,
>>
>> Harlan Haskins, Jaden Geller, and I have been working on a proposal to
>> clean up the semantics of ordering relations in the standard library.  We
>> have a draft that you can get as a gist.
>>   Any
>> feedback you might have about this proposal helps - though please keeps
>> your comments on Swift-Evolution and not on the gist.
>>
>> Cheers,
>>
>> ~Robert Widmann
>>
>>
>>
>>
>>
>> ___
>> 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-0128: Change failable UnicodeScalar initializers to failable

[Karl via swift-evolution]

+1. I was trying to build a naive random string generator the other day (but I 
wanted it to occasionally spit out extended clusters like emojis), and was also 
surprised that the initialiser crashes.
 
Could probably be filed under “bug fixes”, even.

Karl

> On 22 Jul 2016, at 00:28, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0128: Change failable UnicodeScalar initializers to 
> failable" begins now and runs through July 24. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.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?
>   * 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] [Draft][Proposal] Formalized Ordering

[Duan via swift-evolution]

Great proposal. I want to second that areSame may mislead user to think this is 
about identity.

I like areEquivalent() but there may be better names.

Daniel Duan
Sent from my iPhone

> On Jul 21, 2016, at 6:32 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> 
>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu  wrote:
>> 
>> This is nice. Is `areSame()` being proposed because static `==` is the 
>> status quo and you're trying to make the point that `==` in the future need 
>> not guarantee the same semantics?
> 
> Yep!  Equivalence and equality are strictly very different things.
> 
>> 
>> Nit: I think the more common term in stdlib would be `areEquivalent()`. Do 
>> you think `same` in that context (independent of the word "ordering") might 
>> erroneously suggest identity?
> 
> There is room for improvement here.  Keep ‘em coming.
> 
>> 
>> 
>>> On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> Hello Swift Community,
>>> 
>>> Harlan Haskins, Jaden Geller, and I have been working on a proposal to 
>>> clean up the semantics of ordering relations in the standard library.  We 
>>> have a draft that you can get as a gist.  Any feedback you might have about 
>>> this proposal helps - though please keeps your comments on Swift-Evolution 
>>> and not on the gist.
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] [Pitch] Unify joined(separator:) and flatten()

[Jacob Bandes-Storch via swift-evolution]

In the swift-lang Slack channel, a few of us were discussing
joined(separator:) and realized that flatten() does almost exactly the same
thing.

Is there interest in renaming flatten() to joined()?  Since joined takes a
separator that's any Sequence, we can't have a default value for the
separator parameter, but we can have a variant of joined() with no
arguments.

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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Robert Widmann via swift-evolution]

> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu  wrote:
> 
> This is nice. Is `areSame()` being proposed because static `==` is the status 
> quo and you're trying to make the point that `==` in the future need not 
> guarantee the same semantics?

Yep!  Equivalence and equality are strictly very different things.

> 
> Nit: I think the more common term in stdlib would be `areEquivalent()`. Do 
> you think `same` in that context (independent of the word "ordering") might 
> erroneously suggest identity?

There is room for improvement here.  Keep ‘em coming.

> 
> 
> On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution 
> > wrote:
> Hello Swift Community,
> 
> Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean 
> up the semantics of ordering relations in the standard library.  We have a 
> draft that you can get as a gist. 
>   Any 
> feedback you might have about this proposal helps - though please keeps your 
> comments on Swift-Evolution and not on the gist.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> 
> 
> 
> 
> ___
> 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] Returning nothing

[Daniel Steinberg via swift-evolution]

Thanks for the clarification 

I misunderstood your comment.

> On Jul 21, 2016, at 6:29 PM, Chris Lattner  wrote:
> 
> On Jul 21, 2016, at 3:02 PM, Daniel Steinberg via swift-evolution 
>  wrote:
>> Chris’ note addressed my misconception that a goal of Swift was that it 
>> could be a good first or learning language.
> 
> Please clarify this.  I said that Swift was not designed to mock English 
> grammar.  It is absolutely intended to be a good teaching language, and I 
> never said otherwise.
> 
> -Chris
> 

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

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

[Xiaodi Wu via swift-evolution]

This is nice. Is `areSame()` being proposed because static `==` is the
status quo and you're trying to make the point that `==` in the future need
not guarantee the same semantics?

Nit: I think the more common term in stdlib would be `areEquivalent()`. Do
you think `same` in that context (independent of the word "ordering") might
erroneously suggest identity?


On Thu, Jul 21, 2016 at 8:11 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift Community,
>
> Harlan Haskins, Jaden Geller, and I have been working on a proposal to
> clean up the semantics of ordering relations in the standard library.  We
> have a draft that you can get as a gist.
>   Any
> feedback you might have about this proposal helps - though please keeps
> your comments on Swift-Evolution and not on the gist.
>
> Cheers,
>
> ~Robert Widmann
>
>
>
>
>
> ___
> 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][Proposal] Formalized Ordering

[Robert Widmann via swift-evolution]

Hello Swift Community,

Harlan Haskins, Jaden Geller, and I have been working on a proposal to clean up 
the semantics of ordering relations in the standard library.  We have a draft 
that you can get as a gist. 
  Any feedback 
you might have about this proposal helps - though please keeps your comments on 
Swift-Evolution and not on the gist.

Cheers,

~Robert Widmann




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

Re: [swift-evolution] [Pitch] Rename Mirror

[Anton Zhilin via swift-evolution]

Somehow I did not send a copy to evolution the first time:

I have to agree. Stopping the discussion on this until after Swift 3.

And response from Dmitri:

Thanks!

Just wanted to be clear -- I am not against reflection.  And I am
concerned whether the current design of Mirror will work for the
long-term full-featured reflection implementation, but only because we
don't know what will be the shape of reflection in Swift.  For
example, would we be able to call arbitrary public functions on a type
by name?  If yes, how would that be implemented -- both in the API,
and on the low level, how would actual function call and argument
passing work?  How much extra metadata and thunks would the compiler
need to emit?  Would an average app or framework want that bloat?
Remember that we don't have a JIT, so we can't say "we will do what
Java (or any other mainstream language with reflection) does", because
we can't.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Rename Mirror

[Dmitri Gribenko via swift-evolution]

On Thu, Jul 21, 2016 at 4:49 PM, Anton Zhilin  wrote:
> 2016-07-22 2:39 GMT+03:00 Dmitri Gribenko :
>>
>> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin 
>> wrote:
>> > Moreover, types can completely customize contents of their
>> > 'Mirror's. This is incompatible with laziness and with how reflection
>> > should
>> > work, based on experience from other languages.
>>
>> That is actually viewed as a weakness of reflection in other
>> languages.  Allowing reflection to access other types' internal data
>> and APIs creates barriers for optimization, and facilitates creating
>> binary compatibility problems when apps include code that uses
>> reflection to poke at internal data of library types.
>
>
> I talked about Swift here.

I am also talking about Swift.  If we build a reflection mechanism
that would allow third party code to poke at Array or Dictionary
implementation details (or any other type for that matter), we would
be exposing us to the same pitfalls as other languages have now.  I
would be opposed to doing that.

> Types can completely customize contents of their
> Mirrors in Swift.

This is desirable, for implementation hiding reasons.  Nobody should
be able to observe implementation details of Array, Dictionary, or any
other library types through programmatic mechanisms.

> A type, which pretends to be used for reflection, can't
> afford that.

Why not?

You see, we (as a community) don't have a shared long-term vision
about what "reflection" means.  Establishing that agreement would be
the prerequisite to starting any formal proposal process.
Speculatively making changes based on hypothetical designs that were
not discussed yet will not bring us to a better place.

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] [Pitch] Rename Mirror

[Anton Zhilin via swift-evolution]

2016-07-22 2:39 GMT+03:00 Dmitri Gribenko :

> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin 
> wrote:
> > Moreover, types can completely customize contents of their
> > 'Mirror's. This is incompatible with laziness and with how reflection
> should
> > work, based on experience from other languages.
>
> That is actually viewed as a weakness of reflection in other
> languages.  Allowing reflection to access other types' internal data
> and APIs creates barriers for optimization, and facilitates creating
> binary compatibility problems when apps include code that uses
> reflection to poke at internal data of library types.


I talked about Swift here. Types can completely customize contents of their
Mirrors in Swift. A type, which pretends to be used for reflection, can't
afford that.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Xiaodi Wu via swift-evolution]

On Thu, Jul 21, 2016 at 5:40 PM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

>
> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
> --
> Rename T.Type
>
>- Proposal: SE–0126
>
>- Authors: Adrian Zubarev , Anton
>Zhilin 
>- Status: *Revision*
>- Review manager: Chris Lattner 
>- Revision: 2
>- Previous Revisions: 1
>
> 
>
> Introduction
>
> This proposal renames the current metatype T.Type notation and the global
> function from *SE–0096* to match the changes.
>
> Swift-evolution threads:
>
>- [Pitch] Rename T.Type
>- [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
>- [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
>
> 
>- [Discussion] Seal T.Type into Type
>
> 
>
> Motivation
>

For improved reader comprehension, this section could use some more
information and reorganization. Specifically, the structure should (IMO) be
refactored to have:

1. A consolidated section--which can be on the brief side--on the current
art (i.e., how do things currently work?). Some information is already
present, but the prose is not possible to follow unless one is already an
expert in the area. Please start each paragraph with a topic sentence
leading into an explanation in English, not just code, of the current
behavior. Perhaps you could used (attributed) quotations from existing
Swift documentation if necessary.

2. Subsequent to (1), a concise explanation in English (in addition to
Swift code, if desired, but the key is to have it also in English)
outlining the defects present in the current art. I know, for instance,
that type(of:) as approved can't quite be expressed in Swift code due to
issues related to existential metatypes. Could you elaborate on these
issues in a way that would set up your proposed solution?


> In Swift metatypes have the following notation: *T.Type*
>
> As already showed in *SE–0096* and *SE–0090* the Swift community strongly
> is in favor of (re)moving magical intstance or type properties.
>
>-
>
>*SE–0096* moves instanceOfT.dynamicType to type(of: T) -> T.Type.
>-
>
>*SE–0090* aims to remove .self completely.
>
> We propose to rename T.Type to a generic-like notation Metatype. To be
> able to achieve this notation we have to resolve a few issues first.
> Known issues of metatypes:
>
> Assume this function that checks if an Int type conforms to a specific
> protocol. This check uses current model of metatypes combined in a generic
> context:
>
> func intConforms(to _: T.Type) -> Bool {
>return Int.self is T.Type
> }
>
> intConforms(to: CustomStringConvertible.self) //=> false
>
> Int.self is CustomStringConvertible.Type  //=> true
>
> [1] When T is a protocol P, T.Type is the metatype of the protocol type
> itself, P.Protocol. Int.self is not P.self.
>
> [2] There isn’t a way to generically expression P.Type *yet*.
>
> [3] The syntax would have to be changed in the compiler to get something
> that behaves like .Type today.
>
> Written by Joe Groff: [1]
>  [2]
>  [3]
> 
>
> A possible workaround might look like the example below, but does not
> allow to decompose P.Type:
>
> func intConforms(to _: T.Type) -> Bool {
>   return Int.self is T
> }
>
> intConforms(to: CustomStringConvertible.Type.self) //=> true
>
> We can extend this issue and find the second problem by checking against
> the metatype of Any:
>
> func intConforms(to _: T.Type) -> Bool {
> return Int.self is T
> }
>
> intConforms(to: Any.Type.self) //=> true
>
> intConforms(to: Any.self)  //=> true
>
> Int.self is Any.Type   //=> Always true
>
> When using Any the compiler does not require .Type at all and returns true
> for both variations.
>
> The third issue will show itself whenever we would try to check protocol
> relationship with another protocol. Currently there is no way (that we know
> of) to solve this problem:
>
> protocol P {}
> protocol R : P {}
>
> func rIsSubtype(of _: T.Type) -> Bool {
> return R.self is T
> }
>
> rIsSubtype(of: P.Type.self) //=> false
>
> R.self is Any.Type //=> Always true
> R.self is P.Type   //=> true
> R.self is R.Type   //=> true
>
> We also believe that this issue is the reason why the current global
> 

Re: [swift-evolution] [Pitch] Rename Mirror

[Austin Zheng via swift-evolution]

I agree with Dmitri. I would rather see a proper design for reflection
(similar to Completing Generics) before we start making any changes to the
existing machinery.

Best,
Austin

On Thu, Jul 21, 2016 at 4:39 PM, Dmitri Gribenko via swift-evolution <
swift-evolution@swift.org> wrote:

> On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin 
> wrote:
> > 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko :
> >>
> >> > Mirror.DisplayStyle contains optional and set as special cases, but
> does
> >> > not
> >> > contain function
> >> > Mirror collects all information possible at initialization, while for
> >> > true
> >> > reflection we want laziness
> >> > Mirror allows customization. For example, Array is represented
> with a
> >> > field for each of its elements. Do we want this for “true” reflection
> we
> >> > want to add in the future?
> >>
> >> Why can't we add these features to Mirror in future?
> >
> >
> > Reflection in some other languages works as follows: we have a type
> (let's
> > name it 'Reflection'). Each instance of it contains ID of one type and
> can,
> > for example, retrieve an array of its static or normal methods.
>
> I understand.  But we don't know how reflection will work in Swift, we
> haven't designed it yet.  You are assuming it will work like it does
> in other languages, which will not necessarily be the case.
>
> > Moreover, types can completely customize contents of their
> > 'Mirror's. This is incompatible with laziness and with how reflection
> should
> > work, based on experience from other languages.
>
> That is actually viewed as a weakness of reflection in other
> languages.  Allowing reflection to access other types' internal data
> and APIs creates barriers for optimization, and facilitates creating
> binary compatibility problems when apps include code that uses
> reflection to poke at internal data of library types.
>
> 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] [Pitch] Rename Mirror

[Dmitri Gribenko via swift-evolution]

On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin  wrote:
> 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko :
>>
>> > Mirror.DisplayStyle contains optional and set as special cases, but does
>> > not
>> > contain function
>> > Mirror collects all information possible at initialization, while for
>> > true
>> > reflection we want laziness
>> > Mirror allows customization. For example, Array is represented with a
>> > field for each of its elements. Do we want this for “true” reflection we
>> > want to add in the future?
>>
>> Why can't we add these features to Mirror in future?
>
>
> Reflection in some other languages works as follows: we have a type (let's
> name it 'Reflection'). Each instance of it contains ID of one type and can,
> for example, retrieve an array of its static or normal methods.

I understand.  But we don't know how reflection will work in Swift, we
haven't designed it yet.  You are assuming it will work like it does
in other languages, which will not necessarily be the case.

> Moreover, types can completely customize contents of their
> 'Mirror's. This is incompatible with laziness and with how reflection should
> work, based on experience from other languages.

That is actually viewed as a weakness of reflection in other
languages.  Allowing reflection to access other types' internal data
and APIs creates barriers for optimization, and facilitates creating
binary compatibility problems when apps include code that uses
reflection to poke at internal data of library types.

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] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Rod Brown via swift-evolution]

Proposal 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 to the second proposal, if we were to drop the concept of a final class. I 
feel like by blocking subclasses in preference to extensions, we would need to 
be 100% sure we could add stored properties in extensions, otherwise adding a 
stored property would require a subclass. I think that final fully on a class 
tends to be superfluous if we have final and/or open on methods. This would 
allow for composition with little penalty for optimisations.

If we have final classes as a whole, I recommend we go with option 1.

I personally prefer Option #2. I think that a lot of us are going “that’s not 
swifty” and using that as a justification. Lets be honest, we’re deliberately 
limiting ourselves here against composition via subclassing, without writing 
lots of frameworks and libraries where this would directly impact us and we’d 
learn our lessons. Why block composition via subclassing? Opinion, based on 
“this can all be done by extensions and that feels swifty”. Well it currently 
can’t be done via extensions. Perhaps we should be more open about this and 
allow users to choose their composition methodology… I feel like we’re blocking 
something unnecessarily.

Blocking all the members of a class can still be done, but we could 
theoretically allow composition on classes that are otherwise final or sealed. 
Why not?

I love the concept of clear subclassing with “Open” as an extension of the 
access level, showing public *and* subclassable. This is actually how I assumed 
this would work in the first place.

- 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. I think Option 2 however slightly changes that direction, and I think 
that’s a good thing.

- 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?
Continued interest in the discussion. Thorough read.


-Rod



> On 22 Jul 2016, at 1:33 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The third review of "SE-0117: Allow distinguishing between public access and 
> public overridability" begins now and runs through July 25. The proposal is 
> available here:
> 
>   
> 
> 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?
>   * 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] [Proposal] Replace String.init(repeating repeatedValue: Character, count: Int) and String.init(repeating repeatedValue: UnicodeScalar, count: Int) by String.init(repeating repeat

[王 黎明 via swift-evolution]

It's because there is no character literal!
something like 'c','\' in language C.



在 2016年7月22日，00:54，Roman Levenstein via swift-evolution 
> 写道：

Hi,

I’d like to propose some improvements for String initializers and String.append 
methods. It is addressing https://bugs.swift.org/browse/SR-1964 
(rdar://problem/17028332).


# Replace String.init(repeating repeatedValue: Character, count: Int) and 
String.init(repeating repeatedValue: UnicodeScalar, count: Int) by 
String.init(repeating repeatedValue: String, count: Int)

* Proposal:
* Author: [Roman Levenstein](http://github.com/swiftix)
* Status:
* Review manager:

Introduction
=

This proposal suggest replacing String initializers taking Character or 
UnicodeScalar as a repeating value by a more general initializer that takes a 
String as a repeating value. This is done to avoid the ambiguities in the 
current String API, which can be only resolved by explicit casting. It is also 
proposed to remove one of the String.append APIs to match these changes.

All user-facing Swift APIs must go through Swift Evolution. While this is a 
relatively simple API change with an existing implementation, this formal 
proposal provides a paper trail as is normal and usual for this process.

Motivation


This change introduces a non-ambiguous API for constructing Strings. With the 
set of String initializers available today, ones often needs to explicitly cast 
the repeating value literal to disambiguate what initializer is meant to be 
used.

An example of the ambiguity:

> let x = String(repeating:"0", count: 10)
error: repl.swift:29:9: error: ambiguous use of 'init(repeating:count:)'
let x = String(repeating:"0", count: 10)
^

Swift.String:11:12: note: found this candidate
public init(repeating repeatedValue: Character, count: Int)
   ^

Swift.String:21:12: note: found this candidate
public init(repeating repeatedValue: UnicodeScalar, count: Int)
   ^

To disambiguate, one currently needs to write something like:
`let zeroes = String(repeating: "0" as Character, count: 10)` or
`let zeroes = String(repeating: "0" as UnicodeScalar, count: 10)`

Detailed Design


This update affects `String`.

It is proposed to replace the following ambiguous API:
*  `public init(repeating repeatedValue: Character, count: Int)`
*  `public init(repeating repeatedValue: UnicodeScalar, count: Int)`

by the following, more powerful API:
*  `public init(repeating repeatedValue: String, count: Int)`

To match this change, it is also proposed to remove the following String.append 
API:
*  `public mutating func append(_ x: UnicodeScalar)`
because there is already an existing and more powerful API:
*  `public mutating func append(_ other: String)`

Impact on Existing Code
===

Existing third party code using these to be removed String APIs will need 
migration.
A fixit could be provided to automate this migration.

Alternatives Considered
==

Not Applicable


-Roman

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, John McCall  wrote:

>> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution
>>  wrote:
>> on Thu Jul 21 2016, John McCall
>> > >
>
>> wrote:
>> 
 On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
 >
 wrote:
 on Thu Jul 21 2016, Matthew Johnson
 
 >>
>>> 
 wrote:
 
>>  * What is your evaluation of the proposal?
> 
> +1 to the first design.  I think this is a great solution that
> balances the many considerations that have been raised on all sides of
> this issue.  `open` is 2 characters shorter than `public` so
> complaints about boilerplate are no longer valid.  `internal` is the
> “default” - neither `public` nor `open` are privileged as a “default”
> for publishing API outside of a module.
> 
> I am interested in language enhancements such as exhaustive pattern
> matching on classes and protocols which rely on knowledge of the full
> class hierarchy.  Such enhancements will be far more useful if the
> language supports non-open, non-final classes.
> 
> There are design techniques that would require additional boilerplate
> if we cannot have non-open, non-final classes.
> 
> Most importantly, requiring library authors to choose `public` or
> `open` provides important documentation value.  Users of the library
> will know whether the author intends to support subclasses or not.
 
 I think this reasoning is flawed.
 
 If you make any methods overridable outside your module (“open”),
 obviously you mean to allow subclassing outside the module.  If you have
 no open methods, there's absolutely nothing you need to do to “support
 subclasses,” and from a design point-of-view, there's no reason to
 restrict people from subclassing.
>>> 
>>> Superclasses can have superclasses, which can themselves have open methods.
>>> This is, in fact, quite common for Cocoa programmers.
>> 
>> Okay, good point.
>> 
>> Making a class non-subclassable seems like a pretty indirect way to say
>> “not even inherited methods should be overridden outside the defining
>> module,” though.
>> 
>> Wouldn't we prefer to have a way to hide the inheritance relationship
>> (and thus prevent overriding of inherited methods) outside the module?
>> Or are these independently useful axes?
>
> I agree that it would make sense to be able to say "I allow
> subclasses, but they don't get to override any of my methods unless I
> say so, even things I inherit".  But that feels like a refinement.

A refinement of what?

To me, “I don't allow any overrides outside my module” is a much more
useful thing to be able to say than “I don't allow subclasses.”  If we
made “open” on a class mean that it's possible to override methods in
other modules, then it would acheive that purpose, and it would leave
“open” with a consistent meaning related only to overriding.

>
>
> John.
>
>> 
>>> 
>>> 
>>> John.
>>> 
 
 The only reasons I can see for allowing people to prevent non-final
 classes from being subclassed outside the module in which they are
 defined are:
 
 1. It feels like a nice point of control to have.
 
 2. Marginal performance gains as noted in the proposal
 
 I personally don't find these to be convincing.  #1 in particular seems
 like a poor way to make language design decisions.  If we decide to add
 this point of control, I'll justify it to myself in terms of #2.
 
 P.S., I can live with either alternative; it's just important to me that
 we understand the situation clearly when evaluating them.
 
 HTH,
 
 -- 
 Dave
 
 ___
 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
>>> 
>>> 
>> 
>> -- 
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 
>> 

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Chris Lattner via swift-evolution]

> On Jul 21, 2016, at 4:07 PM, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> As unfocussed as original

Please keep comments *constructive* on this list.

-Chris


> Regards
> (From mobile)
> 
> On Jul 22, 2016, at 12:40 AM, Adrian Zubarev via swift-evolution 
> > wrote:
> 
>> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
>>  
>> 
>> Rename T.Type
>> 
>> Proposal: SE–0126 
>> 
>> Authors: Adrian Zubarev , Anton Zhilin 
>> 
>> Status: Revision
>> Review manager: Chris Lattner 
>> Revision: 2
>> Previous Revisions: 1 
>> 
>> Introduction
>> 
>> This proposal renames the current metatype T.Type notation and the global 
>> function from SE–0096 to match the changes.
>> 
>> Swift-evolution threads: 
>> 
>> [Pitch] Rename T.Type 
>> [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror 
>> 
>> [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror 
>> 
>> [Discussion] Seal T.Type into Type 
>> 
>> Motivation
>> 
>> In Swift metatypes have the following notation: T.Type
>> 
>> As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
>> favor of (re)moving magical intstance or type properties.
>> 
>> SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.
>> 
>> SE–0090 aims to remove .self completely.
>> 
>> We propose to rename T.Type to a generic-like notation Metatype. To be 
>> able to achieve this notation we have to resolve a few issues first.
>> 
>> Known issues of metatypes:
>> 
>> Assume this function that checks if an Int type conforms to a specific 
>> protocol. This check uses current model of metatypes combined in a generic 
>> context:
>> 
>> func intConforms(to _: T.Type) -> Bool {
>>return Int.self is T.Type
>> }
>> 
>> intConforms(to: CustomStringConvertible.self) //=> false
>> 
>> Int.self is CustomStringConvertible.Type  //=> true
>> [1] When T is a protocol P, T.Type is the metatype of the protocol type 
>> itself, P.Protocol. Int.self is not P.self.
>> 
>> [2] There isn’t a way to generically expression P.Type yet.
>> 
>> [3] The syntax would have to be changed in the compiler to get something 
>> that behaves like .Type today.
>> 
>> Written by Joe Groff: [1] 
>>  [2] 
>>  [3] 
>> 
>> A possible workaround might look like the example below, but does not allow 
>> to decompose P.Type:
>> 
>> func intConforms(to _: T.Type) -> Bool {
>>   return Int.self is T
>> }
>> 
>> intConforms(to: CustomStringConvertible.Type.self) //=> true
>> We can extend this issue and find the second problem by checking against the 
>> metatype of Any:
>> 
>> func intConforms(to _: T.Type) -> Bool {
>> return Int.self is T
>> }
>> 
>> intConforms(to: Any.Type.self) //=> true
>> 
>> intConforms(to: Any.self)  //=> true
>> 
>> Int.self is Any.Type   //=> Always true
>> When using Any the compiler does not require .Type at all and returns true 
>> for both variations.
>> 
>> The third issue will show itself whenever we would try to check protocol 
>> relationship with another protocol. Currently there is no way (that we know 
>> of) to solve this problem:
>> 
>> protocol P {}
>> protocol R : P {}
>> 
>> func rIsSubtype(of _: T.Type) -> Bool {
>> return R.self is T
>> }
>> 
>> rIsSubtype(of: P.Type.self) //=> false
>> 
>> R.self is Any.Type //=> Always true
>> R.self is P.Type   //=> true
>> R.self is R.Type   //=> true
>> We also believe that this issue is the reason why the current global 
>> functions sizeof, strideof and alignof make use of generic (_: T.Type) 
>> declaration notation instead of (_: Any.Type).
>> 
>> Proposed solution
>> 
>> Rename any occurrence of T.Type and T.Protocol to Metatype.
>> 
>> Revise metatypes internally. 
>> 
>> When T is a protocol, T.self should always return an instance of Metatype 
>> (old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect 
>> the same type relationship behavior like the actual types themselves. 
>> 
>> To match the correct meaning and usage of the noun ‘Metatype’ from this 
>> proposal, we also propose to rename the global function from SE–0096:
>> 
>> before: public func type(of instance: T) -> T.Type
>> after: public func metatype(of 

[swift-evolution] [Proposal] Struct syntax for requesting a copy with an ivar set to an explicit value

[Grant Sheldon via swift-evolution]

Hi all,

I am hoping to get some feedback on a new proposal:

https://gist.github.com/gsheld/542a57c1ca5efe87892a28759215283e

The basic idea is to expose syntax that would make it trivial to create a
copy of a Struct instance with an ivar set to a particular value. The
"proposal" I've linked above will give examples and some motivation for the
suggestion. It is a simple gist and not in any way ready for a PR.

Let me know what you think! I'm curious to know if this bit of syntactic
sugar would have value for any of you.

Best wishes,

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

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

[L. Mihalkovic via swift-evolution]

As unfocussed as original
Regards
(From mobile)

> On Jul 22, 2016, at 12:40 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
> 
> Rename T.Type
> 
> Proposal: SE–0126
> Authors: Adrian Zubarev, Anton Zhilin
> Status: Revision
> Review manager: Chris Lattner
> Revision: 2
> Previous Revisions: 1
> Introduction
> 
> This proposal renames the current metatype T.Type notation and the global 
> function from SE–0096 to match the changes.
> 
> Swift-evolution threads:
> 
> [Pitch] Rename T.Type
> [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
> [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
> [Discussion] Seal T.Type into Type
> Motivation
> 
> In Swift metatypes have the following notation: T.Type
> 
> As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
> favor of (re)moving magical intstance or type properties.
> 
> SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.
> 
> SE–0090 aims to remove .self completely.
> 
> We propose to rename T.Type to a generic-like notation Metatype. To be 
> able to achieve this notation we have to resolve a few issues first.
> 
> Known issues of metatypes:
> 
> Assume this function that checks if an Int type conforms to a specific 
> protocol. This check uses current model of metatypes combined in a generic 
> context:
> 
> func intConforms(to _: T.Type) -> Bool {
>return Int.self is T.Type
> }
> 
> intConforms(to: CustomStringConvertible.self) //=> false
> 
> Int.self is CustomStringConvertible.Type  //=> true
> [1] When T is a protocol P, T.Type is the metatype of the protocol type 
> itself, P.Protocol. Int.self is not P.self.
> 
> [2] There isn’t a way to generically expression P.Type yet.
> 
> [3] The syntax would have to be changed in the compiler to get something that 
> behaves like .Type today.
> 
> Written by Joe Groff: [1] [2] [3]
> A possible workaround might look like the example below, but does not allow 
> to decompose P.Type:
> 
> func intConforms(to _: T.Type) -> Bool {
>   return Int.self is T
> }
> 
> intConforms(to: CustomStringConvertible.Type.self) //=> true
> We can extend this issue and find the second problem by checking against the 
> metatype of Any:
> 
> func intConforms(to _: T.Type) -> Bool {
> return Int.self is T
> }
> 
> intConforms(to: Any.Type.self) //=> true
> 
> intConforms(to: Any.self)  //=> true
> 
> Int.self is Any.Type   //=> Always true
> When using Any the compiler does not require .Type at all and returns true 
> for both variations.
> 
> The third issue will show itself whenever we would try to check protocol 
> relationship with another protocol. Currently there is no way (that we know 
> of) to solve this problem:
> 
> protocol P {}
> protocol R : P {}
> 
> func rIsSubtype(of _: T.Type) -> Bool {
> return R.self is T
> }
> 
> rIsSubtype(of: P.Type.self) //=> false
> 
> R.self is Any.Type //=> Always true
> R.self is P.Type   //=> true
> R.self is R.Type   //=> true
> We also believe that this issue is the reason why the current global 
> functions sizeof, strideof and alignof make use of generic (_: T.Type) 
> declaration notation instead of (_: Any.Type).
> 
> Proposed solution
> 
> Rename any occurrence of T.Type and T.Protocol to Metatype.
> 
> Revise metatypes internally.
> 
> When T is a protocol, T.self should always return an instance of Metatype 
> (old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect 
> the same type relationship behavior like the actual types themselves.
> 
> To match the correct meaning and usage of the noun ‘Metatype’ from this 
> proposal, we also propose to rename the global function from SE–0096:
> 
> before: public func type(of instance: T) -> T.Type
> after: public func metatype(of instance: T) -> Metatype
> Examples:
> 
> protocol P {}
> protocol R : P {}
> class A : P {}
> class B : A, R {}
> 
> func `is`(metatype: Metatype, also _: Metatype ) -> Bool {
> return metatype is Metatype
> }
> 
> `is`(metatype: R.self, also: Any.self) //=> true | Currently: false
> `is`(metatype: R.self, also: P.self)   //=> true | Currently: false
> `is`(metatype: R.self, also: R.self)   //=> true
> 
> `is`(metatype: B.self, also: Any.self) //=> true | Currently: false
> `is`(metatype: B.self, also: P.self)   //=> true | Currently: false
> `is`(metatype: B.self, also: R.self)   //=> true | Currently: false
> `is`(metatype: B.self, also: A.self)   //=> true
> `is`(metatype: B.self, also: B.self)   //=> true
> 
> func cast(metatype: Metatype, to _: Metatype) -> Metatype? {
> return metatype as? Metatype
> }
> 
> cast(metatype: R.self, to: Any.self) //=> an Optional | 
> Currently: nil
> cast(metatype: R.self, to: P.self)   //=> an Optional   | 
> Currently: nil
> cast(metatype: R.self, to: R.self)   //=> an 

Re: [swift-evolution] [Pitch] Rename Mirror

[Anton Zhilin via swift-evolution]

2016-07-22 1:34 GMT+03:00 Dmitri Gribenko :
>
> > Mirror.DisplayStyle contains optional and set as special cases, but does
> not
> > contain function
> > Mirror collects all information possible at initialization, while for
> true
> > reflection we want laziness
> > Mirror allows customization. For example, Array is represented with a
> > field for each of its elements. Do we want this for “true” reflection we
> > want to add in the future?
>
> Why can't we add these features to Mirror in future?


Reflection in some other languages works as follows: we have a type (let's
name it 'Reflection'). Each instance of it contains ID of one type and can,
for example, retrieve an array of its static or normal methods.
'Mirror', on the other hand, serves as a container for information about a
single instance. Moreover, types can completely customize contents of their
'Mirror's. This is incompatible with laziness and with how reflection
should work, based on experience from other languages.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

[Tony Allevato via swift-evolution]

+1. This is an obvious improvement and makes the API safer to use, and
aligns with other string APIs (like those that decode UTF-8).
On Thu, Jul 21, 2016 at 3:31 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> +1. Sensible change; addresses a real issue; proposed solution is the one
> that most fits Swift best practices.
> On Thu, Jul 21, 2016 at 17:28 Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of "SE-0128: Change failable UnicodeScalar initializers to
>> failable" begins now and runs through July 24. The proposal is available
>> here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.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?
>> * 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

[swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev via swift-evolution]

https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md

Rename T.Type

Proposal: SE–0126
Authors: Adrian Zubarev, Anton Zhilin
Status: Revision
Review manager: Chris Lattner
Revision: 2
Previous Revisions: 1
Introduction

This proposal renames the current metatype T.Type notation and the global 
function from SE–0096 to match the changes.

Swift-evolution threads:

[Pitch] Rename T.Type
[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

In Swift metatypes have the following notation: T.Type

As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
favor of (re)moving magical intstance or type properties.

SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.

SE–0090 aims to remove .self completely.

We propose to rename T.Type to a generic-like notation Metatype. To be able 
to achieve this notation we have to resolve a few issues first.

Known issues of metatypes:

Assume this function that checks if an Int type conforms to a specific 
protocol. This check uses current model of metatypes combined in a generic 
context:

func intConforms(to _: T.Type) -> Bool {
   return Int.self is T.Type
}

intConforms(to: CustomStringConvertible.self) //=> false

Int.self is CustomStringConvertible.Type  //=> true
[1] When T is a protocol P, T.Type is the metatype of the protocol type itself, 
P.Protocol. Int.self is not P.self.

[2] There isn’t a way to generically expression P.Type yet.

[3] The syntax would have to be changed in the compiler to get something that 
behaves like .Type today.

Written by Joe Groff: [1] [2] [3]
A possible workaround might look like the example below, but does not allow to 
decompose P.Type:

func intConforms(to _: T.Type) -> Bool {
  return Int.self is T
}

intConforms(to: CustomStringConvertible.Type.self) //=> true
We can extend this issue and find the second problem by checking against the 
metatype of Any:

func intConforms(to _: T.Type) -> Bool {
return Int.self is T
}

intConforms(to: Any.Type.self) //=> true

intConforms(to: Any.self)  //=> true

Int.self is Any.Type   //=> Always true
When using Any the compiler does not require .Type at all and returns true for 
both variations.

The third issue will show itself whenever we would try to check protocol 
relationship with another protocol. Currently there is no way (that we know of) 
to solve this problem:

protocol P {}
protocol R : P {}

func rIsSubtype(of _: T.Type) -> Bool {
return R.self is T
}

rIsSubtype(of: P.Type.self) //=> false

R.self is Any.Type //=> Always true
R.self is P.Type   //=> true
R.self is R.Type   //=> true
We also believe that this issue is the reason why the current global functions 
sizeof, strideof and alignof make use of generic (_: T.Type) declaration 
notation instead of (_: Any.Type).

Proposed solution

Rename any occurrence of T.Type and T.Protocol to Metatype.

Revise metatypes internally.

When T is a protocol, T.self should always return an instance of Metatype 
(old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect the 
same type relationship behavior like the actual types themselves.

To match the correct meaning and usage of the noun ‘Metatype’ from this 
proposal, we also propose to rename the global function from SE–0096:

before: public func type(of instance: T) -> T.Type
after: public func metatype(of instance: T) -> Metatype
Examples:

protocol P {}
protocol R : P {}
class A : P {}
class B : A, R {}

func `is`(metatype: Metatype, also _: Metatype ) -> Bool {
return metatype is Metatype
}

`is`(metatype: R.self, also: Any.self) //=> true | Currently: false
`is`(metatype: R.self, also: P.self)   //=> true | Currently: false
`is`(metatype: R.self, also: R.self)   //=> true

`is`(metatype: B.self, also: Any.self) //=> true | Currently: false
`is`(metatype: B.self, also: P.self)   //=> true | Currently: false
`is`(metatype: B.self, also: R.self)   //=> true | Currently: false
`is`(metatype: B.self, also: A.self)   //=> true
`is`(metatype: B.self, also: B.self)   //=> true

func cast(metatype: Metatype, to _: Metatype) -> Metatype? {
return metatype as? Metatype
}

cast(metatype: R.self, to: Any.self) //=> an Optional | 
Currently: nil
cast(metatype: R.self, to: P.self)   //=> an Optional   | 
Currently: nil
cast(metatype: R.self, to: R.self)   //=> an Optional   | 
Currently: an Optional

let anyR: Any.Type = R.self
let r = cast(metatype: anyR, to: R.self) //=> an Optional   | 
Currently: an Optional

cast(metatype: B.self, to: Any.self) //=> an Optional | 
Currently: nil
cast(metatype: B.self, to: P.self)   //=> an Optional   | 
Currently: nil
cast(metatype: B.self, to: R.self)   //=> an Optional   | 
Currently: nil
cast(metatype: 

Re: [swift-evolution] [Pitch] Rename Mirror

[Dmitri Gribenko via swift-evolution]

On Thu, Jul 21, 2016 at 3:25 PM, Anton Zhilin via swift-evolution
 wrote:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-rename-mirror.md
>
> Rename Mirror
>
> Proposal: SE-
> Author: Anton Zhilin, Adrian Zubarev
> Status: Awaiting review
> Review manager: TBD
>
> Introduction
>
> Rename Mirror to DebugRepresentation and CustomReflectable to
> CustomDebugRepresentable.
>
> Motivation
>
> Name of Mirror does not reflect (no pun) what it is intended to do, i.e.
> providing full featured reflection, which we want to see in Swift 4. Other
> than that, it is only intended to serve for debugging purposes, e.g.
> building trees for selected objects. Some evidence to that:
>
> Mirror.DisplayStyle contains optional and set as special cases, but does not
> contain function
> Mirror collects all information possible at initialization, while for true
> reflection we want laziness
> Mirror allows customization. For example, Array is represented with a
> field for each of its elements. Do we want this for “true” reflection we
> want to add in the future?

Why can't we add these features to Mirror in future?

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] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

[Xiaodi Wu via swift-evolution]

+1. Sensible change; addresses a real issue; proposed solution is the one
that most fits Swift best practices.
On Thu, Jul 21, 2016 at 17:28 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0128: Change failable UnicodeScalar initializers to
> failable" begins now and runs through July 24. The proposal is available
> here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.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?
> * 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] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Garth Snyder via swift-evolution]

+1

[ Long, sorry… ]

This version is a big step forward! Thanks for the continued work and 
comments...

I want to propose a small reframing that I think would help to clarify some of 
the remaining issues. It’s not really a “counterproposal” because I don’t think 
it actually changes all that much about the proposal. It’s more a question of 
how one conceptualizes the changes and fits them into the existing framework.

The gist is: let’s let the second shoe drop and admit that in the current 
proposal, “open” is now an access level modifier, pure and simple.

In the original proposal (and the ensuing discussion), there was tacit 
agreement that subclassability/overridability and access levels should be 
orthogonal. However, given the direction that the design has taken since then, 
I think we should revisit that decision.

open IS in fact an access level. I can’t say it any better than the proposal 
itself: “Since the first release of Swift, marking a class public has provided 
two capabilities: it allows other modules to instantiate and use the class, and 
it also allows other modules to define subclasses of it. Similarly, marking a 
class member (a method, property, or subscript) public has provided two 
capabilities: it allows other modules to use the member, and it also allows 
those modules to override it…This proposal suggests distinguishing these 
concepts. A public member will only be usable by other modules, but not 
overridable. An open member will be both usable and overridable. Similarly, a 
public class will only be usable by other modules, but not subclassable. An 
open class will be both usable and subclassable.”

In other words, subclassability/overridability always was an access level 
issue. All we are doing now is subdividing public into two separate sublevels, 
public and open. Just as public subsumes all the privileges of internal, open 
subsumes public.

Arguments:

First, the vast majority of resistance to this proposal (including my own, 
originally) has centered on the sense that coding options are being removed for 
potentially or partially ideological reasons (see SoftwareDevelopmentAttitude 
), without 
clear value being offered in return. Reframing open as an access level 
completely nullifies this objection. “internal” is already the default access 
level, and the community seems very comfortable with this. For public APIs, 
developers are now simply required to make a neutral choice between public and 
open. There’s no strong-arming and no surprising imposition of new 
restrictions. Developers just have to make exactly the same, explicit access 
level decisions they did before. (For public API, the default is already so 
restrictive as to be moot. No accusations of “you picked the wrong default”!)

Second, framing open as an access level automatically resolves the ambiguity 
between proposal options #1 and #2, in favor of #1 (classes can be marked 
open). The reason there’s ambiguity about this choice is that there’s ambiguity 
about what open "really is.” Pin down exactly how open fits into the larger 
language, and the resolution is obvious. We already know what it means for a 
class and its members to have different access levels: the members are clamped 
to the access level of the container. All of the arguments that led to this 
convention — chiefly, that one may want to keep eventual publication in mind 
while developing and then be able to “flip the switch” in one place —  apply 
equally to the additional privileges of open.  

Third, developers already understand access levels and how they interact. If 
open is just an access level, all of this proposal’s changes can be fully and 
naturally described in one line: “public no longer includes the right to 
subclass or override. To get the behavior formerly known as public, use open 
instead.” Clear, concise, and not very controversial.

Fourth, bending over backwards to insist that open is not an access level leads 
to a variety of weird effects and special cases. For example, the fact that 
open implies public unless otherwise stated, which is mighty strange for 
modifiers that are supposedly orthogonal. Not to mention all the potential 
headbutts mentioned earlier by Xiaodi Wu; I agree that open in combination with 
internal seems oxymoronic. All of these nits would just go away if open were an 
access level. Again, all of this is the case because open really does quack 
like an access level and walk like an access level.

Points:

Q: “But what about access-leveled entities for which ‘open’ doesn’t make sense? 
What does ‘open struct’ mean?”
A: It doesn’t mean anything and should be an error. Simple. It’s not as if 
there weren’t all kinds of above-grammar-level restrictions in the current 
design…

Q: “What about conflicts with other modifiers, e.g. ‘open is not permitted on 
declarations that are explicitly final or dynamic’? Isn’t it weird that a 

[swift-evolution] [Review] SE-0128: Change failable UnicodeScalar initializers to failable

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0128: Change failable UnicodeScalar initializers to failable" 
begins now and runs through July 24. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.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?
* 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[Chris Lattner via swift-evolution]

> On Jul 20, 2016, at 5:18 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0126: Refactor Metatypes, repurpose T.self and Mirror" 
> begins now and runs through July 24. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md

As mentioned on another thread, this proposal has been withdrawn.  Thanks,

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

[swift-evolution] [Pitch] Rename Mirror

[Anton Zhilin via swift-evolution]

https://github.com/Anton3/swift-evolution/blob/master/proposals/-rename-mirror.md
Rename Mirror

   - Proposal: SE- 
   - Author: Anton Zhilin , Adrian Zubarev
   
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

Rename Mirror to DebugRepresentation and CustomReflectable to
CustomDebugRepresentable.
Motivation

Name of Mirror does not reflect (no pun) what it is intended to do, i.e.
providing full featured reflection, which we want to see in Swift 4. Other
than that, it is only intended to serve for debugging purposes, e.g.
building trees for selected objects. Some evidence to that:

   - Mirror.DisplayStyle contains optional and set as special cases, but
   does not contain function
   - Mirror collects all information possible at initialization, while for
   true reflection we want laziness
   - Mirror allows customization. For example, Array is represented with
   a field for each of its elements. Do we want this for “true” reflection we
   want to add in the future?

Proposed solution

   - Rename struct Mirror to DebugRepresentation
   - Rename protocol CustomReflectable to CustomDebugRepresentable
   - Rename property customMirror to customDebugRepresentation
   - Hope that one day we will get a real Mirror with full reflection
   capabilities

Impact on existing code

This is a breaking change; easy automated migration possible.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Withdrawn for revision] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md

The authors of SE-0126 have requested that we withdraw the proposal.  The idea 
will be revised, return back to the “pitch” phase, and when that converges, 
SE-0126 will be revised.

Thanks,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[John McCall via swift-evolution]

> On Jul 21, 2016, at 3:05 PM, Nevin Brackett-Rozinsky 
>  wrote:
> I agree that it would make sense to be able to say "I allow subclasses, but 
> they
> don't get to override any of my methods unless I say so, even things I 
> inherit".
> But that feels like a refinement.
> 
> Well, we can already achieve that by writing,
> 
>   public final func f() -> Int { return _f() }
>   internal func _f() -> Int { return 42 }
> 
> That way subclasses in the module can override _f to change the behavior of 
> f, while outside they cannot. So we can already accomplish “an open member of 
> a base class is sealed by a subclass”.

Well.  While that is, yes, technically possible to do to the entire open API of 
the superclass, it's so much boilerplate for most situations that it might as 
well not exist.  And that's ignoring the fact that the superclass can always 
add more open API.  I wouldn't want to dismiss the feature request this way, 
because it's clearly not an acceptable solution.

John.


> 
> What we *can’t* do, either now or with the proposal, is have a sub-subclass 
> *re-open* that member:
> 
> open class A { open var x: Int //... }
> open class B: A { override final var x: Int { return _x } }
> open class C: B { override open var x: Int { return 16 } }   // error: cannot 
> override `final` member
> 
> For that we would need either an explicit `sealed` keyword, or the ability to 
> override an `open` member as `public` (non-open), which class B could use 
> here.
> 
> Nevin
> 
> 
> On Thu, Jul 21, 2016 at 4:22 PM, John McCall via swift-evolution 
> > wrote:
>> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> on Thu Jul 21 2016, John McCall > > wrote:
>> 
 On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
 > wrote:
 on Thu Jul 21 2016, Matthew Johnson
 
 >>
>>> 
 wrote:
 
>>  * What is your evaluation of the proposal?
> 
> +1 to the first design.  I think this is a great solution that
> balances the many considerations that have been raised on all sides of
> this issue.  `open` is 2 characters shorter than `public` so
> complaints about boilerplate are no longer valid.  `internal` is the
> “default” - neither `public` nor `open` are privileged as a “default”
> for publishing API outside of a module.
> 
> I am interested in language enhancements such as exhaustive pattern
> matching on classes and protocols which rely on knowledge of the full
> class hierarchy.  Such enhancements will be far more useful if the
> language supports non-open, non-final classes.
> 
> There are design techniques that would require additional boilerplate
> if we cannot have non-open, non-final classes.
> 
> Most importantly, requiring library authors to choose `public` or
> `open` provides important documentation value.  Users of the library
> will know whether the author intends to support subclasses or not.
 
 I think this reasoning is flawed.
 
 If you make any methods overridable outside your module (“open”),
 obviously you mean to allow subclassing outside the module.  If you have
 no open methods, there's absolutely nothing you need to do to “support
 subclasses,” and from a design point-of-view, there's no reason to
 restrict people from subclassing.
>>> 
>>> Superclasses can have superclasses, which can themselves have open methods.
>>> This is, in fact, quite common for Cocoa programmers.
>> 
>> Okay, good point.
>> 
>> Making a class non-subclassable seems like a pretty indirect way to say
>> “not even inherited methods should be overridden outside the defining
>> module,” though.
>> 
>> Wouldn't we prefer to have a way to hide the inheritance relationship
>> (and thus prevent overriding of inherited methods) outside the module?
>> Or are these independently useful axes?
> 
> I agree that it would make sense to be able to say "I allow subclasses, but 
> they
> don't get to override any of my methods unless I say so, even things I 
> inherit".
> But that feels like a refinement.
> 
> John.
> 
>> 
>>> 
>>> 
>>> John.
>>> 
 
 The only reasons I can see for allowing people to prevent non-final
 classes from being subclassed outside the module in which they are
 defined are:
 
 1. It feels like a nice point of control to have.
 
 2. Marginal performance gains as noted in the proposal
 
 I personally don't find these to be convincing.  #1 in particular seems
 like a poor way to make language design 

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Tino Heth via swift-evolution]

> Am 21.07.2016 um 22:11 schrieb Haravikk :
> 
> it also opens passing of arrays to variadic functions, which seems to be 
> fairly desired despite no proposal that I could find
I haven't seen a complete proposal, but I managed to remember a link to the 
last(?) discussion about it:
[Idea] Passing an Array to Variadic Functions 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Nevin Brackett-Rozinsky via swift-evolution]

>
> I agree that it would make sense to be able to say "I allow subclasses,
> but they
> don't get to override any of my methods unless I say so, even things I
> inherit".
> But that feels like a refinement.


Well, we can already achieve that by writing,

  public final func f() -> Int { return _f() }
  internal func _f() -> Int { return 42 }

That way subclasses in the module can override _f to change the behavior of
f, while outside they cannot. So we can already accomplish “an open member
of a base class is sealed by a subclass”.

What we *can’t* do, either now or with the proposal, is have a sub-subclass
*re-open* that member:

open class A { open var x: Int //... }
open class B: A { override final var x: Int { return _x } }
open class C: B { override open var x: Int { return 16 } }   // error:
cannot override `final` member

For that we would need either an explicit `sealed` keyword, or the ability
to override an `open` member as `public` (non-open), which class B could
use here.

Nevin


On Thu, Jul 21, 2016 at 4:22 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> on Thu Jul 21 2016, John McCall  wrote:
>
> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
>  wrote:
> on Thu Jul 21 2016, Matthew Johnson
>  >>
>
>
> wrote:
>
> * What is your evaluation of the proposal?
>
>
> +1 to the first design.  I think this is a great solution that
> balances the many considerations that have been raised on all sides of
> this issue.  `open` is 2 characters shorter than `public` so
> complaints about boilerplate are no longer valid.  `internal` is the
> “default” - neither `public` nor `open` are privileged as a “default”
> for publishing API outside of a module.
>
> I am interested in language enhancements such as exhaustive pattern
> matching on classes and protocols which rely on knowledge of the full
> class hierarchy.  Such enhancements will be far more useful if the
> language supports non-open, non-final classes.
>
> There are design techniques that would require additional boilerplate
> if we cannot have non-open, non-final classes.
>
> Most importantly, requiring library authors to choose `public` or
> `open` provides important documentation value.  Users of the library
> will know whether the author intends to support subclasses or not.
>
>
> I think this reasoning is flawed.
>
> If you make any methods overridable outside your module (“open”),
> obviously you mean to allow subclassing outside the module.  If you have
> no open methods, there's absolutely nothing you need to do to “support
> subclasses,” and from a design point-of-view, there's no reason to
> restrict people from subclassing.
>
>
> Superclasses can have superclasses, which can themselves have open methods.
> This is, in fact, quite common for Cocoa programmers.
>
>
> Okay, good point.
>
> Making a class non-subclassable seems like a pretty indirect way to say
> “not even inherited methods should be overridden outside the defining
> module,” though.
>
>
> Wouldn't we prefer to have a way to hide the inheritance relationship
> (and thus prevent overriding of inherited methods) outside the module?
> Or are these independently useful axes?
>
>
> I agree that it would make sense to be able to say "I allow subclasses,
> but they
> don't get to override any of my methods unless I say so, even things I
> inherit".
> But that feels like a refinement.
>
> John.
>
>
>
>
> John.
>
>
> The only reasons I can see for allowing people to prevent non-final
> classes from being subclassed outside the module in which they are
> defined are:
>
> 1. It feels like a nice point of control to have.
>
> 2. Marginal performance gains as noted in the proposal
>
> I personally don't find these to be convincing.  #1 in particular seems
> like a poor way to make language design decisions.  If we decide to add
> this point of control, I'll justify it to myself in terms of #2.
>
> P.S., I can live with either alternative; it's just important to me that
> we understand the situation clearly when evaluating them.
>
> HTH,
>
> --
> Dave
>
> ___
> 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
>
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> 

Re: [swift-evolution] Returning nothing

[Daniel Steinberg via swift-evolution]

Thanks all,

I did note that Nothing had been considered for another purpose and rejected so 
I didn’t think it would cause confusion.

I understand folks who advocate another name such as Unit but don’t feel that 
would help newcomers. Unit doesn’t seem to be more intuitive for them than Void.

Chris’ note addressed my misconception that a goal of Swift was that it could 
be a good first or learning language. I apologize for drawing that conclusion 
from (perhaps misreading) articles about Playgrounds that mentioned Swift as 
being designed so that it was a ideal for children and new programmers. The 
articles may have meant that the environment was designed for that purpose not 
the language.

Although my examples were in stand-alone functions, I was really thinking about 
functions that are passed as argument to other functions.

Given the response, there doesn’t seem to be a reason for me to draw up a 
proposal.

Thank you for the quick feedback,

Best,

Daniel


> On Jul 21, 2016, at 1:19 PM, Matthew Johnson  wrote:
> 
>> 
>> On Jul 21, 2016, at 11:59 AM, Xiaodi Wu > > wrote:
>> 
>> Quite frankly, I think the ship has long sailed for renaming Void.
> 
> Agree.  I’m not advocating change, just stating things that should be 
> considered if anyone wants to propose it.
> 
>> 
>> 
>> On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
>> > > wrote:
>> >
>> > This may be a silly question - given that one of Swift’s design principles 
>> > is to be a language for new programmers and for APIs to read like English 
>> > phrases, should we replace the typealias of Void for the return type () 
>> > with Nothing.
>> 
>> Nothing was one of the names considered for the bottom type that replaces 
>> @noreturn 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>>  
>> ).
>>  I think it would be confusing to rename Void to Nothing.
>> 
>> If we consider renaming it Unit is the obvious way to go 
>> (https://en.m.wikipedia.org/wiki/Unit_type 
>> )
>> 
>> >
>> > So
>> >
>> > f: ( input: Int) -> Void
>> >
>> > becomes
>> >
>> > f: ( input: Int) -> Nothing
>> >
>> > Instead of saying “f takes an Int and returns a Void” I read this as “f 
>> > takes an Int and returns nothing”.
>> >
>> > I’ve been using f:(input: Int) -> () because it’s easier to explain than 
>> > Void to non-experienced programmers. Experienced programmers have no 
>> > problem with Void. But Void seems to be something we’re using just because 
>> > we have for a while - like x++ and C-style for loops.
>> >
>> > Best,
>> >
>> > Daniel
>> > ___
>> > 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 #3] SE-0117: Allow distinguishing between public access and public overridability

[Charles Srstka via swift-evolution]

> On Jul 21, 2016, at 2:29 PM, Karl via swift-evolution 
>  wrote:
> 
>> On 21 Jul 2016, at 20:49, Chris Lattner > > wrote:
>> 
>> On Jul 21, 2016, at 8:56 AM, Karl > > wrote:
>>> 
>>> Just posted in the Review #2 thread. I read the updated proposal, and I 
>>> have another idea besides making “final” default:
>> 
>> Hi Karl,
>> 
>> Please respond to proposal on this thread with your evaluation of it.  This 
>> isn’t the right place to make counterproposals.
>> 
>> -Chris
> 
> -1 from me. Same reasons as before, I think:

I’m -1 as well, for the reasons that have already been given, but since it’s 
clear that this thing’s going to be rammed down our throats no matter how we 
feel about it, we might as well try to make lemonade:

> First proposal:
> - Conflation of ‘public’ and ‘open’; it feels like open is a new higher 
> access level, like getting married, or going sudo or something. If this 
> proposal was accepted, ‘open' should substitute ‘public’, and never be 
> alongside it (the same way “public private class” makes no sense)

Actually, if ‘public’ and ‘open’ are separated, it might allow us to finally 
have some sort of ‘protected’ access level. ‘private open’ implies something 
that can be subclassed but not otherwise accessed, which would more or less 
provide ‘protected’ functionality.

Charles

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

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Paul Cantrell via swift-evolution]

> • What is your evaluation of the proposal?

Breaking it down in parts:

+1 to the basic principle of making the external subclassing a conscious, 
explicit API design decision.

+1 to providing a design state for subclassability that leaves the most room 
for non-breaking future changes. Those who think about API design know that 
allowing subclassing is a non-retractable promise, but the fact that “final” 
will _also_ be non-retractible in Swift when we have ABI stability is a 
slam-dunk argument for the existence of “open.”

+1 to the word “open.” I went back and forth on this a little, pondering 
“subclassable,” “overridable,” etc., but those terms are misleading: they imply 
“not final,” and don’t capture the fact that module boundaries are an important 
ingredient of the concept at hand here.

-1 to “open” implying “public.” I continue to feel that I want to see the word 
“public” on every element that is part of my public API. I don’t mind “public 
open,” and the rationale in the Alternatives section didn’t sway me. However, I 
don’t consider this point a dealbreaker, and am still in favor of this proposal 
overall.

Without having a very strong feeling about it, I’m in favor of the “first 
design,” i.e. the existence of non-open, non-final classes. It’s the less 
surprising model, somehow. I also like the idea of a library being able to make 
assumptions about a closed set of subtypes, just as enums allow assumptions 
about a closed set of values. (A future construct could even apply enum-like 
code path analysis when switching on a supertype with a known set of subtypes.)

Despite that, I would accept the second design (no such thing as “open class”) 
if it consensus favored it.

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

Yes. It would be on good API design principles alone, but the coming ABI 
stability problems around final, at least in my dim understanding of them, 
makes this crucial.

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

It does.

Swift favors making consequential design decisions explicit, and “non-final by 
default” currently breaks with that principle.

“Subclassable within a module by default” is consistent with Swift’s “internal 
by default” attitude.

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

Other languages have solved these same API design concerns with “final by 
default.” I prefer this alternative.

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

I’ve loosely followed the conversation from the beginning, though I confess I 
did not count every sling and arrow in the long message threads.

Cheers,

Paul

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[Adrian Zubarev via swift-evolution]

Here is the new revised draft: 
https://gist.github.com/DevAndArtist/f7da7d7338eedb40adb9c5631a34aee1

We’d like to hear your feedback before we submit this revision. It’s unusual 
for such a quick revision, but it’s clearly was asked by Joe Groff and the 
feedback from the community.

Introduction

This proposal renames the current metatype T.Type notation and the global 
function from SE–0096 to match the changes.

Swift-evolution threads:

[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
[Discussion] Seal T.Type into Type
Motivation

In Swift metatypes have the following notation: T.Type

As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
favor of (re)moving magical intstance or type properties.

SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.

SE–0090 aims to remove .self completely.

We propose to rename T.Type to a generic-like notation Metatype. To be able 
to achieve this notation we have to resolve a few issues first.

Known issues of metatypes:

Assume this function that checks if an Int type conforms to a specific 
protocol. This check uses current model of metatypes combined in a generic 
context:

func intConforms(to _: T.Type) -> Bool {
   return Int.self is T.Type
}

intConforms(to: CustomStringConvertible.self) //=> false

Int.self is CustomStringConvertible.Type  //=> true
[1] When T is a protocol P, T.Type is the metatype of the protocol type itself, 
P.Protocol. Int.self is not P.self.

[2] There isn’t a way to generically expression P.Type yet.

[3] The syntax would have to be changed in the compiler to get something that 
behaves like .Type today.

Written by Joe Groff: [1] [2] [3]
A possible workaround might look like the example below, but does not allow to 
decompose P.Type:

func intConforms(to _: T.Type) -> Bool {
  return Int.self is T
}

intConforms(to: CustomStringConvertible.Type.self) //=> true
We can extend this issue and find the second problem by checking against the 
metatype of Any:

func intConforms(to _: T.Type) -> Bool {
return Int.self is T
}

intConforms(to: Any.Type.self) //=> true

intConforms(to: Any.self)  //=> true

Int.self is Any.Type   //=> Always true
When using Any the compiler does not require .Type at all and returns true for 
both variations.

The third issue will show itself whenever we would try to check protocol 
relationship with another protocol. Currently there is no way (that we know of) 
to solve this problem:

protocol P {}
protocol R : P {}

func rIsSubtype(of _: T.Type) -> Bool {
return R.self is T
}

rIsSubtype(of: P.Type.self) //=> false

R.self is Any.Type //=> Always true
R.self is P.Type   //=> true
R.self is R.Type   //=> true
We also believe that this issue is the reason why the current global functions 
sizeof, strideof and alignof make use of generic (_: T.Type) declaration 
notation instead of (_: Any.Type).

Proposed solution

Rename any occurrence of T.Type and T.Protocol to Metatype.

Revise metatypes internally.

When T is a protocol, T.self should always return an instance of Metatype 
(old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect the 
same type relationship behavior like the actual types themselves.

To match the correct meaning and usage of the noun ‘Metatype’ from this 
proposal, we also propose to rename the global function from SE–0096:

before: public func type(of instance: T) -> T.Type
after: public func metatype(of instance: T) -> Metatype
Examples:

protocol P {}
protocol R : P {}
class A : P {}
class B : A, R {}

func `is`(metatype: Metatype, also _: Metatype ) -> Bool {
return metatype is Metatype
}

`is`(metatype: R.self, also: Any.self) //=> true | Currently: false
`is`(metatype: R.self, also: P.self)   //=> true | Currently: false
`is`(metatype: R.self, also: R.self)   //=> true

`is`(metatype: B.self, also: Any.self) //=> true | Currently: false
`is`(metatype: B.self, also: P.self)   //=> true | Currently: false
`is`(metatype: B.self, also: R.self)   //=> true | Currently: false
`is`(metatype: B.self, also: A.self)   //=> true
`is`(metatype: B.self, also: B.self)   //=> true

func cast(metatype: Metatype, to _: Metatype) -> Metatype? {
return metatype as? Metatype
}

cast(metatype: R.self, to: Any.self) //=> an Optional | 
Currently: nil
cast(metatype: R.self, to: P.self)   //=> an Optional   | 
Currently: nil
cast(metatype: R.self, to: R.self)   //=> an Optional   | 
Currently: an Optional

let anyR: Any.Type = R.self
let r = cast(metatype: anyR, to: R.self) //=> an Optional   | 
Currently: an Optional

cast(metatype: B.self, to: Any.self) //=> an Optional | 
Currently: nil
cast(metatype: B.self, to: P.self)   //=> an Optional   | 
Currently: nil
cast(metatype: B.self, to: R.self)   //=> an Optional   | 
Currently: nil
cast(metatype: 

Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

[Austin Zheng via swift-evolution]

This proposal is great.

Complaining about an API that 99% of users won't ever have to touch and
exists to facilitate NS/CF interop is a bit precious, to be charitable.

On Thu, Jul 21, 2016 at 11:19 AM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 21, 2016, at 10:02 AM, Michael Gottesman via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hello everyone.
> >
> > This is a proposal to move AutoreleasingUnsafeMutablePointer from
> StdlibCore to the Objective C overlay. The reason to do this is that
> ideally StdlibCore would not have any code specific to ObjC in it. This is
> a small step that we can take in this direction by moving the public API of
> AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this
> would be done is that the implementation for
> AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would
> add an underscore to make that API private to the standard library. Then
> inside the ObjC overlay, we would create a typealias to the internal API
> with the non-underscored name (i.e. make the typealias the public API).
> Then at a later point in time we can move the implementation. The reason
> why I am not proposing to move the implementation today is that there are
> dependencies in Array/Hashed Collections on
> AutoreleasingUnsafeMutablePointer. Moving that code is a larger project
> that is preconditioned on this proposal going in first as an incremental
> step.
> >
> > Thoughts, flames, etc?
>
> Sounds awesome. Someone will need to ping Bret Victor to update his
> T-shirt: https://twitter.com/worrydream/status/55853312645697
>
> -Joe
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[Adrian Zubarev via swift-evolution]

Sliced revision is almost done. We would like to focus on two things: 
`Metatype` and `metype(of:)`. I’ll post it here soon before submitting a PR. 

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[John McCall via swift-evolution]

> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution 
>  wrote:
> on Thu Jul 21 2016, John McCall  > wrote:
> 
>>> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
>>> > wrote:
>>> on Thu Jul 21 2016, Matthew Johnson
>>> 
>>> >>
>> 
>>> wrote:
>>> 
>   * What is your evaluation of the proposal?
 
 +1 to the first design.  I think this is a great solution that
 balances the many considerations that have been raised on all sides of
 this issue.  `open` is 2 characters shorter than `public` so
 complaints about boilerplate are no longer valid.  `internal` is the
 “default” - neither `public` nor `open` are privileged as a “default”
 for publishing API outside of a module.
 
 I am interested in language enhancements such as exhaustive pattern
 matching on classes and protocols which rely on knowledge of the full
 class hierarchy.  Such enhancements will be far more useful if the
 language supports non-open, non-final classes.
 
 There are design techniques that would require additional boilerplate
 if we cannot have non-open, non-final classes.
 
 Most importantly, requiring library authors to choose `public` or
 `open` provides important documentation value.  Users of the library
 will know whether the author intends to support subclasses or not.
>>> 
>>> I think this reasoning is flawed.
>>> 
>>> If you make any methods overridable outside your module (“open”),
>>> obviously you mean to allow subclassing outside the module.  If you have
>>> no open methods, there's absolutely nothing you need to do to “support
>>> subclasses,” and from a design point-of-view, there's no reason to
>>> restrict people from subclassing.
>> 
>> Superclasses can have superclasses, which can themselves have open methods.
>> This is, in fact, quite common for Cocoa programmers.
> 
> Okay, good point.
> 
> Making a class non-subclassable seems like a pretty indirect way to say
> “not even inherited methods should be overridden outside the defining
> module,” though.
> 
> Wouldn't we prefer to have a way to hide the inheritance relationship
> (and thus prevent overriding of inherited methods) outside the module?
> Or are these independently useful axes?

I agree that it would make sense to be able to say "I allow subclasses, but they
don't get to override any of my methods unless I say so, even things I inherit".
But that feels like a refinement.

John.

> 
>> 
>> 
>> John.
>> 
>>> 
>>> The only reasons I can see for allowing people to prevent non-final
>>> classes from being subclassed outside the module in which they are
>>> defined are:
>>> 
>>> 1. It feels like a nice point of control to have.
>>> 
>>> 2. Marginal performance gains as noted in the proposal
>>> 
>>> I personally don't find these to be convincing.  #1 in particular seems
>>> like a poor way to make language design decisions.  If we decide to add
>>> this point of control, I'll justify it to myself in terms of #2.
>>> 
>>> P.S., I can live with either alternative; it's just important to me that
>>> we understand the situation clearly when evaluating them.
>>> 
>>> HTH,
>>> 
>>> -- 
>>> Dave
>>> 
>>> ___
>>> 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 
>> 
>> 
> 
> -- 
> Dave
> 
> ___
> 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-0101: Reconfiguring sizeof and related functions into a unified MemoryLayout struct

[Tino Heth via swift-evolution]

> Am 15.07.2016 um 23:56 schrieb Dave Abrahams via swift-evolution 
> :
> 
> We're trying to get away from “magic” properties that exist on every
> type, I think.
I've a serious aversion against regular-looking constructs with special power 
as well (from time to time, I find myself thinking that ErrorType and 
SequenceType are somewhat odd… ;-)
On the other hand:
Is a magic struct better than a magic property?
After all, the size of a type is a property of that type…

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, Matthew Johnson  wrote:

>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Thu Jul 21 2016, Matthew Johnson  wrote:
>> 
>
* What is your evaluation of the proposal?
>>> 
>>> +1 to the first design.  I think this is a great solution that
>>> balances the many considerations that have been raised on all sides of
>>> this issue.  `open` is 2 characters shorter than `public` so
>>> complaints about boilerplate are no longer valid.  `internal` is the
>>> “default” - neither `public` nor `open` are privileged as a “default”
>>> for publishing API outside of a module.
>>> 
>>> I am interested in language enhancements such as exhaustive pattern
>>> matching on classes and protocols which rely on knowledge of the full
>>> class hierarchy.  Such enhancements will be far more useful if the
>>> language supports non-open, non-final classes.
>>> 
>>> There are design techniques that would require additional boilerplate
>>> if we cannot have non-open, non-final classes.
>>> 
>>> Most importantly, requiring library authors to choose `public` or
>>> `open` provides important documentation value.  Users of the library
>>> will know whether the author intends to support subclasses or not.
>> 
>> I think this reasoning is flawed.
>> 
>> If you make any methods overridable outside your module (“open”),
>> obviously you mean to allow subclassing outside the module.  If you have
>> no open methods, there's absolutely nothing you need to do to “support
>> subclasses,” and from a design point-of-view, there's no reason to
>> restrict people from subclassing.
>
> I disagree.  As has been discussed when a class is not open the author
> does not make a commitment to allow subclasses.  

Yes, but that argument is based on the *assumption* that disallowing
subclassing is somehow an important dimension of safety or preserving
API contracts, independent of overriding.  It isn't.

Demonstration: we don't make that argument about aggregation: you can't
prevent someone from making your public struct a stored property in a
type defined outside the module.  Judgements about programming style
aside, in the absence of overriding, subclassing and aggregation are
identical from an encapsulation point-of-view.

> The right to make the class final is reserved for the future.  Maybe
> this is the “nice point of control” you refer to and don’t find
> compelling?  I would prefer to have library authors acknowledge that
> they intend to allow subclasses and make that commitment explicit.

The question is, why?

> For me it isn’t about control as much as it is about making the API
> contract explicit and acknowledged.  I have wondered about the intent
> of library authors enough times to find this explicit statement in the
> language worthwhile.

Yeah, but we don't add language features to represent every possible
author intention, and there's a good argument that any intention that
can be violated without harm shouldn't be enforced.

> I also think language features enabled by knowing the whole class
> hierarchy will provide more value than “compositional subclasses” as
> long as we gain better support for composition elsewhere in the
> language.

I agree that there are better ways to solve the composition/API
forwarding problem.

>> The only reasons I can see for allowing people to prevent non-final
>> classes from being subclassed outside the module in which they are
>> defined are:
>> 
>> 1. It feels like a nice point of control to have.
>> 
>> 2. Marginal performance gains as noted in the proposal
>> 
>> I personally don't find these to be convincing.  #1 in particular seems
>> like a poor way to make language design decisions.  If we decide to add
>> this point of control, I'll justify it to myself in terms of #2.
>> 
>> P.S., I can live with either alternative; it's just important to me that
>> we understand the situation clearly when evaluating them.
>
> I agree with this.
>
>> 
>> HTH,
>> 
>> -- 
>> Dave
>> 
>> ___
>> 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

-- 
Dave

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

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Haravikk via swift-evolution]

> On 20 Jul 2016, at 20:54, Chris Lattner  wrote:
> 
> 
>> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 20 Jul 2016, at 14:55, Tino Heth <2...@gmx.de> wrote:
>>> 
>>> 
 Am 17.07.2016 um 18:31 schrieb Haravikk :
 
 I may move discussion of other collection types to its own section though, 
 to make the core proposal as simple as possible, and leave it up to the 
 core team whether to do that part.
>>> imho this is a good idea: Its increased power is a major argument for the 
>>> proposal, but the schedule seems to be very tight already… and I guess the 
>>> discussion about possible problems caused by variadic functions which can 
>>> be called with an explicit collection could be a real distraction, whereas 
>>> the basic idea is so clear that there shouldn't be any valid reasons to not 
>>> accept it.
>> 
>> I've created a new pull request for this, you can view the updated file here:
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
>> 
>> Hopefully it's still clear; I know I have a nasty tendency to be overly 
>> verbose with wording and stuff, though the first example should keep the 
>> meat of the proposal straightforward =)
> 
> I’m sorry I’m late to this thread, but I’m personally strongly opposed to 
> this.

I'm similarly late to your reply since somehow I missed it ;)

> The problem being solved here is so minor that I don’t see a reason to make a 
> change.

Which problem are you referring to exactly? The core issue of the proposal is 
to eliminate an unnecessary custom syntax and use regular function 
declarations, but the proposal also extends further than that as detailed in 
the advantages section; firstly it also opens passing of arrays to variadic 
functions, which seems to be fairly desired despite no proposal that I could 
find, but this proposal does so using a regular function definition rather than 
bolting on more custom behaviour to variadics. The proposal also details how 
the use of an attribute allows selection of any suitable type for handling the 
variadics, either to be introduced now or as a future feature, allowing any 
ArrayLiteralConvertible or any generic that can be satisfied by an Array to be 
used in an implementation, rather than requiring:

func someFunc(contentsOf:I) 
{ … }
func someFucn(_ values:Int…) { someFunc(contentsOf: values) }

You would just pop the @variadic attribute on the first version.

Again on the future feature front, if we were to get any new variadic features 
the use of an attribute should make them easier to add since they could be 
added as an attribute parameter. Not that I can think of any, but in future it 
would be easy to add say @variadic(min: 1) to set a minimum number of variadic 
parameters; not that I want this, it's just the only thing I can think of, but 
highlights that an attribute is more extensible.

So while the problem inspiring the proposal is relatively minor, the solution 
aims to solve the array passing issue too, while opening up other possibilities 
now or in future.

> Further, the proposed syntax is so heavy weight that it will adversely affect 
> readability of the API

Is it really so heavy-weight? Obviously it's a bit more effort than three dots, 
but it's also declaring an explicit type for your function, which it can also 
handle directly in addition to variadic calling.

In my experience the use of @noescape closures is much, much more common than 
variadics, yet no-one seems that desperate to introduce a custom syntax just to 
make them more lightweight to declare. In fact I could probably count the 
number of variadic functions I've seen or used in Swift on one hand, but I use 
and benefit from @noescape daily without ever feeling the attribute has been a 
burden to declare. This is after all a declaration-site change, anyone actually 
using variadics shouldn't notice much of a difference except where the 
ambiguity issue strikes, but then that's a problem for any array-passing 
extension to variadics I think.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, John McCall  wrote:

>> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
>>  wrote:
>> on Thu Jul 21 2016, Matthew Johnson
>> > >
>
>> wrote:
>> 
* What is your evaluation of the proposal?
>>> 
>>> +1 to the first design.  I think this is a great solution that
>>> balances the many considerations that have been raised on all sides of
>>> this issue.  `open` is 2 characters shorter than `public` so
>>> complaints about boilerplate are no longer valid.  `internal` is the
>>> “default” - neither `public` nor `open` are privileged as a “default”
>>> for publishing API outside of a module.
>>> 
>>> I am interested in language enhancements such as exhaustive pattern
>>> matching on classes and protocols which rely on knowledge of the full
>>> class hierarchy.  Such enhancements will be far more useful if the
>>> language supports non-open, non-final classes.
>>> 
>>> There are design techniques that would require additional boilerplate
>>> if we cannot have non-open, non-final classes.
>>> 
>>> Most importantly, requiring library authors to choose `public` or
>>> `open` provides important documentation value.  Users of the library
>>> will know whether the author intends to support subclasses or not.
>> 
>> I think this reasoning is flawed.
>> 
>> If you make any methods overridable outside your module (“open”),
>> obviously you mean to allow subclassing outside the module.  If you have
>> no open methods, there's absolutely nothing you need to do to “support
>> subclasses,” and from a design point-of-view, there's no reason to
>> restrict people from subclassing.
>
> Superclasses can have superclasses, which can themselves have open methods.
> This is, in fact, quite common for Cocoa programmers.

Okay, good point.

Making a class non-subclassable seems like a pretty indirect way to say
“not even inherited methods should be overridden outside the defining
module,” though.  

Wouldn't we prefer to have a way to hide the inheritance relationship
(and thus prevent overriding of inherited methods) outside the module?
Or are these independently useful axes?

>
>
> John.
>
>> 
>> The only reasons I can see for allowing people to prevent non-final
>> classes from being subclassed outside the module in which they are
>> defined are:
>> 
>> 1. It feels like a nice point of control to have.
>> 
>> 2. Marginal performance gains as noted in the proposal
>> 
>> I personally don't find these to be convincing.  #1 in particular seems
>> like a poor way to make language design decisions.  If we decide to add
>> this point of control, I'll justify it to myself in terms of #2.
>> 
>> P.S., I can live with either alternative; it's just important to me that
>> we understand the situation clearly when evaluating them.
>> 
>> HTH,
>> 
>> -- 
>> Dave
>> 
>> ___
>> 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
>

-- 
Dave

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

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Jose Cheyo Jimenez via swift-evolution]

>   * What is your evaluation of the proposal?
+1 as before but for the first implementation. 

I want to like implementation 2 but I really don’t see the need for it because 
extensions. 

The only reason for 2 is if the core team thinks that we will never get stored 
properties can be added via extensions. 


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

yes

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

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
n/1
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
reviewed the last two iterations. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Karl via swift-evolution]

> On 21 Jul 2016, at 20:49, Chris Lattner  wrote:
> 
> On Jul 21, 2016, at 8:56 AM, Karl  wrote:
>> 
>> Just posted in the Review #2 thread. I read the updated proposal, and I have 
>> another idea besides making “final” default:
> 
> Hi Karl,
> 
> Please respond to proposal on this thread with your evaluation of it.  This 
> isn’t the right place to make counterproposals.
> 
> -Chris

-1 from me. Same reasons as before, I think:

First proposal:
- Conflation of ‘public’ and ‘open’; it feels like open is a new higher access 
level, like getting married, or going sudo or something. If this proposal was 
accepted, ‘open' should substitute ‘public’, and never be alongside it (the 
same way “public private class” makes no sense)

- The concept of classes/class members which are closed until ‘open’ed is a 
powerful one for documenting classes and writing locally-reasonable code. It 
shouldn’t be mixed up with exposure to external modules - we already have a 
concept to describe that; it’s called access levels and ‘public’. I’ve worked 
with horrible base-classes before with a mixture of internally overridden and 
non-overriden members, and I would have absolutely loved some compiler-enforced 
annotation in that case. It makes sure that people stick to the contracts for a 
class’ members, and that breaking them is something you need to think twice 
about.

Second proposal:
- I’m arguing for increased local reasoning for classes, this proposal wants to 
make more of the permissions implicit. I’m not a fan.
- Extra API can be added with extensions. Extra state is something we should 
look in to in general. Obj-C had associated objects; maybe we can do better 
with Swift.

Basically, if you consider that we would need an explicit keyword for the 
default, non-open state (lets say “sealed”) as we have for “internal” - whether 
or not it applies inside the module is the only difference between the first 
proposal and my counter-proposal.
We could make that change later, but I think we should go with the sound logic 
behind this idea, and go with the expectation of safety and local 
reasonability, and try to make it as consistent as possible from the start. We 
could loosen it up to only apply to ‘public’ members if too onerous (although 
my preference would be shorthands - “open-all” or something).

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

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

[Michael Peternell via swift-evolution]

> Am 21.07.2016 um 14:48 schrieb Tino Heth via swift-evolution 
> :
> 
> 
>> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution 
>> :
>> 
>> Oops missed sending to the list.
> it's quite easy to hit the wrong button — but actually, the first recipient 
> list was a better fit for the spirit of your motivation ;-)
> 
>> Swift 3 is going to break code - as you say - on gigantic scale already. All 
>> developers that switch to Swift 3 will have to upgrade all modules they have 
>> and any module developer will have to update their code for Swift 3. Does 
>> this potentially add additional work for a module developer? Yes (some will 
>> get hit harder then others)
> (hope there's at least general agreement on this…)
> 
>> but it will let them better reason and state their contract which can save 
>> effort longer term and improve maintainability.
>> Anyway this is about setting up a language and compiler supported way of 
>> allowing a module developer to more clearly state the API contract for their 
>> module while internally having greater freedom to design things as make 
>> sense. The defaults are being picked to favor being explicit about the 
>> contract which is a good thing for everyone.
> I had an intrinsic motivation for that reply — and this is not to stop 
> SE-0117, which, after all, has already been accepted.
> Driven by the same motivation, I'm answering your message as well:
> How can you know that anything is "a good thing for everyone"? I can accept a 
> decision that I consider wrong, but not that it is justified with false 
> assumptions (or even lies — seen all that).
> There is a huge group of developers who think that the new defaults are no 
> good thing, but absolutely terrible — and that is something supporters of 
> SE-0117 have to accept, even if such tolerance doesn't fit into their mindset.
> I'm not even such a big fan of subclassing, but I wholeheartedly oppose this 
> attitude of "we know what's best for everyone": If anyone had a proof that 
> the decision is superior, he could have saved us a whole big discussion… but 
> there is none, so as I advised to live with sealed-by-default, I advise the 
> other camp to be happy about it and stop fortune-telling.

Hmm, I think the conflict is explained well here, it was a very insightful read 
for me:
http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html
http://martinfowler.com/bliki/EnablingAttitude.html
http://martinfowler.com/bliki/DirectingAttitude.html
(I think someone has already posted the link on this list, but I cannot find it 
right now.)

Interestingly, what I seem to share with Steve Jobs is his "enabling attitude" 
;) This is also what I like about Objective-C, and the reason why I started 
making iPhone-apps at all. (In Swift there will never be something like 
RPC-mechanisms/NSConnection/KVO/NSProxy/Mocking-objects.) In case you are 
wondering: yes I use monkey patching occasionally.. about 2 times a year/5 
hours per year; not that it is such a big deal, but it feels good to have this 
extra power when I really need it (which is rare, but it happens.) I just hope 
that Objective-C will stay for some time and that I can continue to use it, and 
that I'm not forced to write code in Swift 3+. Because that may be the time 
when I just leave the Apple ecosystem and look for another job ;) I feel like 
there is no point in fighting against SE-0117 anymore, because Swift already is 
too far away from what I want it to be, and one other step in the "wrong" or 
"right" direction doesn't really make much difference for me. Although I like 
value types: Objective-C + Swift-structs + 
private(statically-dispatched/not-accidentally-overridable)methods + 
Swift-enums = perfect language for me.

Bye bye Swift.

-Michael

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

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Leonardo Pessoa via swift-evolution]

Matthew, I also thought that way but I think there is no harm in
allowing one to create a subclass if there are no open methods in it,
meaning there is no way a subclass can even replace an existing
implementation. Even if Swift were to allow creating a new method with
the same name of an existing superclass method the new method should
not respond for calls made using the superclass as base. This is
allowed in C# where you can have the following (*dusts off*):

   class A {
  public virtual void method() {
  Console.println("method in A");
  }
   }

   class B : A {
   public final void method() {
  Console.println("method in B");
  }
   }

   class C : B {
   public new void method() {
  Console.println("method in C");
   }
   }

   B b = new C();
   b.method(); // prints "method in B"
   C c = (C) b;
   c.method(); // prints "method in C"

I know I'm being a little flexible here given my previous messages to
this list but if we are to allow subclasses to be openly created,
subclasses will only be allowed to implement new interfaces and create
new methods but not mess with the base implementation unless a method
is explicitly open, there is no harm to the defined contract, so I see
no harm in this approach for composition.

And yes, contracts are about (at least some) control.

L


On 21 July 2016 at 15:08, Matthew Johnson via swift-evolution
 wrote:
>
>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>>
>>
>> on Thu Jul 21 2016, Matthew Johnson  wrote:
>>
 * What is your evaluation of the proposal?
>>>
>>> +1 to the first design.  I think this is a great solution that
>>> balances the many considerations that have been raised on all sides of
>>> this issue.  `open` is 2 characters shorter than `public` so
>>> complaints about boilerplate are no longer valid.  `internal` is the
>>> “default” - neither `public` nor `open` are privileged as a “default”
>>> for publishing API outside of a module.
>>>
>>> I am interested in language enhancements such as exhaustive pattern
>>> matching on classes and protocols which rely on knowledge of the full
>>> class hierarchy.  Such enhancements will be far more useful if the
>>> language supports non-open, non-final classes.
>>>
>>> There are design techniques that would require additional boilerplate
>>> if we cannot have non-open, non-final classes.
>>>
>>> Most importantly, requiring library authors to choose `public` or
>>> `open` provides important documentation value.  Users of the library
>>> will know whether the author intends to support subclasses or not.
>>
>> I think this reasoning is flawed.
>>
>> If you make any methods overridable outside your module (“open”),
>> obviously you mean to allow subclassing outside the module.  If you have
>> no open methods, there's absolutely nothing you need to do to “support
>> subclasses,” and from a design point-of-view, there's no reason to
>> restrict people from subclassing.
>
> I disagree.  As has been discussed when a class is not open the author does 
> not make a commitment to allow subclasses.  The right to make the class final 
> is reserved for the future.  Maybe this is the “nice point of control” you 
> refer to and don’t find compelling?  I would prefer to have library authors 
> acknowledge that they intend to allow subclasses and make that commitment 
> explicit.
>
> For me it isn’t about control as much as it is about making the API contract 
> explicit and acknowledged.  I have wondered about the intent of library 
> authors enough times to find this explicit statement in the language 
> worthwhile.
>
> I also think language features enabled by knowing the whole class hierarchy 
> will provide more value than “compositional subclasses” as long as we gain 
> better support for composition elsewhere in the language.
>
>>
>> The only reasons I can see for allowing people to prevent non-final
>> classes from being subclassed outside the module in which they are
>> defined are:
>>
>> 1. It feels like a nice point of control to have.
>>
>> 2. Marginal performance gains as noted in the proposal
>>
>> I personally don't find these to be convincing.  #1 in particular seems
>> like a poor way to make language design decisions.  If we decide to add
>> this point of control, I'll justify it to myself in terms of #2.
>>
>> P.S., I can live with either alternative; it's just important to me that
>> we understand the situation clearly when evaluating them.
>
> I agree with this.
>
>>
>> HTH,
>>
>> --
>> Dave
>>
>> ___
>> 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 #3] SE-0117: Allow distinguishing between public access and public overridability

[Leonardo Pessoa via swift-evolution]

On 21 July 2016 at 12:33, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access and 
> public overridability" begins now and runs through July 25. 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?

I like the design with open and have no issues with it implicitly
meaning public. After a little confabulation I also believe the
original intent can be achieved by allowing subclassing to be open and
method overriding to be sealed by default, thus providing ground for
composition with no replacing of behaviour as exemplified in the
proposal, so I have no issues with it as long as methods are sealed by
default.

As for the openness of overriden methods, I still believe there should
be a way other than final to reseal the method. Sure there are means
to implement the same without it but not as elegantly IMO.

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

No.

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

I've read the proposal and discussed the issue a lot on the threads.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] Updating the proposal template to prompt backward compatibility concerns

[Charlie Monroe via swift-evolution]

I agree that the concern of future proposals should be backward compatibility, 
though I personaly think that Swift 4 will be full of breaking changes anyway 
(not as many as Swift 3, but there will be quite a few). In that matter, I'm 
not sure that stressing backward compatibility is better than stressing better 
desing for the years to come.

> On Jul 21, 2016, at 6:05 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> With the end of Swift 3 drawing near, we'll need to start designing with an 
> eye toward backward compatibility. To that end, I think we should update the 
> "Impact on existing code" proposal template to start asking writers to 
> consider backward compatibility concerns. Here's some draft verbage to that 
> effect:
> 
> https://github.com/jckarter/swift-evolution/blob/4bdd1b875a8402ec6bbabb3f37151262f130af2b/-template.md#backward-compatibility
> 
> Any concerns, revisions, or objections?
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Charlie Monroe via swift-evolution]

> On Jul 21, 2016, at 5:46 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> 
>> 
>> There are many empty strings in that string. In fact, there are infinite 
>> empty strings between each character, before the string, and after the 
>> string. Observe:
>> 
>> "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
>> "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
>> "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
>> "" + "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the 
>> Galaxy 42"
>> etc, and I didn't even get past the first character!
>> 
> 
> Wel, maybe I am not intelligent enough to comprehend that,
> or maybe it’s just a matter of definition/convention..
>  
> Again, to me a string is ***just a row of characters***. 

In which case it should be even more confusing to you:

let str = "Hello"
str.characters.starts(with: "".characters) // true
str.hasPrefix("") // false

> 
> therefore, concatenating empty strings (that do not contain any characters)  
> with other strings have no effect: . 
> for example: 
> 
>let res = "" + "" + "" + "" + “The Art Of Learning To Fly”
> 
> after that: 
>   
>  res == “The Art Of Learning To Fly”
> 
> and:
> 
>  res.count == “The Art Of Learning To Fly”.count
> 
> Regardless what in many  other programming languages  is done;
> I prefer the Objective jC NSString hasPrefix(“") way of handling this,
> which always returns False,e because a row of characters
> is contiguous, without empty “” in between, leading or trailing.  
> 
> However, we don’t seem to share the same opinion, about this sorry. 
> nothing more to say about that, I guess.
> 
> TedvG
> 
> 
> 
>>> On Jul 20, 2016, at 6:49 PM, Ted F.A. van Gaalen via swift-evolution 
>>> > wrote:
>>> 
>>> Don’t Panic !
>>> 
>>> At the risk of seeing things in a somewhat trivial perspective,
>>> combined with an almost complete absence of abstraction:
>>> 
>>> Note that to relatively simple persons like me: 
>>> 
>>> String instances are just rows of characters (when not empty, of course) 
>>> 
>>> There are only two kinds of Strings:
>>> 
>>> 1. empty Strings, which do not contain amy characters at all
>>> 
>>>   and 
>>> 
>>> 2.  Strings containing 1 or more characters.
>>> 
>>> Ergo ad Infinitum :
>>> 
>>> Empty Strings do not occur in Strings that contain characters. 
>>> 
>>> 
>>> I’d say, please try to find possible empty strings
>>> that might perhaps be embedded e.g. in the string below: 
>>>  
>>> “Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42” 
>>> 
>>> 
>>> With all due respect: 
>>> This might void the discussion below :o)
>>> 
>>> I have nothing against Mathematics as long
>>> as it is applicable.
>>> 
>>> 
>>> Kind Regards
>>> Ted
>>> 
>>> 
>>> 
 To the question of whether any given string has the empty string as prefix:
 yes it does. This is a correct answer, and returning true is a correct
 behaviour.
 
 To the question of how many times the empty string occurs in a string: yes,
 this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" + "" + "" +
 "" == "a" + "" + "" + "" + "" == ... etc.. Concatenating an empty string,
 like adding zero or multiplying by zero for a numerical value, can be done
 infinitely many times without making a difference.
 
 However, there's correctness and convenience. For example, every integer
 can be expressed as a multiple of prime factors. 1 is technically a prime
 number - it's divisible by 1 and itself - but for convenience we say it
 isn't a prime number, because if it isn't, every integer can be expressed
 uniquely as a multiple of prime factors, whereas if it is, there are an
 infinite number of such expressions for each integer.
 
 There may be many algorithms which rely on an empty prefix returning false.
 If hasPrefix and hasSuffix are corrected, those algorithms should be
 altered to recognise that correction. For example, if breaking up a string
 using the empty string as a separator, it seems sensible that the sequence
 of substrings would never contain consecutive empty strings.
 
 On Wed, Jul 20, 2016 at 11:58 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org > wrote:
 
> I'd run this by someone who actually knows math, but afaik there are
> finitely many empty strings in any given string.
> 
> How many e's are in any given string? (Ignoring Unicode issues for now,)
> for each index in the string's indices, form a substring one character in
> length starting at that index and compare the value of that substring to 
> e.
> 
> How many empty strings are in any given string? For each index in the
> string's indices, form a substring zero characters in length 

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Chris Lattner via swift-evolution]

On Jul 21, 2016, at 8:56 AM, Karl  wrote:
> 
> Just posted in the Review #2 thread. I read the updated proposal, and I have 
> another idea besides making “final” default:

Hi Karl,

Please respond to proposal on this thread with your evaluation of it.  This 
isn’t the right place to make counterproposals.

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

Re: [swift-evolution] Returning nothing

[Chris Lattner via swift-evolution]

On Jul 21, 2016, at 9:42 AM, Daniel Steinberg via swift-evolution 
 wrote:
>  given that one of Swift’s design principles is … for APIs to read like 
> English phrases,

This isn’t a goal of Swift.  The goal is to provide clarity at point of use, 
and many other things:
https://swift.org/documentation/api-design-guidelines/

I don’t see any advantage to renaming Void, particularly given that almost no 
one writes Void for first-order functions.

-Chris

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

Re: [swift-evolution] [Proposal] Variadics as Attribute

[Chris Lattner via swift-evolution]

> On Jul 21, 2016, at 3:13 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> Am 20.07.2016 um 21:54 schrieb Chris Lattner :
>> 
>> I’m sorry I’m late to this thread, but I’m personally strongly opposed to 
>> this.
> May I ask a general question:
> What implications does this statement have? Is it "spare yourself from 
> unnecessary work, this will never be accepted", or "prepare yourself for a 
> hard review”?

It is hard to say, but it could definitely be either of those.  In any case, 
we’re moving more to a model that proposals need to have fairly strong 
community support before merging them.  This is because we’ve had a number of 
proposals getting rejected recently, ones that were “obviously” not going to 
happen.

That said, I specifically worded it that way so that you know it was my person 
feeling, not the measured opinion of the core team or anyone else.  My opinion 
is shaped by many things, including a significant amount of thinking about the 
shape of Swift as it is today, along with the tradeoffs involved in adding and 
removing things.  That said, the community sentiment and other core team member 
opinions frequently change my position on things, so it’s not some invariant - 
a well developed and very compelling argument is always important for a 
successful proposal.

-Chris

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

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

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md

The review of "SE-0119: Remove access modifiers from extensions" ran from July 
12...19. The proposal has been *rejected*.

The majority of the feedback on this proposal was opposed to it, because it 
eliminated the useful ability to apply access control to a batch of methods and 
properties.

Thank you to Adrian Zubarev for raising this proposal,

-Chris Lattner
Review Manager

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

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Nevin Brackett-Rozinsky via swift-evolution]

>
> *What is your evaluation of the proposal?*


Strong +1 to either design, and neutral between them.

In the prior review I advocated that `open` should *only* apply to classes,
not members. This new proposal turns that on its head and is *vastly
superior*. Tagging open members with *just* the word `open`, eliding
`public` entirely, is a phenomenal improvement.

Kudos to the core team both for crafting this solution, and more
importantly for conducting the (lengthy!) review process with such aplomb.
It would have been easy (and tempting!) to end the first review by
“accepting with revision”, leaving us with needless boilerplate and a
suboptimal design. By instead inviting the community to bikeshed a second
time *with the constraint that `sealed` would be the default*, and then
meeting afterward to thoroughly discuss the possibilities, the core team
has truly demonstrated how an *ahem* open, public design process ought to
be carried out.


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


Honestly I am not in a position to say.


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


Well, the one aspect I am not sure about is, “A class member that overrides
an open class member must be explicitly declared open unless it is
explicitly final or it is a member of a final or non-public class. In any
case, it is considered open.”

This seems like an unnecessary restriction. Perhaps I want to override an
`open` member with a `public` one. As in,

open class Base { open var x: Int { return 6 } }
open class Sub: Base { public var x: Int { return 7 } }
open class Grand: Sub { final var x: Int { return 8 } }

Note that “Sub” might be defined in a separate module from “Base”, a module
that wants to publish Sub and Grand without letting its own clients
override `x` from them.


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


Only languages with run-of-the-mill access control, nothing like this!


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


I read all messages in the previous draft and review threads, and the
entire new proposal except for the 8-paragraph, 886-word “Motivation”
section. Seriously, that is 3½ pages of motivation!

Nevin


On Thu, Jul 21, 2016 at 11:33 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access
> and public overridability" begins now and runs through July 25. 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?
> * 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] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

[Joe Groff via swift-evolution]

> On Jul 21, 2016, at 10:02 AM, Michael Gottesman via swift-evolution 
>  wrote:
> 
> Hello everyone.
> 
> This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore 
> to the Objective C overlay. The reason to do this is that ideally StdlibCore 
> would not have any code specific to ObjC in it. This is a small step that we 
> can take in this direction by moving the public API of 
> AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this 
> would be done is that the implementation for 
> AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would 
> add an underscore to make that API private to the standard library. Then 
> inside the ObjC overlay, we would create a typealias to the internal API with 
> the non-underscored name (i.e. make the typealias the public API). Then at a 
> later point in time we can move the implementation. The reason why I am not 
> proposing to move the implementation today is that there are dependencies in 
> Array/Hashed Collections on AutoreleasingUnsafeMutablePointer. Moving that 
> code is a larger project that is preconditioned on this proposal going in 
> first as an incremental step.
> 
> Thoughts, flames, etc?

Sounds awesome. Someone will need to ping Bret Victor to update his T-shirt: 
https://twitter.com/worrydream/status/55853312645697

-Joe

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

Re: [swift-evolution] [Meta] Proposal status page

[Jordan Rose via swift-evolution]

> On Jul 18, 2016, at 16:57, Mark Lacey via swift-evolution 
>  wrote:
> 
>> 
>> On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> This is now live:  http://apple.github.io/swift-evolution/ 
>> 
> Very very nice!
> 
> I wonder if we should do something to avoid the 404 here though: 
> http://apple.github.io 
> 
> Perhaps a redirect to https://github.com/apple/swift 
>  or maybe directly to 
> https://github.com/apple/swift/blob/master/README.md? 
> 
The Swift Open Source project isn’t the only project under github.com/apple. 
Any landing page here would have to come from Apple PR.

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

Re: [swift-evolution] Returning nothing

[Matthew Johnson via swift-evolution]

> On Jul 21, 2016, at 12:51 PM, Haravikk  wrote:
> 
> 
>> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution 
>>  wrote:
>>> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
>>>  wrote:
>>> 
>>> This may be a silly question - given that one of Swift’s design principles 
>>> is to be a language for new programmers and for APIs to read like English 
>>> phrases, should we replace the typealias of Void for the return type () 
>>> with Nothing.
>> 
>> Nothing was one of the names considered for the bottom type that replaces 
>> @noreturn 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
>>  I think it would be confusing to rename Void to Nothing.
> 
> I think on that issue the favourite for replacing @noreturn is Never or 
> NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it 
> doesn't return in the first place), so Nothing is actually okay in that 
> regard.

Yes, Never won that debate.  But Nothing was considered and does imply “bottom 
type” to many people.  That is why I don’t think it is a good choice here.

> 
> I wouldn't mind the change of name, as void to me suggests something like a 
> yawning abyss, which implies a substantive gap, rather than an actual absence 
> of something, whereas Nothing is a bit clearer. That said I've never had any 
> real trouble with Void, but can see Nothing being a tad easier to teach.
> 
> It's also not necessarily a very disruptive change, as many people don't 
> write -> Void and just omit it, though personally I prefer to always write it 
> out explicitly.

Agree.  I’m neutral on changing it.  I just think Nothing is the wrong name.  I 
would advocate Unit if we’re going to change it.  Both Unit and Void have 
precedence in other languages.  The precedence for Nothing in other languages 
is “bottom type” which means it is going to be a confusing choice.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
I think the philosophical direction of the proposal is good, though I still 
don’t like the actual implementation details. There are two concepts here:
the ability to subclass
the ability to override members

Having both of these concepts annotated with `open` is confusing as they do 
different things. Marking a class as open does **not** provide the ability to 
override. However, marking a member as `open` would provide the ability to 
override. These are two related but different concepts.

I see no reason why `virtual` should not be used to mark members that are 
inheritable and overridable. That concept is what is taught in schools, that 
concept is what is easily searchable, and that term is well known in the 
computer science field for this very concept. Just do a Google search between 
“open function” and “virtual function”. Deviating from this seems to be counter 
to one of Swift goals of being approachable. Having to learn `open` here is 
just mental noise that makes the coder have to think, “right… this is just a 
virtual method”.

To me, the better approach is:
change `open` to `virtual`
`virtual` is only allowed on inheritable and overridable members (i.e. `var`, 
`func`, and `subscript`)
`virtual` is not permitted on declarations that are explicitly `final` or 
`dynamic`. (Note that it's okay if one or both of the modifiers are implicitly 
inferred.)
A class is made inheritable outside of the module the **only** when the class 
is marked as both `public` and one or members are marked as `virtual` 

Lastly, it’s almost certainly a bug in your code if you mark a member as `open` 
on your public class but forget to annotate your class also with `open`. Worse, 
this error will **only** be caught if you attempt to use this type **outside** 
the context of tests because `@testable` will grant your module the `open` 
class state because `@testable` is special.

The only scenario that this change doesn’t allow would be the ability to 
subclass a class that has no virtual members. In my opinion, this scenario is 
better handled via extensions anyway.

However, **if** this scenario really was desirable, this could later be added 
by allowing `virtual` (or `inheritable` or `open`...) on a class definition. 
However, I would still make the argument that once you have a `virtual` member 
on a type, that the class is implicitly marked as `virtual` as well (see 
reasoning above).

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

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

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes, many. This proposal’s philosophical direction is more resilient by default.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve read the posts, thought about it, experimented, blogged about it.

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

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, Matthew Johnson  wrote:

>>  * What is your evaluation of the proposal?
>
> +1 to the first design.  I think this is a great solution that
> balances the many considerations that have been raised on all sides of
> this issue.  `open` is 2 characters shorter than `public` so
> complaints about boilerplate are no longer valid.  `internal` is the
> “default” - neither `public` nor `open` are privileged as a “default”
> for publishing API outside of a module.
>
> I am interested in language enhancements such as exhaustive pattern
> matching on classes and protocols which rely on knowledge of the full
> class hierarchy.  Such enhancements will be far more useful if the
> language supports non-open, non-final classes.
>
> There are design techniques that would require additional boilerplate
> if we cannot have non-open, non-final classes.
>
> Most importantly, requiring library authors to choose `public` or
> `open` provides important documentation value.  Users of the library
> will know whether the author intends to support subclasses or not.

I think this reasoning is flawed.

If you make any methods overridable outside your module (“open”),
obviously you mean to allow subclassing outside the module.  If you have
no open methods, there's absolutely nothing you need to do to “support
subclasses,” and from a design point-of-view, there's no reason to
restrict people from subclassing.

The only reasons I can see for allowing people to prevent non-final
classes from being subclassed outside the module in which they are
defined are:

1. It feels like a nice point of control to have.

2. Marginal performance gains as noted in the proposal

I personally don't find these to be convincing.  #1 in particular seems
like a poor way to make language design decisions.  If we decide to add
this point of control, I'll justify it to myself in terms of #2.

P.S., I can live with either alternative; it's just important to me that
we understand the situation clearly when evaluating them.

HTH,

-- 
Dave

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

Re: [swift-evolution] Returning nothing

[Haravikk via swift-evolution]

> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution 
>  wrote:
>> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
>>  wrote:
>> 
>> This may be a silly question - given that one of Swift’s design principles 
>> is to be a language for new programmers and for APIs to read like English 
>> phrases, should we replace the typealias of Void for the return type () with 
>> Nothing.
> 
> Nothing was one of the names considered for the bottom type that replaces 
> @noreturn 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
>  I think it would be confusing to rename Void to Nothing.

I think on that issue the favourite for replacing @noreturn is Never or 
NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it 
doesn't return in the first place), so Nothing is actually okay in that regard.

I wouldn't mind the change of name, as void to me suggests something like a 
yawning abyss, which implies a substantive gap, rather than an actual absence 
of something, whereas Nothing is a bit clearer. That said I've never had any 
real trouble with Void, but can see Nothing being a tad easier to teach.

It's also not necessarily a very disruptive change, as many people don't write 
-> Void and just omit it, though personally I prefer to always write it out 
explicitly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Vladimir.S via swift-evolution]

On 21.07.2016 18:33, Chris Lattner via swift-evolution wrote:

Hello Swift community,

The third review of "SE-0117: Allow distinguishing between public access and public 
overridability" begins now and runs through July 25. The proposal is available here:


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


+1 for *second* approach because :

* Simple mental model. It is adding `open` keyword for methods only. It is 
very easy to understand/remember just one *new* rule : only `open` 
methods/props could be overridden outside of the module. Easy to describe 
this to anyone new in Swift.
* More flexible. You still can subclass the `public` class. But you can't 
"hurt" the logic inside the module while you can have additional state and 
methods in new class for your own logic. So IMO second approach fixes the 
exact reason why we have this proposal *without* adding unnecessary 
limitations and additional complexity.
* As I understand, for second approach there is no this IMO strange 
limitation : "The superclass of an open class must be open." (while yes, 
this still exists: "The overridden declaration of an open override must be 
open.")
* I feel this approach more Swifty - free to subclass if you want for your 
logic but safe for internal module's logic.
* 'open class' adds complexity to access model, given we already have 
public, internal, private, fileprivate
* Second approach unifies the syntax : structs and classes will have the 
same syntax for public declaration (only difference : classes can have 
'open' for methods/props)




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?
* 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] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, Michael Gottesman  wrote:

> Hello everyone.
>
> This is a proposal to move AutoreleasingUnsafeMutablePointer from
> StdlibCore to the Objective C overlay. The reason to do this is that
> ideally StdlibCore would not have any code specific to ObjC in
> it. This is a small step that we can take in this direction by moving
> the public API of AutoreleasingUnsafeMutablePointer to the ObjC
> overlay. 

+1

To avoid confusion among reviewers, I feel I need to point out that
everything below this point is implementation detail that IMO has no
relevance to the evolution list.

> The way that this would be done is that the implementation
> for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but
> we would add an underscore to make that API private to the standard
> library. Then inside the ObjC overlay, we would create a typealias to
> the internal API with the non-underscored name (i.e. make the
> typealias the public API). Then at a later point in time we can move
> the implementation. The reason why I am not proposing to move the
> implementation today is that there are dependencies in Array/Hashed
> Collections on AutoreleasingUnsafeMutablePointer. Moving that code is
> a larger project that is preconditioned on this proposal going in
> first as an incremental step.

I am not confident that we will ever be able to move that code, but as I
said before, that's really irrelevant here.  Let's do it!

-- 
Dave

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

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Félix Cloutier via swift-evolution]

 You probably know this better than me: will the compiler always recognize that 
what came from "#import/#include " (not @import Cocoa) is the 
same as what comes from Swift's "import Cocoa"? What about non-module includes?
Are we saying that you can always re-import a module and the last import wins, 
or is that a special case for symbols that come from a C header instead of 
Swift code?
Félix

On Thursday, July 21, 2016 9:36 AM, Robert Widmann  
wrote:


import Cocoa hiding (NSWindow)
Done.  This specific case is one of the reasons why imports are file-local.


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

Re: [swift-evolution] [Proposal] Replace String.init(repeating repeatedValue: Character, count: Int) and String.init(repeating repeatedValue: UnicodeScalar, count: Int) by String.init(repeating repeat

[Dave Abrahams via swift-evolution]

on Thu Jul 21 2016, Roman Levenstein  wrote:

> Hi,
>
> I’d like to propose some improvements for String initializers and
> String.append methods. It is addressing
> https://bugs.swift.org/browse/SR-1964
>  (rdar://problem/17028332
> ).

+1; let's do it!

>
> # Replace String.init(repeating repeatedValue: Character, count: Int) and 
> String.init(repeating repeatedValue: UnicodeScalar, count: Int) by 
> String.init(repeating repeatedValue: String, count: Int)
>
> * Proposal:
> * Author: [Roman Levenstein](http://github.com/swiftix)
> * Status: 
> * Review manager:
>
> Introduction
> =
>
> This proposal suggest replacing String initializers taking Character or 
> UnicodeScalar as a repeating value by a more general initializer that takes a 
> String as a repeating value. This is done to avoid the ambiguities in the 
> current String API, which can be only resolved by explicit casting. It is 
> also proposed to remove one of the String.append APIs to match these changes.
>
> All user-facing Swift APIs must go through Swift Evolution. While this is a 
> relatively simple API change with an existing implementation, this formal 
> proposal provides a paper trail as is normal and usual for this process.
>
> Motivation
> 
>
> This change introduces a non-ambiguous API for constructing Strings. With the 
> set of String initializers available today, ones often needs to explicitly 
> cast the repeating value literal to disambiguate what initializer is meant to 
> be used. 
>
> An example of the ambiguity:
>
>> let x = String(repeating:"0", count: 10) 
> error: repl.swift:29:9: error: ambiguous use of 'init(repeating:count:)'
> let x = String(repeating:"0", count: 10)
> ^
>
> Swift.String:11:12: note: found this candidate
> public init(repeating repeatedValue: Character, count: Int)
>^
>
> Swift.String:21:12: note: found this candidate
> public init(repeating repeatedValue: UnicodeScalar, count: Int)
>^
>
> To disambiguate, one currently needs to write something like:
> `let zeroes = String(repeating: "0" as Character, count: 10)` or 
> `let zeroes = String(repeating: "0" as UnicodeScalar, count: 10)`
>
> Detailed Design
> 
>
> This update affects `String`.
>
> It is proposed to replace the following ambiguous API:
> *  `public init(repeating repeatedValue: Character, count: Int)`
> *  `public init(repeating repeatedValue: UnicodeScalar, count: Int)`
>
> by the following, more powerful API:
> *  `public init(repeating repeatedValue: String, count: Int)`
>
> To match this change, it is also proposed to remove the following 
> String.append API:
> *  `public mutating func append(_ x: UnicodeScalar)`
> because there is already an existing and more powerful API:
> *  `public mutating func append(_ other: String)`
>
> Impact on Existing Code
> ===
>
> Existing third party code using these to be removed String APIs will need 
> migration.
> A fixit could be provided to automate this migration.
>
> Alternatives Considered
> ==
>
> Not Applicable
>
> -Roman
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave

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

Re: [swift-evolution] Fixing the confusion between non-mutating algorithms and single-pass sequences

[Dave Abrahams via swift-evolution]

on Wed Jul 20 2016, Jonathan Hull  wrote:

>> On Jul 20, 2016, at 3:30 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed Jul 20 2016, Dave Abrahams  wrote:
>> 
>
>>> on Wed Jul 20 2016, Jonathan Hull  wrote:
>>> 
 Basically, I added back in a super-minimal protocol to fill the
 structural gap left by Sequence.  I call it “IteratorProvider” and it
 only has a single function which vends an iterator.  Collection
 adheres to this, and Iterator adheres to it by returning itself.  All
 of the other methods from Sequence remain on Iterator.  Thus anyone
 
 with API that only needs a single pass would take a IteratorProvider
 and then work on the iterator it provides.
>>> 
>>> That leaves us back where we are now: people will see that
>>> IteratorProvider is a simple, universal protocol for both single-and
>>> multi-pass sequences, write algorithm libraries that depend on
>>> multi-pass-ness, and test them with the most prevalent examples, which
>>> happen to be multi pass.
>> 
>> Let me make a quick counter-argument, because I thought about it a
>> bit, and I don’t think it does have the same problem (especially with
>> careful/better naming).
>> 
>> The difference is that the ONLY method on IteratorProvider is the one
>> to get an iterator.  There is no map, filter, sort, first, count, etc…
>> just a way to get a single-pass iterator.  This changes the mindset
>> when using it.  You are aware that you are getting a single-pass
>> iterator.
> 
> Maybe.  What's to stop people from extending IteratorProvider?
 
 Nothing.  But that is true of any protocol.  I am ok with individual's
 extensions.  They would have to use that single method to build up
 from anyway, so presumably they would have to consider the single pass
 case in their extensions...
 
>> True, people might try to get the iterator a second time, but we can
>> make the iteratorProvider method optional (and trying to get an
>> iterator from an iterator which is spent would return nil) 
>> and then they are forced to deal with the case where it was
>> single-pass.
> 
> Now you can't loop over the same array multiple times.
 I must be missing something.  Isn’t that the point?
>>> 
>>> No.  Arrays are multipass.
>>> 
 I mean, your version is called “IterableOnce”.  Why do you want to
 iterate on IterableOnce more than once?  
>>> 
>>> Because it happens to be multipass.
>>> 
 The point (at least in my mind) is to provide a common interface for
 things that we want to iterate over a single time.  If you want to
 iterate multiple times, use collection’s interface where you are
 guaranteed multi-pass.
>>> 
>>> for ... in uses Iterators.
>>> 
 That said, you actually can loop multiple times for collections by
 getting a new iterator from the provider (which could point to the
 same array storage).  The optional just forces you to check for the
 single-pass case.
>>> 
>>> Oh, I'm sorry; I didn't realize you were saying that only single-pass
>>> IteratorProviders would ever return nil from their methods.
>> 
>> Note: any IteratorProvider that could return nil would have to be a
>> class (or wrap a class) in order to bypass mutability restrictions,
>> since we can't allow the method that provides the iterator to be
>> mutating.
>
> That is a good point.  I think I am ok with it, since in my mind this
> is already true of non-clonable Iterators anyway.  If you recall, in
> my original proposal I wanted to make iterators reference types. That
> was rejected for performance reasons, but I still think that
> non-clonable Iterators will at least need to wrap a reference type
> somewhere (or they will be subject to the issue you are talking about
> above).
>
> Note: In the current system, it is common to create sequences, but
> under my proposal it would be rare to create an IteratorProvider that
> wasn’t also an Iterator or Collection, since Iterator and Collection
> would both have default implementations satisfying IteratorProvider,
> and IteratorProvider doesn’t have any useful methods besides the one
> providing an Iterator.

Suggestion: Realistically, I see no possibility that this idea can be
completely designed, reviewed, approved, and implemented in time for
Swift 3, so let's take this up after Swift 3 ships.  Yes, it's a
breaking change, but there *will* be some of those going forward.
Obviously, if you disagree, feel free to pursue it now, but—even though
I'm very interested in this topic—I don't
think I have the time budget to participate at the moment.

Regardless, the best proof-of-concept would be to implement it and
create a pull request against Swift that demonstrates how it works and
passes tests, and that can be worked on by anybody at any time.  That's
also the only thing I can 

Re: [swift-evolution] Returning nothing

[Matthew Johnson via swift-evolution]

> On Jul 21, 2016, at 11:59 AM, Xiaodi Wu  wrote:
> 
> Quite frankly, I think the ship has long sailed for renaming Void.

Agree.  I’m not advocating change, just stating things that should be 
considered if anyone wants to propose it.

> 
> 
> On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
> > > wrote:
> >
> > This may be a silly question - given that one of Swift’s design principles 
> > is to be a language for new programmers and for APIs to read like English 
> > phrases, should we replace the typealias of Void for the return type () 
> > with Nothing.
> 
> Nothing was one of the names considered for the bottom type that replaces 
> @noreturn 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>  
> ).
>  I think it would be confusing to rename Void to Nothing.
> 
> If we consider renaming it Unit is the obvious way to go 
> (https://en.m.wikipedia.org/wiki/Unit_type 
> )
> 
> >
> > So
> >
> > f: ( input: Int) -> Void
> >
> > becomes
> >
> > f: ( input: Int) -> Nothing
> >
> > Instead of saying “f takes an Int and returns a Void” I read this as “f 
> > takes an Int and returns nothing”.
> >
> > I’ve been using f:(input: Int) -> () because it’s easier to explain than 
> > Void to non-experienced programmers. Experienced programmers have no 
> > problem with Void. But Void seems to be something we’re using just because 
> > we have for a while - like x++ and C-style for loops.
> >
> > Best,
> >
> > Daniel
> > ___
> > 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] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Matthew Johnson via swift-evolution]

>   * What is your evaluation of the proposal?

+1 to the first design.  I think this is a great solution that balances the 
many considerations that have been raised on all sides of this issue.  `open` 
is 2 characters shorter than `public` so complaints about boilerplate are no 
longer valid.  `internal` is the “default” - neither `public` nor `open` are 
privileged as a “default” for publishing API outside of a module.  

I am interested in language enhancements such as exhaustive pattern matching on 
classes and protocols which rely on knowledge of the full class hierarchy.  
Such enhancements will be far more useful if the language supports non-open, 
non-final classes.

There are design techniques that would require additional boilerplate if we 
cannot have non-open, non-final classes.  

Most importantly, requiring library authors to choose `public` or `open` 
provides important documentation value.  Users of the library will know whether 
the author intends to support subclasses or not.  The second design requires 
the use of comments and / or documentation to communicate this information.  I 
prefer important semantic considerations like this to be encoded in the 
language itself.

I would prefer to see better language support for composition to support 
compositional subclasses rather than choosing the second design here.  Language 
support for composition could be designed to work with structs as well as 
classes and would encourage the use of protocols rather than class hierarchies 
for polymorphism.  This feels like a much Swiftier direction to me.

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

Yes.  Library authors are currently locked into “open” designs unless they are 
able to make the design `final` and remember to do so in the initial release.

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

Very much so.  It seeks an optimal middle ground that keeps boilerplate to a 
minimum while providing explicit API contracts.

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

The closest is the requirement to mark methods as `virtual` in C++ and C#.  
This solution is superior in a number of ways.  A couple of items come to mind 
immediately:

1. It avoids boilerplate within a module allowing for easy rapid prototyping 
and evolution of a design within a module.
2. It requires an explicit choice to be made when publishing an API which means 
that a library author can’t accidentally “forget” to include the `open` 
modifier if that is their intent.

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

In-depth participation in many of the discussion threads and the initial review 
thread as well as in-depth study of all relevant proposals.

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

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 21, 2016, at 4:59 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hello Brent, thank you for your feedback on the review process of our 
> proposal.
> 
> I think this proposal is a huge mess. I don’t understand why the split 
> between Type and Metatype exists. I think Mirror seems half-baked; it ought 
> to be omitted entirely until we can actually design a reflection system.
> The reason why we took Mirror here, is because there can be metatypes that 
> pretend to reflect T where the actual metatype could reflect U with 
> relationship like U : T:
> 
> class Superclass {}
> class Subclass : Superclass {}
> 
> let hidden: Any = Subclass()
> let dynamicMetatype = hidden.dynamicType // Any.Type
> dynamicMetatype as? Any.Type  //=> NOT nil
> dynamicMetatype as? Superclass.Type   //=> NOT nil
> dynamicMetatype as? Subclass.Type //=> NOT nil
> That is the reason why a standalone non-generic type was needed to solve the 
> problem with the ‘current’ Swift.
> 
> And I can’t even tell if these are actual problems. It’s possible that the 
> design is just fine, but the proposal explains it poorly. At minimum, the 
> proposal should be rewritten and the type names reconsidered. I’m not a 
> person who gets confused by metatypes, but I simply cannot make heads or 
> tails of this proposal.

The most immediate issue is that this is a set of possible tactical moves 
without a strategy to justify why they are the right ones. There is no doubt 
that some are good, but without a clear plan of what reflection is intended to 
provide in swift, then it looks like a random exercise.

Joe's idea of slicing them apart is interesting and likely what will happen if 
he says so, but in my mind it will push further away the fundamental question 
of giving a scope to reflection in swift. As i said privately, there are a lot 
of good papers out there exploring the different facets. The answer belongs to 
the core team: if swift is mostly for all 7-to-77 with an ipad, then what's in 
swift today is already too much, if on the other hand the goal is to help with 
writing efficient dynamic language runtimes in swift, then this proposal will 
need lots of TLC.


> My general sense of this area is that the main problem is the dual meaning of 
> T.Type. T.Type wants to simultaneously be the type of the type instance and 
> the supertype of all subtype type instances. But this breaks down with 
> protocols, because protocol existentials don’t conform to themselves. So we 
> end up with T.Protocol, which gets confusingly renamed when it crosses 
> generic boundaries.
> 
> I think the answer here is to split these two roles:
> 
> Metatype is the type of the type instance. T.self is of type Metatype. 
> (Yes, we can call it T.metatype if we want.)
> If we don’t go into the direction of Type there is no need to rename the 
> current T.self magic to T.metatype, that was only considered for the Type 
> model. .self will be removed one day anyways (hopefully).
> 
> Subtype-supertype relationships don’t translate directly to metaclasses; 
> Metatype is not a subtype of Metatype.
> Why is that so, see the example above?!
> 
> T.Subtype (or T.SubtypeMetatype? T.Conforming? this needs bikeshedding) is 
> the supertype of all metatypes for T and its subtypes. T.Subtype is sort of 
> like a protocol, in that there are no concrete instances of it, so it makes 
> no sense to instantiate it. For classes, it only includes required (i.e. 
> inherited) initializers.
> Happily, I believe—though I may be wrong—that we can mostly resyntax to fix 
> this immediate problem. Adding new capabilities, like extending the metatypes 
> of specific types and adding universal members, can wait (or mostly wait) for 
> another day.
> 
> (But in general, I would like to see those added directly on Metatype, and I 
> would like extending Metatype with instance members to be equivalent to 
> extending T with static/class members. I’d also like to conform metatypes to 
> protocols, to somehow define Metatype in the standard library as a relatively 
> ordinary Swift type, and to have a pony.)
> This is an interesting suggestion you mentioned there. But I think that would 
> imply that every member you’d add on the generic Metatype would be 
> automatically not available on any Swift type:
> 
> // Bikeshedding example:
> 
> buildin Metatype : Hashable {
> var hashValue: Int { .. }
> }
> 
> struct New {
> // NOT available anymore - even if it's needed for a different purpose
> static hashValue: Int { .. }  
> }
> The issue can be solve if metatypes gain a bottleneck access to the type T, 
> like Type.metatype for example.
> 
> // Bikeshedding example:
> 
> buildin Metatype : Hashable {
> var hashValue: Int { .. }
> var somethingToAccessT: T_XYZ { .. }
> }
> 
> struct New {
> static hashValue: Int { .. } // available again
> }
> If we now compare this to our Type 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

[Dave Abrahams via swift-evolution]

on Wed Jul 20 2016, Arnold  wrote:

> Sent from my iPhone
>
>> On Jul 20, 2016, at 12:47 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed Jul 20 2016, Arnold Schwaighofer  wrote:
>> 
 On Jul 20, 2016, at 9:54 AM, Andrew Trick  wrote:
 
 
> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer 
>  wrote:
> 
> 
> The question is are they relying on the non-@objc post-condition
> when the API returns true? If they were to implement something like
> array they might.
 
 The conservative thing to do is not make that promise for now and
 address need later if it’s important. Conservative makes sense to me
 given the current level of confusion.
>>> 
>> 
>> That said, something like “isUniquelyReferencedNativeSwift” would
>> work assuming that’s semantically correct (“native" Swfit objects
>> do not inherit from NSObject). “isKnownUniquelyReferenced” would
>> be fine with a warning in the doc comment that it may always
>> return false for objc objects.
> 
> 
> Native swift objects are the ones that use native swift reference
> counting and don’t alias Objc class instances. That is at least how
> we have defined it at the SIL (Builtin.NativeObject vs
> Builtin.UnknownObject) level:
> 
> 
> * A ``Builtin.NativeObject`` may alias any native Swift heap object,
> including a Swift class instance, a box allocated by ``alloc_box``,
> or a thick function's closure context.
> It may not alias natively Objective-C class instances.
> 
> 
> I think at the language/stdlib level the “native” concept is
> implementation detail that is not witnessed other than with the
> non-@objc requirement of ManageBufferPointer and
> isUniquelyReferencedNonObjC, i.e at the language/stdlib level we
> call “native” "non-@objc”. Which IMO is more descriptive.
 
 I totally agree, but people can’t have it both ways. You can’t avoid
 a negative in the name and refuse to define the positive
 nomenclature.
 
> I understand the desire to remove Objc’ness from API names that can be 
> used on platforms without ObjC.
 
 Me too.
 
 +1 forisKnownUniquelyReferenced, with clarifying doc comments
>>> 
>>> Do we continue promise that “isKnownUniquelyReferenced” returns false
>>> for non-@objc objects in the comments?
>> 
>> I think you mean, “do we promise that “isKnownUniquelyReferenced” returns
>> false for @objc objects?”
>
> Yes.
>
>> 
>> IMO we should not make that promise.  There's not much you can do with it.
>
> You can implement Array (or a similar bridged) type outside of the
> standard library -- at least the aspect of it that transitions to a
> native representation when you write to it if it is non-native.

You can still do that, even without a guarantee from
isKnownUniquelyReferenced.  You can dynamic cast to your native storage
type and see if you have it.  Or you can use an enum to remember what
representation you store.

-- 
Dave

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

Re: [swift-evolution] Returning nothing

[Ross O'Brien via swift-evolution]

There's a difference between returning a void type and returning nothing.
An instance of Void is a catch-all 'something' which conforms to no
protocols, which can be quite useful with generic types.

On Thu, Jul 21, 2016 at 5:59 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Quite frankly, I think the ship has long sailed for renaming Void.
>
>
> On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > This may be a silly question - given that one of Swift’s design
>> principles is to be a language for new programmers and for APIs to read
>> like English phrases, should we replace the typealias of Void for the
>> return type () with Nothing.
>>
>> Nothing was one of the names considered for the bottom type that replaces
>> @noreturn (
>> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
>> I think it would be confusing to rename Void to Nothing.
>>
>> If we consider renaming it Unit is the obvious way to go (
>> https://en.m.wikipedia.org/wiki/Unit_type)
>>
>> >
>> > So
>> >
>> > f: ( input: Int) -> Void
>> >
>> > becomes
>> >
>> > f: ( input: Int) -> Nothing
>> >
>> > Instead of saying “f takes an Int and returns a Void” I read this as “f
>> takes an Int and returns nothing”.
>> >
>> > I’ve been using f:(input: Int) -> () because it’s easier to explain
>> than Void to non-experienced programmers. Experienced programmers have no
>> problem with Void. But Void seems to be something we’re using just because
>> we have for a while - like x++ and C-style for loops.
>> >
>> > Best,
>> >
>> > Daniel
>> > ___
>> > 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] [Proposal][Discussion] Qualified Imports

[Xiaodi Wu via swift-evolution]

On Thu, Jul 21, 2016 at 11:14 AM, Robert Widmann 
wrote:

>
>
> ~Robert Widmann
>
> 2016/07/21 8:23、Xiaodi Wu  のメッセージ:
>
> On Thu, Jul 21, 2016 at 2:02 AM, Robert Widmann 
> wrote:
>
>>
>> On Jul 20, 2016, at 11:56 PM, Xiaodi Wu  wrote:
>>
>> On Thu, Jul 21, 2016 at 1:40 AM, Robert Widmann 
>> wrote:
>>
>>>
>>> On Jul 20, 2016, at 10:04 PM, Xiaodi Wu  wrote:
>>>
>>> On Wed, Jul 20, 2016 at 10:33 PM, Robert Widmann <
>>> devteam.cod...@gmail.com> wrote:
>>>


 ~Robert Widmann

 2016/07/20 19:01、Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> のメッセージ:

 On Wed, Jul 20, 2016 at 8:10 PM, Robert Widmann 
 wrote:

>
> On Jul 20, 2016, at 5:47 PM, Xiaodi Wu  wrote:
>
> On Wed, Jul 20, 2016 at 6:30 PM, Robert Widmann 
> wrote:
>
>> “The Phase Distinction” is a semantic one, not one built into the
>> import system itself.
>>
>
>
> I understand. To rephrase my question: why introduce this semantic
> distinction to Swift?
>
>
> What I meant is that even the system I’m modeling this on makes a
>> distinction between import directives that actually expose identifiers to
>> modules and import directives that modify identifiers that are already in
>> scope.
>>
>
>
> This is, IMO, very complex. I appreciate enormously the conceptual
> simplicity of the current Swift approach which, for all of its
> deficiencies, has only one import directive that does what it says on the
> tin: it exposes identifiers. I'm not bothered if it gains the ability to
> expose identifiers differently from one file to the next without keywords
> firewalled from each other to preserve the notion of phases of import.
>
>
> We are *not* changing the unqualified Swift import system.  Take a
> gander at the proposal again, or even the first draft.  Swift has a
> particularly strange syntax for qualified imports that hasn’t received
> attention since it was first introduced 2 major versions ago.  That thing
> allows quite a variety of senseless variants that can be both completely
> expressed by and subsumed by `using` and `hiding`.
>


 My sense, which I think has been echoed by others, is that the proposed
 solution is syntactically complex, and now that I understand that you're
 thinking through a multi-phase concept, also conceptually multilayered. I'm
 not arguing that the existing syntax for qualified imports doesn't need
 changing, only that there is room for radical simplification of the
 proposed solution IMO. As I re-read this proposal once more, it strikes me
 that the motivating issues identified (needlessly specific, does not
 compose, etc.) don't clearly argue for the specific direction proposed as
 opposed to alternatives like Joe's.


 Perhaps they need to reread the proposal.  Syntactically complex how?
 We're introducing two keywords and using tuple syntax.  Our grammar changes
 are laid bare and take up 7 lines.  I think there might be a general air of
 confusing semantics changes with syntax changes.

>>>
>>>
>>> I can't speak for the general air, but putting on my disinterested
>>> reader hat, I can see why the confusion might arise--
>>>
>>> The Motivation section begins:
>>> "The existing syntax for qualified imports..."
>>>
>>> And the Proposed Solution begins:
>>> "The grammar and semantics of qualified imports..."
>>>
>>> But the Detailed Design begins:
>>> "Qualified import syntax will be revised..."
>>>
>>> It's neither here nor there in terms of the proposal content, but
>>> suffice it to say that if one strings together the topic sentences in your
>>> proposal, the overarching narrative to be gleaned here is: "The current
>>> syntax for qualified imports is no good; therefore, we revise the semantics
>>> of qualified imports by changing the syntax." Sure.
>>>
>>>
>>> Ne’er the twain shall meet.
>>
>
>
> Yes, you explained this concept very clearly as it applies to Agda.
> But I just don't see why we should care to have this distinction. Yet you
> are very adamant about it. What am I missing?
>
>
>
> We should care because that is precisely what the two operations *do*.
>  `using` and `hiding` introduce things or remove things from scope which 
> is
> a very different operation from taking something that is already in scope
> and giving it a new name.
>


 Perhaps I'm not phrasing my question very cogently. Of course, if we
 are to have `using`, `hiding`, and `renaming`, we must observe the
 distinctions between them.



 If you don’t want to think of them as part of the same 

Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

[Dmitri Gribenko via swift-evolution]

On Thu, Jul 21, 2016 at 10:02 AM, Michael Gottesman via
swift-evolution  wrote:
> Hello everyone.
>
> This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore 
> to the Objective C overlay.

+1.

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

[swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

[Michael Gottesman via swift-evolution]

Hello everyone.

This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore to 
the Objective C overlay. The reason to do this is that ideally StdlibCore would 
not have any code specific to ObjC in it. This is a small step that we can take 
in this direction by moving the public API of AutoreleasingUnsafeMutablePointer 
to the ObjC overlay. The way that this would be done is that the implementation 
for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would 
add an underscore to make that API private to the standard library. Then inside 
the ObjC overlay, we would create a typealias to the internal API with the 
non-underscored name (i.e. make the typealias the public API). Then at a later 
point in time we can move the implementation. The reason why I am not proposing 
to move the implementation today is that there are dependencies in Array/Hashed 
Collections on AutoreleasingUnsafeMutablePointer. Moving that code is a larger 
project that is preconditioned on this proposal going in first as an 
incremental step.

Thoughts, flames, etc?
Michael
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Robert Widmann via swift-evolution]

> On Jul 21, 2016, at 9:41 AM, Joe Groff  wrote:
> 
> 
>> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Why is hiding in-scope but renaming out-of-scope? Both are additive to 
>> Swift, and as has been argued by others, the former is a special case of the 
>> latter.
> 
> Hiding also doesn't seem useful to me at all. The main use case I can see is 
> to resolve a name conflict introduced between two import-everything 
> declarations, or between an imported and local name, and both of these use 
> cases seem better served to me by a name lookup rule that locals are favored 
> over qualified imports, which in turn are favored over everything imports. 
> 'hiding' puts the import declaration in the wrong place. Consider that:
> 
>   import Foo hiding foo
>   import Bar
> 
>   foo()
> 
> declares the un-import of 'foo' next to 'Foo'. The user (or IDE) has to do 
> the mental gymnastics to figure out that 'foo()' refers to Bar.foo() by 
> omission. This is much clearer expressed with 'using', which puts the 
> disambiguation next to the chosen module:
> 

We were already doing those gymnastics before (in fact, one of the diagnostics 
for the old style would remind you of the correct decl kind if you thought a 
struct was a class etc.  Clearly, we already know).  If you want to be 
explicit, 

import Bar using (foo)
import Foo hiding (foo)

import Bar

Works just fine.  

The lookup rule seems to be justifying introducing the “confusing” example 
above.  It would definitely work, but why not just be explicit about what 
you’re using and what you’re hiding?

>   import Foo
>   import Bar
>   import Bar using foo // favor Bar.foo over Foo.foo
> 
>   foo()
> 
> 'using' is also more resilient against module evolution; as modules gain new 
> members, their clients would potentially be forced to play whack-a-mole with 
> 'hiding' as new conflicts are introduced. A user who diligently uses 
> qualified imports doesn't need to worry about that. I would suggest removing 
> 'hiding' in favor of a rule like this.

Is this not the same case with using declarations as the client module evolves? 
 It is more likely that a using import will grow in size as a module evolves 
than a hiding one - after all a hiding import says you explicitly intend to use 
everything else.  And if you start hiding enough identifiers that it becomes 
unwieldy you can always flip the script and use a using directive.  The same 
applies the other way around for big using clauses.

> 
> -Joe
> 
>> On Wed, Jul 20, 2016 at 15:55 Brandon Knope  wrote:
>> I meant is there any reason for requiring parentheses 
>> 
>> On Jul 20, 2016, at 4:53 PM, Robert Widmann  wrote:
>> 
>>> Renaming is out of scope for this proposal, that’s why.
>>> 
 On Jul 20, 2016, at 1:26 PM, Brandon Knope  wrote:
 
 I prefer this 100x more
 
 Is there any reason why this wouldn't work?
 
 Brandon 
 
 On Jul 20, 2016, at 4:13 PM, Xiaodi Wu  wrote:
 
> Yeah, I'd be happy to lose the parentheses as well.
> 
> In the last thread, my take on simplifying the proposed syntax was:
> 
> ```
> import Swift using String, Int
> 
> // or, for hiding:
> import Swift using Int as _
> ```
> 
> The key simplification here is that hiding doesn't need its own 
> contextual keyboard, especially if we support renaming (a huge plus in my 
> book), as renaming to anything unused (or explicitly to `_`) is what 
> hiding is all about.
> On Wed, Jul 20, 2016 at 15:01 Brandon Knope  wrote:
> 
> 
> On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> As Joe and others mentioned in the previous thread, this syntax could be 
>> greatly simplified in ways that resemble analogous facilities in other 
>> languages. In particular I think it's alarmingly asymmetrical that, in 
>> your proposal, `import Swift using (String)` imports *only* String while 
>> `import Swift hiding (String)` imports *everything but* String. This 
>> becomes evident when chained together:
>> 
>> ```
>> import Swift using (String, Int)
>> // imports only String and Int
>> import Swift using (String, Int) hiding (String)
>> // imports only Int
>> import Swift hiding (String, Int)
>> // imports everything except String and Int
>> import Swift hiding (String, Int) using (String)
>> // imports *nothing*? nothing except String? everything except Int? 
>> confusing.
>> ```
>> 
>> By contrast, Joe's proposed syntax (with some riffs) produces something 
>> much more terse *and* much more clear:
>> 
>> ```
>> import Swift.*
>> import Swift.(Int as MyInt, *)
>> import Swift.(Int as _, *)

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Shawn Erickson via swift-evolution]

I agree with your line of reasoning regarding not needing 'hiding'
(leveraging order of lookup as you noted).
On Thu, Jul 21, 2016 at 12:41 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 20, 2016, at 1:59 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Why is hiding in-scope but renaming out-of-scope? Both are additive to
> Swift, and as has been argued by others, the former is a special case of
> the latter.
>
> Hiding also doesn't seem useful to me at all. The main use case I can see
> is to resolve a name conflict introduced between two import-everything
> declarations, or between an imported and local name, and both of these use
> cases seem better served to me by a name lookup rule that locals are
> favored over qualified imports, which in turn are favored over everything
> imports. 'hiding' puts the import declaration in the wrong place. Consider
> that:
>
> import Foo hiding foo
> import Bar
>
> foo()
>
> declares the un-import of 'foo' next to 'Foo'. The user (or IDE) has to do
> the mental gymnastics to figure out that 'foo()' refers to Bar.foo() by
> omission. This is much clearer expressed with 'using', which puts the
> disambiguation next to the chosen module:
>
> import Foo
> import Bar
> import Bar using foo // favor Bar.foo over Foo.foo
>
> foo()
>
> 'using' is also more resilient against module evolution; as modules gain
> new members, their clients would potentially be forced to play whack-a-mole
> with 'hiding' as new conflicts are introduced. A user who diligently uses
> qualified imports doesn't need to worry about that. I would suggest
> removing 'hiding' in favor of a rule like this.
>
> -Joe
>
> > On Wed, Jul 20, 2016 at 15:55 Brandon Knope  wrote:
> > I meant is there any reason for requiring parentheses
> >
> > On Jul 20, 2016, at 4:53 PM, Robert Widmann  wrote:
> >
> >> Renaming is out of scope for this proposal, that’s why.
> >>
> >>> On Jul 20, 2016, at 1:26 PM, Brandon Knope  wrote:
> >>>
> >>> I prefer this 100x more
> >>>
> >>> Is there any reason why this wouldn't work?
> >>>
> >>> Brandon
> >>>
> >>> On Jul 20, 2016, at 4:13 PM, Xiaodi Wu  wrote:
> >>>
>  Yeah, I'd be happy to lose the parentheses as well.
> 
>  In the last thread, my take on simplifying the proposed syntax was:
> 
>  ```
>  import Swift using String, Int
> 
>  // or, for hiding:
>  import Swift using Int as _
>  ```
> 
>  The key simplification here is that hiding doesn't need its own
> contextual keyboard, especially if we support renaming (a huge plus in my
> book), as renaming to anything unused (or explicitly to `_`) is what hiding
> is all about.
>  On Wed, Jul 20, 2016 at 15:01 Brandon Knope  wrote:
> 
> 
>  On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
> > As Joe and others mentioned in the previous thread, this syntax
> could be greatly simplified in ways that resemble analogous facilities in
> other languages. In particular I think it's alarmingly asymmetrical that,
> in your proposal, `import Swift using (String)` imports *only* String while
> `import Swift hiding (String)` imports *everything but* String. This
> becomes evident when chained together:
> >
> > ```
> > import Swift using (String, Int)
> > // imports only String and Int
> > import Swift using (String, Int) hiding (String)
> > // imports only Int
> > import Swift hiding (String, Int)
> > // imports everything except String and Int
> > import Swift hiding (String, Int) using (String)
> > // imports *nothing*? nothing except String? everything except Int?
> confusing.
> > ```
> >
> > By contrast, Joe's proposed syntax (with some riffs) produces
> something much more terse *and* much more clear:
> >
> > ```
> > import Swift.*
> > import Swift.(Int as MyInt, *)
> > import Swift.(Int as _, *)
> > ```
> 
>  I really don't find this much clearer than the proposed one. The
> proposal reads much clearer.
> 
>  Joe's syntax has a lot going on in my opinion.
> 
>  For the proposal, do we really need the parentheses? It makes the
> syntax look heavier
> 
>  Brandon
> 
> 
> 
> >
> >
> > On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Hello all,
> >
> > I’d like to thank the members of the community that have guided the
> revisions of this proposal.  We have decided to heed the advice of the
> community and break down our original proposal on modules and qualified
> imports into source-breaking (qualified imports) and additive (modules)
> proposals.  As qualified imports is the change most suited to Swift 3, we
> 

Re: [swift-evolution] Returning nothing

[Xiaodi Wu via swift-evolution]

Quite frankly, I think the ship has long sailed for renaming Void.


On Thu, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > This may be a silly question - given that one of Swift’s design
> principles is to be a language for new programmers and for APIs to read
> like English phrases, should we replace the typealias of Void for the
> return type () with Nothing.
>
> Nothing was one of the names considered for the bottom type that replaces
> @noreturn (
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
> I think it would be confusing to rename Void to Nothing.
>
> If we consider renaming it Unit is the obvious way to go (
> https://en.m.wikipedia.org/wiki/Unit_type)
>
> >
> > So
> >
> > f: ( input: Int) -> Void
> >
> > becomes
> >
> > f: ( input: Int) -> Nothing
> >
> > Instead of saying “f takes an Int and returns a Void” I read this as “f
> takes an Int and returns nothing”.
> >
> > I’ve been using f:(input: Int) -> () because it’s easier to explain than
> Void to non-experienced programmers. Experienced programmers have no
> problem with Void. But Void seems to be something we’re using just because
> we have for a while - like x++ and C-style for loops.
> >
> > Best,
> >
> > Daniel
> > ___
> > 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] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Shawn Erickson via swift-evolution]

(Google inbox won't let me inline my comments)

Thanks for the effort on iterating and refining this proposal.

+1 on the proposal, more strongly favoring the first design.

If my brain is working correctly it seems like we could start with the
first design and if somehow problematic move to the the second model in the
future without (much?) disruption. I didn't sit down and reason it out in
much depth (watching my 2.5 year old at the moment) however so I will leave
that to others to ponder.

I think it aligns well with Swifts principles in terms of favoring external
to module API to be intentional / explicit. The latest revisions - I think
- has also sufficiently reduced the burden to module developers which is
also another important aspect of Swift.

I haven't used a language the has this exact type of feature but I have
often desired to haven his type of capability when I was authoring
libraries for others (often in company). I am a believer in being very
explicit in API contract to both confine what I have to design for/test
when authoring a library as well as having more clarity when consuming a
library.




-Shawn

On Thu, Jul 21, 2016 at 11:33 AM Chris Lattner  wrote:

> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access
> and public overridability" begins now and runs through July 25. 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?
> * 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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Proposal] Replace String.init(repeating repeatedValue: Character, count: Int) and String.init(repeating repeatedValue: UnicodeScalar, count: Int) by String.init(repeating repeatedVa

[Roman Levenstein via swift-evolution]

Hi,

I’d like to propose some improvements for String initializers and String.append 
methods. It is addressing https://bugs.swift.org/browse/SR-1964 
 (rdar://problem/17028332 
).


# Replace String.init(repeating repeatedValue: Character, count: Int) and 
String.init(repeating repeatedValue: UnicodeScalar, count: Int) by 
String.init(repeating repeatedValue: String, count: Int)

* Proposal:
* Author: [Roman Levenstein](http://github.com/swiftix)
* Status: 
* Review manager:

Introduction
=

This proposal suggest replacing String initializers taking Character or 
UnicodeScalar as a repeating value by a more general initializer that takes a 
String as a repeating value. This is done to avoid the ambiguities in the 
current String API, which can be only resolved by explicit casting. It is also 
proposed to remove one of the String.append APIs to match these changes.

All user-facing Swift APIs must go through Swift Evolution. While this is a 
relatively simple API change with an existing implementation, this formal 
proposal provides a paper trail as is normal and usual for this process.

Motivation


This change introduces a non-ambiguous API for constructing Strings. With the 
set of String initializers available today, ones often needs to explicitly cast 
the repeating value literal to disambiguate what initializer is meant to be 
used. 

An example of the ambiguity:

> let x = String(repeating:"0", count: 10) 
error: repl.swift:29:9: error: ambiguous use of 'init(repeating:count:)'
let x = String(repeating:"0", count: 10)
^

Swift.String:11:12: note: found this candidate
public init(repeating repeatedValue: Character, count: Int)
   ^

Swift.String:21:12: note: found this candidate
public init(repeating repeatedValue: UnicodeScalar, count: Int)
   ^

To disambiguate, one currently needs to write something like:
`let zeroes = String(repeating: "0" as Character, count: 10)` or 
`let zeroes = String(repeating: "0" as UnicodeScalar, count: 10)`

Detailed Design


This update affects `String`.

It is proposed to replace the following ambiguous API:
*  `public init(repeating repeatedValue: Character, count: Int)`
*  `public init(repeating repeatedValue: UnicodeScalar, count: Int)`

by the following, more powerful API:
*  `public init(repeating repeatedValue: String, count: Int)`

To match this change, it is also proposed to remove the following String.append 
API:
*  `public mutating func append(_ x: UnicodeScalar)`
because there is already an existing and more powerful API:
*  `public mutating func append(_ other: String)`

Impact on Existing Code
===

Existing third party code using these to be removed String APIs will need 
migration.
A fixit could be provided to automate this migration.

Alternatives Considered
==

Not Applicable


-Roman

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

Re: [swift-evolution] Returning nothing

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
>  wrote:
> 
> This may be a silly question - given that one of Swift’s design principles is 
> to be a language for new programmers and for APIs to read like English 
> phrases, should we replace the typealias of Void for the return type () with 
> Nothing.

Nothing was one of the names considered for the bottom type that replaces 
@noreturn 
(https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
 I think it would be confusing to rename Void to Nothing.

If we consider renaming it Unit is the obvious way to go 
(https://en.m.wikipedia.org/wiki/Unit_type)

> 
> So
> 
> f: ( input: Int) -> Void
> 
> becomes
> 
> f: ( input: Int) -> Nothing
> 
> Instead of saying “f takes an Int and returns a Void” I read this as “f takes 
> an Int and returns nothing”.
> 
> I’ve been using f:(input: Int) -> () because it’s easier to explain than Void 
> to non-experienced programmers. Experienced programmers have no problem with 
> Void. But Void seems to be something we’re using just because we have for a 
> while - like x++ and C-style for loops.
> 
> Best,
> 
> Daniel
> ___
> 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] Memberwise initialisers adopt the same access modifiers as the struct

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jul 21, 2016, at 11:26 AM, Ian Keen  wrote:
> 
> I did see that one, however it appeared that proposal didn’t could on the 
> access of the initialiser itself at all? just how it interacts with different 
> properties access levels. It was kinda gargantuan, I’m proposing a single 
> behavioural change for now, rather than introducing a ton of new features.
> 
> I would almost consider this a bug.

This is an additive change so it is out of scope for Swift 3 no matter how 
small.  There are already plans to revisit the memberwise initialization 
discussion after Swift 3 is out.  I encourage you to join that discussion when 
it gets going.

> 
> 
> 
>>> On Jul 20, 2016, at 8:15 PM, Ian Keen via 
>>> swift-evolutionwrote:
>>> 
>>> Not much to this one… I think the memberwise `init` should follow the same 
>>> level of access as the struct. It appears to default to `internal` 
>>> regardless of the struct access modifiers
>>> 
>>> Thoughts?
>> There was an extensive discussion and review of a proposal I put forward 
>> early this year for improving memberwise initialization. This topic has been 
>> deferred until after Swift 3 wraps up. We’ll be revisiting it in the coming 
>> months.
>> 
>>> 
>>> ___
>>> 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] Returning nothing

[Daniel Steinberg via swift-evolution]

This may be a silly question - given that one of Swift’s design principles is 
to be a language for new programmers and for APIs to read like English phrases, 
should we replace the typealias of Void for the return type () with Nothing.

So

f: ( input: Int) -> Void

becomes

f: ( input: Int) -> Nothing

Instead of saying “f takes an Int and returns a Void” I read this as “f takes 
an Int and returns nothing”.

I’ve been using f:(input: Int) -> () because it’s easier to explain than Void 
to non-experienced programmers. Experienced programmers have no problem with 
Void. But Void seems to be something we’re using just because we have for a 
while - like x++ and C-style for loops.

Best,

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

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Joe Groff via swift-evolution]

> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Why is hiding in-scope but renaming out-of-scope? Both are additive to Swift, 
> and as has been argued by others, the former is a special case of the latter.

Hiding also doesn't seem useful to me at all. The main use case I can see is to 
resolve a name conflict introduced between two import-everything declarations, 
or between an imported and local name, and both of these use cases seem better 
served to me by a name lookup rule that locals are favored over qualified 
imports, which in turn are favored over everything imports. 'hiding' puts the 
import declaration in the wrong place. Consider that:

import Foo hiding foo
import Bar

foo()

declares the un-import of 'foo' next to 'Foo'. The user (or IDE) has to do the 
mental gymnastics to figure out that 'foo()' refers to Bar.foo() by omission. 
This is much clearer expressed with 'using', which puts the disambiguation next 
to the chosen module:

import Foo
import Bar
import Bar using foo // favor Bar.foo over Foo.foo

foo()

'using' is also more resilient against module evolution; as modules gain new 
members, their clients would potentially be forced to play whack-a-mole with 
'hiding' as new conflicts are introduced. A user who diligently uses qualified 
imports doesn't need to worry about that. I would suggest removing 'hiding' in 
favor of a rule like this.

-Joe

> On Wed, Jul 20, 2016 at 15:55 Brandon Knope  wrote:
> I meant is there any reason for requiring parentheses 
> 
> On Jul 20, 2016, at 4:53 PM, Robert Widmann  wrote:
> 
>> Renaming is out of scope for this proposal, that’s why.
>> 
>>> On Jul 20, 2016, at 1:26 PM, Brandon Knope  wrote:
>>> 
>>> I prefer this 100x more
>>> 
>>> Is there any reason why this wouldn't work?
>>> 
>>> Brandon 
>>> 
>>> On Jul 20, 2016, at 4:13 PM, Xiaodi Wu  wrote:
>>> 
 Yeah, I'd be happy to lose the parentheses as well.
 
 In the last thread, my take on simplifying the proposed syntax was:
 
 ```
 import Swift using String, Int
 
 // or, for hiding:
 import Swift using Int as _
 ```
 
 The key simplification here is that hiding doesn't need its own contextual 
 keyboard, especially if we support renaming (a huge plus in my book), as 
 renaming to anything unused (or explicitly to `_`) is what hiding is all 
 about.
 On Wed, Jul 20, 2016 at 15:01 Brandon Knope  wrote:
 
 
 On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
> As Joe and others mentioned in the previous thread, this syntax could be 
> greatly simplified in ways that resemble analogous facilities in other 
> languages. In particular I think it's alarmingly asymmetrical that, in 
> your proposal, `import Swift using (String)` imports *only* String while 
> `import Swift hiding (String)` imports *everything but* String. This 
> becomes evident when chained together:
> 
> ```
> import Swift using (String, Int)
> // imports only String and Int
> import Swift using (String, Int) hiding (String)
> // imports only Int
> import Swift hiding (String, Int)
> // imports everything except String and Int
> import Swift hiding (String, Int) using (String)
> // imports *nothing*? nothing except String? everything except Int? 
> confusing.
> ```
> 
> By contrast, Joe's proposed syntax (with some riffs) produces something 
> much more terse *and* much more clear:
> 
> ```
> import Swift.*
> import Swift.(Int as MyInt, *)
> import Swift.(Int as _, *)
> ```
 
 I really don't find this much clearer than the proposed one. The proposal 
 reads much clearer. 
 
 Joe's syntax has a lot going on in my opinion.
 
 For the proposal, do we really need the parentheses? It makes the syntax 
 look heavier
 
 Brandon 
 
 
 
> 
> 
> On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution 
>  wrote:
> Hello all,
> 
> I’d like to thank the members of the community that have guided the 
> revisions of this proposal.  We have decided to heed the advice of the 
> community and break down our original proposal on modules and qualified 
> imports into source-breaking (qualified imports) and additive (modules) 
> proposals.  As qualified imports is the change most suited to Swift 3, we 
> are pushing that proposal now as our final draft.
> 
> It can be had inline with this email, on Github, or as a gist.
> 
> Thanks,
> 
> ~Robert Widmann
> 
> Qualified Imports Revisited
> 
>   • Proposal: SE-
>   • Authors: Robert Widmann, 

Re: [swift-evolution] : [Proposal] Change UnicodeScalar initializer to failable

[Duan via swift-evolution]

+1

"Explicit is better than implicit"

Daniel Duan
Sent from my iPhone

> On Jul 21, 2016, at 9:34 AM, Björn Forster via swift-evolution 
>  wrote:
> 
> +1
> 
> I think this helps making Swift code more robust and should be included in 
> Swift 3.
> 
> The scenario described by Xin is a real world and not an academic one.
> 
> Also, the change he proposes is a very small one, so you get "much bang for 
> the bucks" in my point of view.
> 
> Björn
> 
> Am Dienstag, 19. Juli 2016 schrieb Xin Tong via swift-evolution :
>> Hi, 
>> I would like to propose changing unicodescalar initializer to failable. 
>> Currently, when you pass an invalid value to the UnicodeScalar initializer 
>> the swift stdlib crashes the program by calling _precondition. This is bad 
>> if you construct a unicode scalar from unknown input.
>> As a result. I would like to propose to mark the initializer as failable and 
>> return nil in case of a failure. 
>> 
>> Currently, in the code below, the stdlib crashes the program by calling 
>> _precondition if codepoint is not a valid unicode.  
>> var string = “" 
>> let codepoint: UInt32 = 55357 // this is invalid 
>> let ucode = UnicodeScalar(codepoint) // Program crashes at this point. 
>> string.append(code)
>> 
>> After marking the initializer as failable, users can write code like this. 
>> And the program will execute fine even codepoint is invalid.  
>> var string = "" let codepoint: UInt32 = 55357 // this is invalid
>> let ucode = UnicodeScalar(codepoint) 
>> if ucode != nil {
>>   string.append(code!)
>> } else {
>>   // do something else 
>> }
>> 
>> As the initializer is now failable, it returns an optional, so optional 
>> unchaining or forced unwrapping needs to be used.  Alternatively, its also 
>> possible to leave status quo and force the users to do input checks
>> before trying to construct a UnicodeScalar.  But i feel having failable 
>> initializer helps user to write more robust code.
>> -Xin  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Robert Widmann via swift-evolution]

> On Jul 21, 2016, at 9:25 AM, Félix Cloutier  wrote:
> 
>> 
>> Le 21 juil. 2016 à 08:48:22, Robert Widmann > > a écrit :
>> 
>> ~Robert Widmann
>> 
>> 2016/07/21 8:17、Félix Cloutier > > のメッセージ:
>> 
>>> I know that the compiler can't read my mind. I don't mean to be frustrating.
>>> 
>>> If Foundation is imported in the bridging header of a project (as it is 
>>> today, by default, in Swift framework projects), you get all of Foundation 
>>> in all of your Swift code without a chance to write "import Foundation 
>>> hiding (...)" anywhere. This reinforces my position that types should be 
>>> selected affirmatively.
>> 
>> I don't understand this at all.  The point of using and hiding is we create 
>> a file-local subset of identifiers you want to see.  Bridging headers do not 
>> change that.  I don't see how this is an example that affirmative is the 
>> *only* way to pick identifiers out of modules.
> 
> Here's a tiny Swift framework project: 
> http://felixcloutier.com/tmp/SwiftImports.zip 
> 
> 
> The important part is that it has a Foo.h framework header, which #imports 
> Cocoa. Through that, every Swift file in the project has access to everything 
> that you get from , as demonstrated by Foo.swift that creates 
> a NSWindow without importing anything. Under the suggested model, I can't 
> hide any of these symbols because the import does not happen on the Swift 
> side, and there doesn't seem to be a way to break an ambiguity by hiding 
> symbols in that case.
> 


import Cocoa hiding (NSWindow)

Done.  This specific case is one of the reasons why imports are file-local.

> I probably misused "bridging header" because I don't fully understand how 
> symbols flow between Objective-C and Swift in frameworks.
> 
>> 
>>> 
>>> I'm not proposing a better solution because I don't have one right now. But 
>>> if it would help appease you that I suggest something: keep "import using", 
>>> let go of "hiding", and reuse the "using" keyword to select symbols from 
>>> specific modules to break ambiguities. (Names must always be 
>>> module-qualified to break ambiguities with classes that have the same name 
>>> as a module.)
>> 
>> Halfway there.  Why is hiding such an issue?  Explain to me how with only 
>> using imports you can recreate the "import String without String.UTF8View" 
>> example in the proposal.
> 
> I'm pretty sure that I said that the example wasn't perfect. I wouldn't know 
> how to do that. However, I don't know what else than breaking ambiguities you 
> would want to use hiding for, and that example fully demonstrates how you 
> would do that.

So it does.  Thank you for mocking this up.

> 
> Félix

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

Re: [swift-evolution] : [Proposal] Change UnicodeScalar initializer to failable

[Björn Forster via swift-evolution]

+1

I think this helps making Swift code more robust and should be included in
Swift 3.

The scenario described by Xin is a real world and not an academic one.

Also, the change he proposes is a very small one, so you get "much bang for
the bucks" in my point of view.

Björn

Am Dienstag, 19. Juli 2016 schrieb Xin Tong via swift-evolution :

> Hi,
>
> I would like to propose changing unicodescalar initializer to failable.
>
> Currently, when you pass an invalid value to the UnicodeScalar initializer 
> the swift stdlib crashes the program by calling _precondition. This is bad if 
> you construct a unicode scalar from unknown input.
>
> As a result. I would like to propose to mark the initializer as failable and 
> return nil in case of a failure.
>
>
> Currently, in the code below, the stdlib crashes the program by calling 
> _precondition if codepoint is not a valid unicode.
>
> var string = “"
>
> let codepoint: UInt32 = 55357 // this is invalid
>
> let ucode = UnicodeScalar(codepoint) // Program crashes at this point.
>
> string.append(code)
>
>
> After marking the initializer as failable, users can write code like this. 
> And the program will execute fine even codepoint is invalid.
>
> var string = "" let codepoint: UInt32 = 55357 // this is invalid
>
> let ucode = UnicodeScalar(codepoint)
>
> if ucode != nil {
>
>   string.append(code!)
>
> } else {
>
>   // do something else
>
> }
>
>
> As the initializer is now failable, it returns an optional, so optional 
> unchaining or forced unwrapping needs to be used.  Alternatively, its also 
> possible to leave status quo and force the users to do input checks
>
> before trying to construct a UnicodeScalar.  But i feel having failable 
> initializer helps user to write more robust code.
>
> -Xin
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[Félix Cloutier via swift-evolution]

> Le 21 juil. 2016 à 08:48:22, Robert Widmann  a 
> écrit :
> 
> ~Robert Widmann
> 
> 2016/07/21 8:17、Félix Cloutier > 
> のメッセージ:
> 
>> I know that the compiler can't read my mind. I don't mean to be frustrating.
>> 
>> If Foundation is imported in the bridging header of a project (as it is 
>> today, by default, in Swift framework projects), you get all of Foundation 
>> in all of your Swift code without a chance to write "import Foundation 
>> hiding (...)" anywhere. This reinforces my position that types should be 
>> selected affirmatively.
> 
> I don't understand this at all.  The point of using and hiding is we create a 
> file-local subset of identifiers you want to see.  Bridging headers do not 
> change that.  I don't see how this is an example that affirmative is the 
> *only* way to pick identifiers out of modules.

Here's a tiny Swift framework project: 
http://felixcloutier.com/tmp/SwiftImports.zip

The important part is that it has a Foo.h framework header, which #imports 
Cocoa. Through that, every Swift file in the project has access to everything 
that you get from , as demonstrated by Foo.swift that creates a 
NSWindow without importing anything. Under the suggested model, I can't hide 
any of these symbols because the import does not happen on the Swift side, and 
there doesn't seem to be a way to break an ambiguity by hiding symbols in that 
case.

I probably misused "bridging header" because I don't fully understand how 
symbols flow between Objective-C and Swift in frameworks.

> 
>> 
>> I'm not proposing a better solution because I don't have one right now. But 
>> if it would help appease you that I suggest something: keep "import using", 
>> let go of "hiding", and reuse the "using" keyword to select symbols from 
>> specific modules to break ambiguities. (Names must always be 
>> module-qualified to break ambiguities with classes that have the same name 
>> as a module.)
> 
> Halfway there.  Why is hiding such an issue?  Explain to me how with only 
> using imports you can recreate the "import String without String.UTF8View" 
> example in the proposal.

I'm pretty sure that I said that the example wasn't perfect. I wouldn't know 
how to do that. However, I don't know what else than breaking ambiguities you 
would want to use hiding for, and that example fully demonstrates how you would 
do that.

Félix

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

Re: [swift-evolution] [Pitch] Memberwise initialisers adopt the same access modifiers as the struct

[Ian Keen via swift-evolution]

I did see that one, however it appeared that proposal didn’t could on the 
access of the initialiser itself at all? just how it interacts with different 
properties access levels. It was kinda gargantuan, I’m proposing a single 
behavioural change for now, rather than introducing a ton of new features.

I would almost consider this a bug.



> > On Jul 20, 2016, at 8:15 PM, Ian Keen via 
> > swift-evolutionwrote:
> > 
> > Not much to this one… I think the memberwise `init` should follow the same 
> > level of access as the struct. It appears to default to `internal` 
> > regardless of the struct access modifiers
> > 
> > Thoughts?
> There was an extensive discussion and review of a proposal I put forward 
> early this year for improving memberwise initialization. This topic has been 
> deferred until after Swift 3 wraps up. We’ll be revisiting it in the coming 
> months.
> 
> > 
> > ___
> > 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 #3] SE-0117: Allow distinguishing between public access and public overridability

[Tony Allevato via swift-evolution]

On Thu, Jul 21, 2016 at 8:33 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access
> and public overridability" begins now and runs through July 25. 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 to the first design. I wouldn't be upset if the second design was what
got accepted, but I strongly prefer the first.

One of the benefits of this proposal has been formalizing some software
design notions related to type extensibility, and I feel very strongly that
API authors should be forced to make a decision one way or the other at the
time that they design a class whether it is extensible or not. It's true
that under design #2 you get a closed class (module extending with data)
without the explicitness of the keyword. However, being able to look at a
class definition and know immediately whether it's intended to be open or
closed is even more important. The performance improvements also seem
compelling.

While the formal side of me really liked keeping orthogonal concepts
(visibility vs. extensibility) separate, I can appreciate the desire to
eliminate boilerplate. Having "open" imply "public" unless stated otherwise
seems like a reasonable compromise.

Likewise, open-within-a-module-and-closed-outside as the default for
"public" is entirely aligned with Swift's other default visibility,
internal-by-default. The credo is essentially "don't protect users from
themselves and don't make coding more difficult for the common case of
within-app/module development, but the minute you decide to expose
something for other users, you must think about these things that affect
how others can and will use it."



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

Yes. More mainstream languages need to do more to encourage authors to
think about their designs and to allow those who care deeply about API
design to express them well.


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

Read the original and latest proposals and followed the discussions.


>
> 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 #3] SE-0117: Allow distinguishing between public access and public overridability

[Xiaodi Wu via swift-evolution]

On Thu, Jul 21, 2016 at 10:33 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The third review of "SE-0117: Allow distinguishing between public access
> and public overridability" begins now and runs through July 25. 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?
>

Much improved. I would be happy with either of the alternatives about open
classes.


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

(See previous review.)


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

Yes, almost entirely. One more nit. Now that `open` is proposed as a
standalone modifier (as opposed to `public open`), it should *not* be
composable with `internal`, etc. Here's why:

If I make an `internal` subclass of an `open` class, I should not be able
to have a `private open override`. In a [public] open subclass, I'd be
required to have a [public] open override. So too for an internal subclass
it doesn't make sense that the override might have less visibility than the
type itself. Forbidding accessory access control modifiers would have the
desired effect of enforcing the same visibility for an overriding open
member as for its containing type.

Moreover, from a learnability standpoint, seeing `private open` and
`internal open` sets up the expectation that `public open` might be
meaningful and not redundant, and that `open` might mean `internal open`
just as in (nearly) all other circumstances the absence of `private`,
`fileprivate`, and `public` implies `internal`. Since this is not true, and
since accessory access control modifiers should never be necessary as
discussed above, I'd advocate for forbidding the use of `open` in
conjunction with an explicit access level.

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

(See previous review.)


>
> 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] [Pitch] Memberwise initialisers adopt the same access modifiers as the struct

[Matthew Johnson via swift-evolution]

> On Jul 20, 2016, at 8:15 PM, Ian Keen via swift-evolution 
>  wrote:
> 
> Not much to this one… I think the memberwise `init` should follow the same 
> level of access as the struct. It appears to default to `internal` regardless 
> of the struct access modifiers 
> 
> Thoughts?

There was an extensive discussion and review of a proposal I put forward early 
this year for improving memberwise initialization.  This topic has been 
deferred until after Swift 3 wraps up.  We’ll be revisiting it in the coming 
months.

> 
> ___
> 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] [Meta] Updating the proposal template to prompt backward compatibility concerns

[Joe Groff via swift-evolution]

With the end of Swift 3 drawing near, we'll need to start designing with an eye 
toward backward compatibility. To that end, I think we should update the 
"Impact on existing code" proposal template to start asking writers to consider 
backward compatibility concerns. Here's some draft verbage to that effect:

https://github.com/jckarter/swift-evolution/blob/4bdd1b875a8402ec6bbabb3f37151262f130af2b/-template.md#backward-compatibility

Any concerns, revisions, or objections?

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

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Tony Allevato via swift-evolution]

A deeper problem is that String is already internally inconsistent because
of the special case in hasPrefix/Suffix:

String("abc").characters.prefix(0) == ""

which should imply that "abc".hasPrefix("") == true.

The existing implementation of hasPrefix/Suffix inherited from NSString is
a bug, not a feature, and I can cite it as a source of actual bugs in
production code that I have personal experience with. The correct
implementation being proposed here is backed by formal set/sequence theory.

Unfortunately, just fixing hasPrefix/Suffix isn't enough—since the String
type in Swift gets many of its primitive operations via Foundation.NSString
bridging, it will still inherit a lot of wrong behavior from there:

"abc".rangeOfSubstring("") currently returns nil, when it should return
Range(startIndex: 0, endIndex: 0), because that is the location of the
earliest range where "" is found.
"abc".containsString("") currently returns false when it should return
true.

Since Dave Abrahams mentioned earlier that Swift 4 would re-work strings,
I'm hopeful that a lot of this inherited behavior from Foundation will be
replaced by Swift-native code that does the right thing.


On Thu, Jul 21, 2016 at 8:46 AM Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> There are many empty strings in that string. In fact, there are infinite
> empty strings between each character, before the string, and after the
> string. Observe:
>
> "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy
> 42"
> "" + "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the
> Galaxy 42"
> etc, and I didn't even get past the first character!
>
> Wel, maybe I am not intelligent enough to comprehend that,
> or maybe it’s just a matter of definition/convention..
>
> Again, to me a string is ***just a row of characters***.
>
> therefore, concatenating empty strings (that do not contain any
> characters)  with other strings have no effect: .
> for example:
>
>let res = "" + "" + "" + "" + “The Art Of Learning To Fly”
>
> after that:
>
>  res == “The Art Of Learning To Fly”
>
> and:
>
>  res.count == “The Art Of Learning To Fly”.count
>
> Regardless what in many  other programming languages  is done;
> I prefer the Objective jC NSString hasPrefix(“") way of handling this,
> which always returns False,e because a row of characters
> is contiguous, without empty “” in between, leading or trailing.
>
> However, we don’t seem to share the same opinion, about this sorry.
> nothing more to say about that, I guess.
>
> TedvG
>
>
>
> On Jul 20, 2016, at 6:49 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Don’t Panic !
>
> At the risk of seeing things in a somewhat trivial perspective,
> combined with an almost complete absence of abstraction:
>
> Note that to relatively simple persons like me:
>
> String instances are just rows of characters (when not empty, of course)
>
> There are only two kinds of Strings:
>
> 1. empty Strings, which do not contain amy characters at all
>
>   and
>
> 2.  Strings containing 1 or more characters.
>
> Ergo ad Infinitum :
>
> Empty Strings do not occur in Strings that contain characters.
>
>
> I’d say, please try to find possible empty strings
> that might perhaps be embedded e.g. in the string below:
>
> “Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42”
>
>
> With all due respect:
> This might void the discussion below :o)
>
> I have nothing against Mathematics as long
> as it is applicable.
>
>
> Kind Regards
> Ted
>
>
>
> To the question of whether any given string has the empty string as prefix:
> yes it does. This is a correct answer, and returning true is a correct
> behaviour.
>
> To the question of how many times the empty string occurs in a string: yes,
> this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" + "" + "" +
> "" == "a" + "" + "" + "" + "" == ... etc.. Concatenating an empty string,
> like adding zero or multiplying by zero for a numerical value, can be done
> infinitely many times without making a difference.
>
> However, there's correctness and convenience. For example, every integer
> can be expressed as a multiple of prime factors. 1 is technically a prime
> number - it's divisible by 1 and itself - but for convenience we say it
> isn't a prime number, because if it isn't, every integer can be expressed
> uniquely as a multiple of prime factors, whereas if it is, there are an
> infinite number of such expressions for each integer.
>
> There may be many algorithms which rely on an empty prefix returning false.
> If hasPrefix and hasSuffix are corrected, those algorithms should be
> altered to recognise that correction. For example, if breaking up a string
> using the empty string as a separator, it seems sensible