Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 21, 2016 at 9:26 PM, Xiaodi Wu  wrote:

> You kinda sent that to swift-evolution :P
>

Another painful reminder of why "oops" is a four-letter word...

Sorry!


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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

Well, it seems that I jumped the gun and sent my document link to
swift-evolution by mistake. Since I can't take it back, it might be good to
say what it's about. Because of my mistake, this version has *not* had any
review by the rest of the author group, which probably would have improved
it a lot. I had intended one more round of edits to deal with a few things
that still say "FIX" and a few minor cleanups, but I think the substance of
the proposal is sound.

This revised proposal

tries
to take into account most of the feedback we have received here. Lots of
nitty-gritty changes, but here's the big picture of the changes:

   - Emojis are admitted, subject to reasonable sanity conditions.
   - A (significantly) broader, but still conservative set of code points
   are admitted for symbol identifiers. Hopefully this addresses current need,
   but I remain open to adopting full-on [:Sm:] and [:So:] if there is a
   strong push for that.
   - Operator definition is orthogonal to identifier specification, which
   deals with the noun/verb confusion and also addresses the widely-expressed
   feeling that some symbols aren't operators and their conventional meaning
   should be usable. The term "operator" no longer has anything to do with
   identifiers.
   - A laundry list of potential parsing gotchas are addressed. The
   previous proposal would have broken the generics syntax and also the
   binding syntax. This isn't a substantive conceptual change, but it's
   important if the proposal is going to, you know, *actually work*. :-)
   - Dollar is admitted in identifiers.
   - Explicitly addresses anonymous closure parameters in a way that
   reflects how the compiler actually needs to deal with such things. Might be
   I've written a compiler or two in my career. :-)
   - Consistent with the current direction of UAX31 on these issues.
   - Susan Kare's legacy is preserved. :-) If you don't know who Susan is,
   look her up and learn why Chris loves the dogcow emoji pair.

The new proposal remains entirely compatible with Swift 3, except where
existing source runs up against the narrower symbol identifier space. It's
a specific goal to avoid breaking reasonable current practice where
possible, though we're surely going to break *something* with this one.

I was trained to write specifications in a school that favored rigorous
writing. In order to make sure I didn't lose track of something I rewrote
the proposal in a form that I know how to use effectively. Any loss of
"fun" in the text is my fault alone.

Interested to see how this will be received.


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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan S. Shapiro via swift-evolution]

Now for a position:

-1 on this proposal, because '$' should be legal in *any* identifier
position.

+1 for the proposal that '$' should be legal in *any* position.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan S. Shapiro via swift-evolution]

Several people here have called out implicit closure parameters as a
concern, which is actually irrelevant to adopting '$' in parameters.

It is perfectly feasible to accept '$' in parameters *generally*, and
reject identifiers of the form

$ followed by one or more decimal digits


in defining occurrences. This is completely compatible with current Swift
practice, and logically consistent with other kinds of reserved words.

I'm not taking a position pro or con here. I'm saying that we should reject
non-impacting arguments as a basis for deciding one way or the other.


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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan S. Shapiro via swift-evolution]

On Wed, Oct 19, 2016 at 1:02 PM, Kevin Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm actually vaguely surprised that the other currency symbols are
> considered valid identifiers, since they're not alphanumeric symbols. As
> for turning them into operators, it's a cute idea, but it doesn't work for
> any symbol that's used by multiple countries. For example, would $3.50 be
> USD, AUD, CAD, or any of the other dozens of countries that use dollars?
>

This is true, but not compelling. While using USD, AUD, CAD, and friends is
better practice for a truly internationalized code base, it does not follow
that use of $ for a more local-consumption code base should be rejected out
of hand.


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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan S. Shapiro via swift-evolution]

On Tue, Oct 18, 2016 at 7:20 AM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:

> It's s symbol. Here are some others:
> ! & * ( . -
>
> You wouldn't want to allow an identifier to start with any of those
> symbols, for obvious reasons.
>

That's an assertion. Can you substantiate?

Because I can think of a whole bunch of reasons for identifiers to start
with those, several languages in which they actually *do* start with those,
and significant benefit that accrues in those languages from admitting
these identifiers...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 14, 2016 at 1:53 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> I don’t think $ will be become available to be used as an operator if we
> remove its identifier use.
>

I'm about to put out a revised proposal for operators and symbol
identifiers that addresses this.


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

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

> On 22 Oct 2016, at 04:12, Karl  wrote:
> 
> 
>> On 22 Oct 2016, at 04:07, Karl > > wrote:
>> 
>> 
>>> On 22 Oct 2016, at 04:02, Braeden Profile >> > wrote:
>>> 
>>> But what would that mean?  If I reference `ProtocolName.InnerType`, that 
>>> doesn’t always have meaning.  In fact, if you have two different extensions 
>>> where AssociatedType equals something else, there’s a type ambiguity from 
>>> other code.  I suspect it would only work if that InnerType was mandated to 
>>> be `private`.
>> 
>> You would need a reference to a (ProtocolName where AssociatedType == Int), 
>> which you can get either from a `self` inside the extension or from a 
>> generic parameter:
>> 
>> struct MyValue : ProtocolName { typealias AssociatedType = T }
>> 
>> let _ = MyValue().InnerType()
> 
> No, wait - sorry, that’s wrong. I got confused for a second. You’re right; it 
> would have to be a private type.

Actually I think I take that back (I was just writing, lots of snippets 
floating around my head) - ProtocolName is a generic protocol, so types inside 
of it would become types on the concrete conformers. That’s consistent with the 
Editor.Delegate example in the draft proposal I linked to.

So MyValue.InnerType would exist  ProtocolName.InnerType isn’t really 
very meaningful otherwise.

- Karl

> 
>> 
>>> 
 On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution 
 > wrote:
 
 That option should not be disallowed. Here is a simple example you might 
 want to build at some point:
 
 protocol ProtocolName {
  
 associatedtype AssociatedType
 }
 
 extension ProtocolName where AssociatedType == Int {
   
 struct InnerType {}
 }
 
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 
 Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> Is your vision that each conforming type would have to provide its own 
> nested type as specified by the protocol?
> 
> Or could the protocol itself define a nested type and anything could use 
> it?
> 
> protocol FloatingPoint: … {
> enum RoundingRule {
> // Do I put an implementation here?
> }
> }
> 
> No, types which are defined inside the protocol are implemented there. 
> Providing your own types to satisfy a conformance is what associated 
> types are for.
> 
> If you wanted something like that, you could do it with a nested protocol 
> + associated type:
> 
> protocol FloatingPoint {
> 
> protocol _RoundingRule { func round(_ : Super) -> Super }
> associatedType RoundingRule : _RoundingRule
> }
> 
> struct Float : FloatingPoint {
> 
> enum RoundingRule : _RoundingRule {
> func round(_ val: Float) -> Float {
> /* switch self, perform rounding… */ 
> }
> }
> }
> 
> That brings up an interesting point, though - we would need a way to 
> refer to the outer protocol (I used “Super” here).
> 
 
 
 ___
 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] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

> On 22 Oct 2016, at 04:07, Karl  wrote:
> 
> 
>> On 22 Oct 2016, at 04:02, Braeden Profile > > wrote:
>> 
>> But what would that mean?  If I reference `ProtocolName.InnerType`, that 
>> doesn’t always have meaning.  In fact, if you have two different extensions 
>> where AssociatedType equals something else, there’s a type ambiguity from 
>> other code.  I suspect it would only work if that InnerType was mandated to 
>> be `private`.
> 
> You would need a reference to a (ProtocolName where AssociatedType == Int), 
> which you can get either from a `self` inside the extension or from a generic 
> parameter:
> 
> struct MyValue : ProtocolName { typealias AssociatedType = T }
> 
> let _ = MyValue().InnerType()

No, wait - sorry, that’s wrong. I got confused for a second. You’re right; it 
would have to be a private type.

> 
>> 
>>> On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> That option should not be disallowed. Here is a simple example you might 
>>> want to build at some point:
>>> 
>>> protocol ProtocolName {
>>>  
>>> associatedtype AssociatedType
>>> }
>>> 
>>> extension ProtocolName where AssociatedType == Int {
>>>   
>>> struct InnerType {}
>>> }
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 Is your vision that each conforming type would have to provide its own 
 nested type as specified by the protocol?
 
 Or could the protocol itself define a nested type and anything could use 
 it?
 
 protocol FloatingPoint: … {
 enum RoundingRule {
 // Do I put an implementation here?
 }
 }
 
 No, types which are defined inside the protocol are implemented there. 
 Providing your own types to satisfy a conformance is what associated types 
 are for.
 
 If you wanted something like that, you could do it with a nested protocol 
 + associated type:
 
 protocol FloatingPoint {
 
 protocol _RoundingRule { func round(_ : Super) -> Super }
 associatedType RoundingRule : _RoundingRule
 }
 
 struct Float : FloatingPoint {
 
 enum RoundingRule : _RoundingRule {
 func round(_ val: Float) -> Float {
 /* switch self, perform rounding… */ 
 }
 }
 }
 
 That brings up an interesting point, though - we would need a way to refer 
 to the outer protocol (I used “Super” here).
 
>>> 
>>> 
>>> ___
>>> 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] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

> On 22 Oct 2016, at 04:02, Braeden Profile  wrote:
> 
> But what would that mean?  If I reference `ProtocolName.InnerType`, that 
> doesn’t always have meaning.  In fact, if you have two different extensions 
> where AssociatedType equals something else, there’s a type ambiguity from 
> other code.  I suspect it would only work if that InnerType was mandated to 
> be `private`.

You would need a reference to a (ProtocolName where AssociatedType == Int), 
which you can get either from a `self` inside the extension or from a generic 
parameter:

struct MyValue : ProtocolName { typealias AssociatedType = T }

let _ = MyValue().InnerType()

> 
>> On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>> That option should not be disallowed. Here is a simple example you might 
>> want to build at some point:
>> 
>> protocol ProtocolName {
>>  
>> associatedtype AssociatedType
>> }
>> 
>> extension ProtocolName where AssociatedType == Int {
>>   
>> struct InnerType {}
>> }
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> Is your vision that each conforming type would have to provide its own 
>>> nested type as specified by the protocol?
>>> 
>>> Or could the protocol itself define a nested type and anything could use it?
>>> 
>>> protocol FloatingPoint: … {
>>> enum RoundingRule {
>>> // Do I put an implementation here?
>>> }
>>> }
>>> 
>>> No, types which are defined inside the protocol are implemented there. 
>>> Providing your own types to satisfy a conformance is what associated types 
>>> are for.
>>> 
>>> If you wanted something like that, you could do it with a nested protocol + 
>>> associated type:
>>> 
>>> protocol FloatingPoint {
>>> 
>>> protocol _RoundingRule { func round(_ : Super) -> Super }
>>> associatedType RoundingRule : _RoundingRule
>>> }
>>> 
>>> struct Float : FloatingPoint {
>>> 
>>> enum RoundingRule : _RoundingRule {
>>> func round(_ val: Float) -> Float {
>>> /* switch self, perform rounding… */ 
>>> }
>>> }
>>> }
>>> 
>>> That brings up an interesting point, though - we would need a way to refer 
>>> to the outer protocol (I used “Super” here).
>>> 
>> 
>> 
>> ___
>> 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] Nested types in protocols (and nesting protocols in types)

[Braeden Profile via swift-evolution]

But what would that mean?  If I reference `ProtocolName.InnerType`, that 
doesn’t always have meaning.  In fact, if you have two different extensions 
where AssociatedType equals something else, there’s a type ambiguity from other 
code.  I suspect it would only work if that InnerType was mandated to be 
`private`.

> On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> That option should not be disallowed. Here is a simple example you might want 
> to build at some point:
> 
> protocol ProtocolName {
>  
> associatedtype AssociatedType
> }
> 
> extension ProtocolName where AssociatedType == Int {
>   
> struct InnerType {}
> }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Is your vision that each conforming type would have to provide its own 
>> nested type as specified by the protocol?
>> 
>> Or could the protocol itself define a nested type and anything could use it?
>> 
>> protocol FloatingPoint: … {
>> enum RoundingRule {
>> // Do I put an implementation here?
>> }
>> }
>> 
>> No, types which are defined inside the protocol are implemented there. 
>> Providing your own types to satisfy a conformance is what associated types 
>> are for.
>> 
>> If you wanted something like that, you could do it with a nested protocol + 
>> associated type:
>> 
>> protocol FloatingPoint {
>> 
>> protocol _RoundingRule { func round(_ : Super) -> Super }
>> associatedType RoundingRule : _RoundingRule
>> }
>> 
>> struct Float : FloatingPoint {
>> 
>> enum RoundingRule : _RoundingRule {
>> func round(_ val: Float) -> Float {
>> /* switch self, perform rounding… */ 
>> }
>> }
>> }
>> 
>> That brings up an interesting point, though - we would need a way to refer 
>> to the outer protocol (I used “Super” here).
>> 
> 
> 
> ___
> 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] Nested types in protocols (and nesting protocols in types)

[Karl via swift-evolution]

I had a go at writing this up formally:

https://gist.github.com/karwa/4c6bff75f8fa84b16df2c8caae97d622 


Is there anything I missed?

- Karl

> On 17 Oct 2016, at 20:44, Adrian Zubarev  
> wrote:
> 
> That option should not be disallowed. Here is a simple example you might want 
> to build at some point:
> 
> protocol ProtocolName {
>  
> associatedtype AssociatedType
> }
> 
> extension ProtocolName where AssociatedType == Int {
>   
> struct InnerType {}
> }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Is your vision that each conforming type would have to provide its own 
>> nested type as specified by the protocol?
>> 
>> Or could the protocol itself define a nested type and anything could use it?
>> 
>> protocol FloatingPoint: … {
>> enum RoundingRule {
>> // Do I put an implementation here?
>> }
>> }
>> 
>> No, types which are defined inside the protocol are implemented there. 
>> Providing your own types to satisfy a conformance is what associated types 
>> are for.
>> 
>> If you wanted something like that, you could do it with a nested protocol + 
>> associated type:
>> 
>> protocol FloatingPoint {
>> 
>> protocol _RoundingRule { func round(_ : Super) -> Super }
>> associatedType RoundingRule : _RoundingRule
>> }
>> 
>> struct Float : FloatingPoint {
>> 
>> enum RoundingRule : _RoundingRule {
>> func round(_ val: Float) -> Float {
>> /* switch self, perform rounding… */ 
>> }
>> }
>> }
>> 
>> That brings up an interesting point, though - we would need a way to refer 
>> to the outer protocol (I used “Super” here).
>> 
> 
> 

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

Re: [swift-evolution] @noescape loop hole

[Robert Ryan via swift-evolution]

I’ll defer the question of whether it’s worth the effort or not to fix this. 
But even if we decide to make parameter closures non-escaping by default, but 
leave other closures escaping, there is still a problem here: If you mark a 
non-parameter closure as `@noescape`, you get a warning that incorrectly says 
"@noescape is the default and is deprecated”, even though it really is escaping 
by default in this context. If we’re not going to change all closures to be 
non-escaping by default in that context, we should fix the warnings. And I 
guess we should also confirm whether it really is truly deprecated or not 
(because `@noescape` appears to still work for these non-parameter closures).

> On Fri Aug 26 19:52:40 CDT 2016, Jordan Rose via swift-evolution 
>  wrote:
>
> That’s not really a loophole, because nothing unsafe can happen because of 
> it. It’s just a missing feature. Personally I think the added complexity from 
> allowing non-parameter closures to be marked non-escaping makes it not worth 
> the effort.
>
> Jordan

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro <
jonathan.s.shap...@gmail.com> wrote:

> On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> A few other thoughts:
>>
>> * One of our (or at least my) overarching goals for this proposal is to
>> refine identifier and operator sets by moving away from an ad-hoc
>> character-by-character approach to a systematic treatment that relies on
>> well-defined criteria to select blocks of characters for inclusion.
>>
>
> I completely agree with this, up to the point where you wrote "select
> blocks". That doesn't seem to be the way things are selected in the Unicode
> universe.
>
> We can choose to adopt blocks as an interim measure, but we should not
> loose sight of the notion that this should eventually be property-driven.
>
> * Particularly if the community insists on emoji being identifiers, we
>> will have to critically evaluate how to proceed on that in tandem with
>> operators, because there exist emojified operators and arrows, and certain
>> emoji are encoded in blocks that are otherwise symbols, which Unicode is
>> likely to deem as operators in the future.
>>
>
> This is not correct. The current view in the UAX31 discussion is that
> emojis and pictographics should be excluded from *both* types of
> identifiers so that individual programming languages can make
> language-specific choices.
>

This proposed approach raises some issues with apparent inconsistency as
well as forward compatibility issues. What I'm saying is that today, among
a chunk of symbols which Unicode may deem to be operators, there will be
some with emoji variants and others without. It seems kinda arbitrary to
exclude specific arrows or specific dingbats from valid operator characters
on the criterion that they have an emoji variant. For instance, if curly
leftwards arrow has an emoji variant but curly upwards arrow does not, one
is considered an invalid operator but the other is valid? Now, going
forward, if an existing codepoint is today part of IDC_Start but tomorrow
gains an emoji variant, what happens then?

The main current problem is that there is no clear-cut Unicode property
> covering Emojis at the present time, which is something that needs to be
> resolved over in Unicode-land. There is a list given in the antique texty
> UCD file format, but it isn't part of the XML formulation of the UCD
> database. I'll be generating a proposed update shortly, and when I have
> that I can provide a working list in the form of a C file that can be used
> by Swift.
>
> I have a mild preference that emojis should live in conventional
> identifiers if they are adopted.
>
>
>>  Moreover, IIUC, certain codepoints can be either emoji or non-emoji
>> symbols and variant selectors can specify which they are...
>>
>
> Can you expand on this and (hopefully) point me at the appropriate spot in
> one of the Unicode TRs?
>
>
> Thanks!
>
>
> Jonathan
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

On Fri, Oct 21, 2016 at 4:32 PM, Jonathan S. Shapiro <
jonathan.s.shap...@gmail.com> wrote:

> On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> A few other thoughts:
>>
>> * One of our (or at least my) overarching goals for this proposal is to
>> refine identifier and operator sets by moving away from an ad-hoc
>> character-by-character approach to a systematic treatment that relies on
>> well-defined criteria to select blocks of characters for inclusion.
>>
>
> I completely agree with this, up to the point where you wrote "select
> blocks". That doesn't seem to be the way things are selected in the Unicode
> universe.
>
> We can choose to adopt blocks as an interim measure, but we should not
> loose sight of the notion that this should eventually be property-driven.
>
> * Particularly if the community insists on emoji being identifiers, we
>> will have to critically evaluate how to proceed on that in tandem with
>> operators, because there exist emojified operators and arrows, and certain
>> emoji are encoded in blocks that are otherwise symbols, which Unicode is
>> likely to deem as operators in the future.
>>
>
> This is not correct. The current view in the UAX31 discussion is that
> emojis and pictographics should be excluded from *both* types of
> identifiers so that individual programming languages can make
> language-specific choices.
>
> The main current problem is that there is no clear-cut Unicode property
> covering Emojis at the present time, which is something that needs to be
> resolved over in Unicode-land. There is a list given in the antique texty
> UCD file format, but it isn't part of the XML formulation of the UCD
> database. I'll be generating a proposed update shortly, and when I have
> that I can provide a working list in the form of a C file that can be used
> by Swift.
>
> I have a mild preference that emojis should live in conventional
> identifiers if they are adopted.
>
>
>>  Moreover, IIUC, certain codepoints can be either emoji or non-emoji
>> symbols and variant selectors can specify which they are...
>>
>
> Can you expand on this and (hopefully) point me at the appropriate spot in
> one of the Unicode TRs?
>

Indeed. This issue first popped up on my radar when John Gruber wrote that
he had issues with his website displaying the curly arrow symbol as emoji
in recent browsers:

https://twitter.com/gruber/status/590355262281744384

Turns out, certain characters have emoji variants and text variants, which
can be selected for explicitly by appending a variant selector:

http://mts.io/2015/04/21/unicode-symbol-render-text-emoji/

However, whether the *default* presentation in the absence of a variant
selector is text or emoji can change from platform to platform, or from use
case to use case. This is explicitly spelled out in UTR#51:

"The presentation of a given emoji character depends on the environment,
whether or not there is an emoji or text variation selector, and the
default presentation style (emoji vs text). In informal environments like
texting and chats, it is more appropriate for most emoji characters to
appear with a colorful emoji presentation, and only get a text presentation
with a text variation selector. Conversely, in formal environments such as
word processing, it is generally better for emoji characters to appear with
a text presentation, and only get the colorful emoji presentation with the
emoji variation selector."

http://unicode.org/reports/tr51/#Presentation_Style


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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 21, 2016 at 1:51 PM, Martin Waitz via swift-evolution <
swift-evolution@swift.org> wrote:

> With the current difficulty to come up with an agreed set of identifies
> vs. operators, maybe we should really try to sidestep this issue entirely
> and study Jonathan Shapiro’s idea of using identifiers as operators.
>

Martin:

My "operators" proposal relies on resolving what will be a symbol
identifier, so I'm afraid we can't duck this issue.

I'm writing up a revised proposal as we speak. I'm hopeful that it will
address *most* of the concerns that have been expressed here, but it adopts
a slightly different conceptual approach than the previous one - enough so
that I don't think of it as a revision.

Because of the concern that Xiaodi just raised about emojis and modifiers,
I'm going to identify that as an open issue with an "if feasible" proposed
resolution to place them in the traditional identifier space.

I hope to be able to send a link to this list in a few hours.


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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> I think it is plainly evident that the well-defined criteria you would
> like to use *have not yet been defined* by Unicode. That is a large part of
> why I recommend that we postpone a major overhaul of our operator
> characters.
>

That's a feasible way to go, but keep in mind that the UAX31 changes are
being co-designed with and informed by the current discussion. There are a
bunch of things that have come up here that will allow UAX31 to side-step
some "might have happened" mistakes, so this discussion has been very
useful.

The Swift community can and should make its own decision about whether to
remain engaged. The risk of disengagement is that messy compatibility
issues will probably have to be faced later that we can easily head-off now.


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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Jonathan S. Shapiro via swift-evolution]

On Fri, Oct 21, 2016 at 1:10 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> A few other thoughts:
>
> * One of our (or at least my) overarching goals for this proposal is to
> refine identifier and operator sets by moving away from an ad-hoc
> character-by-character approach to a systematic treatment that relies on
> well-defined criteria to select blocks of characters for inclusion.
>

I completely agree with this, up to the point where you wrote "select
blocks". That doesn't seem to be the way things are selected in the Unicode
universe.

We can choose to adopt blocks as an interim measure, but we should not
loose sight of the notion that this should eventually be property-driven.

* Particularly if the community insists on emoji being identifiers, we will
> have to critically evaluate how to proceed on that in tandem with
> operators, because there exist emojified operators and arrows, and certain
> emoji are encoded in blocks that are otherwise symbols, which Unicode is
> likely to deem as operators in the future.
>

This is not correct. The current view in the UAX31 discussion is that
emojis and pictographics should be excluded from *both* types of
identifiers so that individual programming languages can make
language-specific choices.

The main current problem is that there is no clear-cut Unicode property
covering Emojis at the present time, which is something that needs to be
resolved over in Unicode-land. There is a list given in the antique texty
UCD file format, but it isn't part of the XML formulation of the UCD
database. I'll be generating a proposed update shortly, and when I have
that I can provide a working list in the form of a C file that can be used
by Swift.

I have a mild preference that emojis should live in conventional
identifiers if they are adopted.


>  Moreover, IIUC, certain codepoints can be either emoji or non-emoji
> symbols and variant selectors can specify which they are...
>

Can you expand on this and (hopefully) point me at the appropriate spot in
one of the Unicode TRs?


Thanks!


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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Nevin Brackett-Rozinsky via swift-evolution]

I think it is plainly evident that the well-defined criteria you would like
to use *have not yet been defined* by Unicode. That is a large part of why
I recommend that we postpone a major overhaul of our operator characters.

Furthermore, just like during the Great Renaming—when we used some general
rules to automate the name changes, then went through and fine-tuned by
hand to deal with cases where the automated rules produced suboptimal
results—I think it will be great if we can classify the majority of
characters all at once with certain criteria, but we should expect and plan
to go through by hand afterward to clean up the edge cases that humans can
tell were misplaced by the broad rules.

It is more important that we get the definitions of operator and identifier
characters *right* than that we make them *rigidly conform to a certain
rule*. If our rule says “∞” should be an operator, but we as humans
recognize that to be a mistake, then we should change it. Heck, maybe we
should make “∞” parse as a floating-point literal!

The point is, bikeshedding over operators has been and continues to be
diverting our collective attention away from the rest of the proposal, such
as using the IDC_Start and IDC_Continue categories that you mentioned.

Nevin



On Fri, Oct 21, 2016 at 4:10 PM, Xiaodi Wu  wrote:

> A few other thoughts:
>
> * One of our (or at least my) overarching goals for this proposal is to
> refine identifier and operator sets by moving away from an ad-hoc
> character-by-character approach to a systematic treatment that relies on
> well-defined criteria to select blocks of characters for inclusion. My
> personal opinion is that reverting to discussions of individual characters,
> such as the turned ampersand, means we're simply re-shuffling the current
> set of identifier and operator characters to a different one, having failed
> to discover any systematic basis for doing so. I think one of the strongest
> parts of this proposal is the straight-up statement that identifier start
> characters shall be IDC_Start and identifier continuation characters shall
> be IDC_Continue, modulo a few ASCII characters that require special
> treatment in Swift.
>
> * Particularly if the community insists on emoji being identifiers, we
> will have to critically evaluate how to proceed on that in tandem with
> operators, because there exist emojified operators and arrows, and certain
> emoji are encoded in blocks that are otherwise symbols, which Unicode is
> likely to deem as operators in the future. Moreover, IIUC, certain
> codepoints can be either emoji or non-emoji symbols and variant selectors
> can specify which they are, but in the absence of a variant selector
> *either* the emoji or non-emoji version can be correctly displayed
> depending on the platform. For some of these, the non-emoji version is
> either clearly or plausible an operator character. Therefore, without
> dealing *very* carefully with emoji and with operators at the same time, we
> are failing to address a key motivation of this proposal, which is to fix
> the incorrect separation between emoji operators and emoji identifiers.
>
>
> On Fri, Oct 21, 2016 at 2:36 PM, Xiaodi Wu  wrote:
>
>> I disagree pretty strongly with this approach. Firstly because as you've
>> pointed out, changes to the operator characters will have effects on valid
>> operator character sets, secondly because a major question about operators
>> is whether it is feasible or no to manually exclude empty set and infinity
>> given that Unicode is likely to reject that approach. For these reasons I
>> feel very strongly that the reforming the operator and identifier
>> characters must move in tandem.
>>
>> On Fri, Oct 21, 2016 at 14:28 Nevin Brackett-Rozinsky via swift-evolution
>>  wrote:
>>
>>> I think it is important that we as a community discuss the non-operator
>>> portion of this proposal. And, given the strong opinions about operators
>>> that have been expressed, I think it is unlikely we will do so while major
>>> operator changes are on the table.
>>>
>>> Thus I would suggest that either the operator changes should be
>>> separated out into their own proposal, or we should make only minor (and
>>> generally consensus-agreed) changes to the operator set as part of this one.
>>>
>>> Here is what I propose:
>>>
>>> Emoji shall be identifiers, not operators.
>>> The turned ampersand shall be an operator, not an identifier.
>>> The empty set and infinity symbols shall be identifiers, not operators.
>>>
>>> All other potential changes to the set of operator characters then go in
>>> their own proposal, which I am sure will receive a lot of attention.
>>>
>>> It may turn out that the non-operator portion of this proposal
>>> nonetheless touches characters that Swift has designated for operators, in
>>> which case we may address those as they arise.
>>>
>>> Does that sound like a reasonable way 

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Martin Waitz via swift-evolution]

With the current difficulty to come up with an agreed set of identifies vs. 
operators, maybe we should really try to sidestep this issue entirely and study 
Jonathan Shapiro’s idea of using identifiers as operators.

— Martin

> Am 21.10.2016 um 22:10 schrieb Xiaodi Wu via swift-evolution 
> :
> 
> A few other thoughts:
> 
> * One of our (or at least my) overarching goals for this proposal is to 
> refine identifier and operator sets by moving away from an ad-hoc 
> character-by-character approach to a systematic treatment that relies on 
> well-defined criteria to select blocks of characters for inclusion. My 
> personal opinion is that reverting to discussions of individual characters, 
> such as the turned ampersand, means we're simply re-shuffling the current set 
> of identifier and operator characters to a different one, having failed to 
> discover any systematic basis for doing so. I think one of the strongest 
> parts of this proposal is the straight-up statement that identifier start 
> characters shall be IDC_Start and identifier continuation characters shall be 
> IDC_Continue, modulo a few ASCII characters that require special treatment in 
> Swift.
> 
> * Particularly if the community insists on emoji being identifiers, we will 
> have to critically evaluate how to proceed on that in tandem with operators, 
> because there exist emojified operators and arrows, and certain emoji are 
> encoded in blocks that are otherwise symbols, which Unicode is likely to deem 
> as operators in the future. Moreover, IIUC, certain codepoints can be either 
> emoji or non-emoji symbols and variant selectors can specify which they are, 
> but in the absence of a variant selector *either* the emoji or non-emoji 
> version can be correctly displayed depending on the platform. For some of 
> these, the non-emoji version is either clearly or plausible an operator 
> character. Therefore, without dealing *very* carefully with emoji and with 
> operators at the same time, we are failing to address a key motivation of 
> this proposal, which is to fix the incorrect separation between emoji 
> operators and emoji identifiers.
> 
> 

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

A few other thoughts:

* One of our (or at least my) overarching goals for this proposal is to
refine identifier and operator sets by moving away from an ad-hoc
character-by-character approach to a systematic treatment that relies on
well-defined criteria to select blocks of characters for inclusion. My
personal opinion is that reverting to discussions of individual characters,
such as the turned ampersand, means we're simply re-shuffling the current
set of identifier and operator characters to a different one, having failed
to discover any systematic basis for doing so. I think one of the strongest
parts of this proposal is the straight-up statement that identifier start
characters shall be IDC_Start and identifier continuation characters shall
be IDC_Continue, modulo a few ASCII characters that require special
treatment in Swift.

* Particularly if the community insists on emoji being identifiers, we will
have to critically evaluate how to proceed on that in tandem with
operators, because there exist emojified operators and arrows, and certain
emoji are encoded in blocks that are otherwise symbols, which Unicode is
likely to deem as operators in the future. Moreover, IIUC, certain
codepoints can be either emoji or non-emoji symbols and variant selectors
can specify which they are, but in the absence of a variant selector
*either* the emoji or non-emoji version can be correctly displayed
depending on the platform. For some of these, the non-emoji version is
either clearly or plausible an operator character. Therefore, without
dealing *very* carefully with emoji and with operators at the same time, we
are failing to address a key motivation of this proposal, which is to fix
the incorrect separation between emoji operators and emoji identifiers.


On Fri, Oct 21, 2016 at 2:36 PM, Xiaodi Wu  wrote:

> I disagree pretty strongly with this approach. Firstly because as you've
> pointed out, changes to the operator characters will have effects on valid
> operator character sets, secondly because a major question about operators
> is whether it is feasible or no to manually exclude empty set and infinity
> given that Unicode is likely to reject that approach. For these reasons I
> feel very strongly that the reforming the operator and identifier
> characters must move in tandem.
>
> On Fri, Oct 21, 2016 at 14:28 Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think it is important that we as a community discuss the non-operator
>> portion of this proposal. And, given the strong opinions about operators
>> that have been expressed, I think it is unlikely we will do so while major
>> operator changes are on the table.
>>
>> Thus I would suggest that either the operator changes should be separated
>> out into their own proposal, or we should make only minor (and generally
>> consensus-agreed) changes to the operator set as part of this one.
>>
>> Here is what I propose:
>>
>> Emoji shall be identifiers, not operators.
>> The turned ampersand shall be an operator, not an identifier.
>> The empty set and infinity symbols shall be identifiers, not operators.
>>
>> All other potential changes to the set of operator characters then go in
>> their own proposal, which I am sure will receive a lot of attention.
>>
>> It may turn out that the non-operator portion of this proposal
>> nonetheless touches characters that Swift has designated for operators, in
>> which case we may address those as they arise.
>>
>> Does that sound like a reasonable way forward?
>>
>> Nevin
>>
>>
>>
>> On Fri, Oct 21, 2016 at 9:27 AM, Ben Rimmington via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> > On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
>> >
>> > Brackets and symbols are definitely operators.  Different brackets are
>> used to represent various quantum mechanical forms and operations.
>>
>> The brackets are mostly "bracket pieces":
>>
>> [:Math_Symbol:]
>> - [:name=/\bANGLE\b/:]
>> - [:Emoji:]
>> - [:ID_Continue:]
>> - [:NFC_Quick_Check=No:]
>> & [:Script_Extensions=Common:]
>> & [:Block=Miscellaneous_Technical:]
>>
>> > %5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%
>> 5Cb%2F%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%3AID_
>> Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%5D%
>> 0D%0A%26+%5B%3AScript_Extensions%3DCommon%3A%5D%0D%0A%26+%5B%3ABlock%
>> 3DMiscellaneous_Technical%3A%5D>
>>
>> > Arrows are also useful as operators, including but not restricted to
>> chemical reactions.
>>
>> Including arrows, there are 740 operators:
>>
>> [:Math_Symbol:]
>> - [:name=/\bANGLE\b/:]
>> - [:name=EMPTY SET:]
>> - [:name=INFINITY:]
>> - [:Emoji:]
>> - [:ID_Continue:]
>> - [:NFC_Quick_Check=No:]
>> & [:Script_Extensions=Common:]
>> & [[:Block=Arrows:]
>>

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Xiaodi Wu via swift-evolution]

I disagree pretty strongly with this approach. Firstly because as you've
pointed out, changes to the operator characters will have effects on valid
operator character sets, secondly because a major question about operators
is whether it is feasible or no to manually exclude empty set and infinity
given that Unicode is likely to reject that approach. For these reasons I
feel very strongly that the reforming the operator and identifier
characters must move in tandem.
On Fri, Oct 21, 2016 at 14:28 Nevin Brackett-Rozinsky via swift-evolution <
swift-evolution@swift.org> wrote:

> I think it is important that we as a community discuss the non-operator
> portion of this proposal. And, given the strong opinions about operators
> that have been expressed, I think it is unlikely we will do so while major
> operator changes are on the table.
>
> Thus I would suggest that either the operator changes should be separated
> out into their own proposal, or we should make only minor (and generally
> consensus-agreed) changes to the operator set as part of this one.
>
> Here is what I propose:
>
> Emoji shall be identifiers, not operators.
> The turned ampersand shall be an operator, not an identifier.
> The empty set and infinity symbols shall be identifiers, not operators.
>
> All other potential changes to the set of operator characters then go in
> their own proposal, which I am sure will receive a lot of attention.
>
> It may turn out that the non-operator portion of this proposal nonetheless
> touches characters that Swift has designated for operators, in which case
> we may address those as they arise.
>
> Does that sound like a reasonable way forward?
>
> Nevin
>
>
>
> On Fri, Oct 21, 2016 at 9:27 AM, Ben Rimmington via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> > On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
> >
> > Brackets and symbols are definitely operators.  Different brackets are
> used to represent various quantum mechanical forms and operations.
>
> The brackets are mostly "bracket pieces":
>
> [:Math_Symbol:]
> - [:name=/\bANGLE\b/:]
> - [:Emoji:]
> - [:ID_Continue:]
> - [:NFC_Quick_Check=No:]
> & [:Script_Extensions=Common:]
> & [:Block=Miscellaneous_Technical:]
>
> <
> http://www.unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%5Cb%2F%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%3AID_Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%5D%0D%0A%26+%5B%3AScript_Extensions%3DCommon%3A%5D%0D%0A%26+%5B%3ABlock%3DMiscellaneous_Technical%3A%5D
> >
>
> > Arrows are also useful as operators, including but not restricted to
> chemical reactions.
>
> Including arrows, there are 740 operators:
>
> [:Math_Symbol:]
> - [:name=/\bANGLE\b/:]
> - [:name=EMPTY SET:]
> - [:name=INFINITY:]
> - [:Emoji:]
> - [:ID_Continue:]
> - [:NFC_Quick_Check=No:]
> & [:Script_Extensions=Common:]
> & [[:Block=Arrows:]
>[:Block=General_Punctuation:]
>[:Block=Latin_1_Supplement:]
>[:Block=Mathematical_Operators:]
>[:Block=Miscellaneous_Mathematical_Symbols_A:]
>[:Block=Miscellaneous_Symbols_And_Arrows:]
>[:Block=Supplemental_Arrows_A:]
>[:Block=Supplemental_Arrows_B:]
>[:Block=Supplemental_Mathematical_Operators:]]
>
> <
> http://www.unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%5Cb%2F%3A%5D%0D%0A-+%5B%3Aname%3DEMPTY+SET%3A%5D%0D%0A-+%5B%3Aname%3DINFINITY%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%3AID_Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%5D%0D%0A%26+%5B%3AScript_Extensions%3DCommon%3A%5D%0D%0A%26+%5B%5B%3ABlock%3DArrows%3A%5D%0D%0A+++%5B%3ABlock%3DGeneral_Punctuation%3A%5D%0D%0A+++%5B%3ABlock%3DLatin_1_Supplement%3A%5D%0D%0A+++%5B%3ABlock%3DMathematical_Operators%3A%5D%0D%0A+++%5B%3ABlock%3DMiscellaneous_Mathematical_Symbols_A%3A%5D%0D%0A+++%5B%3ABlock%3DMiscellaneous_Symbols_And_Arrows%3A%5D%0D%0A+++%5B%3ABlock%3DSupplemental_Arrows_A%3A%5D%0D%0A+++%5B%3ABlock%3DSupplemental_Arrows_B%3A%5D%0D%0A+++%5B%3ABlock%3DSupplemental_Mathematical_Operators%3A%5D%5D
> >
>
> -- Ben
>
> ___
> 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] Refining Identifier and Operator Symbology

[Nevin Brackett-Rozinsky via swift-evolution]

I think it is important that we as a community discuss the non-operator
portion of this proposal. And, given the strong opinions about operators
that have been expressed, I think it is unlikely we will do so while major
operator changes are on the table.

Thus I would suggest that either the operator changes should be separated
out into their own proposal, or we should make only minor (and generally
consensus-agreed) changes to the operator set as part of this one.

Here is what I propose:

Emoji shall be identifiers, not operators.
The turned ampersand shall be an operator, not an identifier.
The empty set and infinity symbols shall be identifiers, not operators.

All other potential changes to the set of operator characters then go in
their own proposal, which I am sure will receive a lot of attention.

It may turn out that the non-operator portion of this proposal nonetheless
touches characters that Swift has designated for operators, in which case
we may address those as they arise.

Does that sound like a reasonable way forward?

Nevin



On Fri, Oct 21, 2016 at 9:27 AM, Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
> >
> > Brackets and symbols are definitely operators.  Different brackets are
> used to represent various quantum mechanical forms and operations.
>
> The brackets are mostly "bracket pieces":
>
> [:Math_Symbol:]
> - [:name=/\bANGLE\b/:]
> - [:Emoji:]
> - [:ID_Continue:]
> - [:NFC_Quick_Check=No:]
> & [:Script_Extensions=Common:]
> & [:Block=Miscellaneous_Technical:]
>
>  %5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%
> 5Cb%2F%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%3AID_
> Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%5D%
> 0D%0A%26+%5B%3AScript_Extensions%3DCommon%3A%5D%0D%0A%26+%5B%3ABlock%
> 3DMiscellaneous_Technical%3A%5D>
>
> > Arrows are also useful as operators, including but not restricted to
> chemical reactions.
>
> Including arrows, there are 740 operators:
>
> [:Math_Symbol:]
> - [:name=/\bANGLE\b/:]
> - [:name=EMPTY SET:]
> - [:name=INFINITY:]
> - [:Emoji:]
> - [:ID_Continue:]
> - [:NFC_Quick_Check=No:]
> & [:Script_Extensions=Common:]
> & [[:Block=Arrows:]
>[:Block=General_Punctuation:]
>[:Block=Latin_1_Supplement:]
>[:Block=Mathematical_Operators:]
>[:Block=Miscellaneous_Mathematical_Symbols_A:]
>[:Block=Miscellaneous_Symbols_And_Arrows:]
>[:Block=Supplemental_Arrows_A:]
>[:Block=Supplemental_Arrows_B:]
>[:Block=Supplemental_Mathematical_Operators:]]
>
>  %5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%
> 5Cb%2F%3A%5D%0D%0A-+%5B%3Aname%3DEMPTY+SET%3A%5D%0D%
> 0A-+%5B%3Aname%3DINFINITY%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%
> 0D%0A-+%5B%3AID_Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_
> Check%3DNo%3A%5D%0D%0A%26+%5B%3AScript_Extensions%3DCommon%
> 3A%5D%0D%0A%26+%5B%5B%3ABlock%3DArrows%3A%5D%0D%0A+++%5B%
> 3ABlock%3DGeneral_Punctuation%3A%5D%0D%0A+++%5B%3ABlock%
> 3DLatin_1_Supplement%3A%5D%0D%0A+++%5B%3ABlock%
> 3DMathematical_Operators%3A%5D%0D%0A+++%5B%3ABlock%
> 3DMiscellaneous_Mathematical_Symbols_A%3A%5D%0D%0A+++%5B%
> 3ABlock%3DMiscellaneous_Symbols_And_Arrows%3A%5D%0D%0A+++%5B%3ABlock%
> 3DSupplemental_Arrows_A%3A%5D%0D%0A+++%5B%3ABlock%
> 3DSupplemental_Arrows_B%3A%5D%0D%0A+++%5B%3ABlock%
> 3DSupplemental_Mathematical_Operators%3A%5D%5D>
>
> -- Ben
>
> ___
> 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] Non-class type requirements on protocols (eg : struct, : enum)

[Dave Abrahams via swift-evolution]

on Fri Oct 21 2016, Adrian Zubarev  wrote:

> Does this constraint exclude COW or are we still allowed to have a reference 
> type for storage behind
> the scenes?

It does not exclude CoW.  Array has value semantics.

> -- 
> Adrian Zubarev
> Sent with Airmail
>
> Am 21. Oktober 2016 um 19:50:31, Dave Abrahams via swift-evolution 
> (swift-evolution@swift.org)
> schrieb:
>
> I'm not sure what you mean by “data-only,” but the constraint I want is
> “has value semantics.”

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

Re: [swift-evolution] [Pitch] allow non-nominal type extension

[Jon Shier via swift-evolution]

It’s also the same as:

typealias CombinedProtocol = TrackCountProvider & PublishDateProvier

extension CombinedProtocol { } 

I, too, find the distinction largely pointless, but I’m not a language designer.


Jon

> On Oct 20, 2016, at 11:30 PM, Cao Jiannan via swift-evolution 
>  wrote:
> 
> It is just same as current grammar:
> 
> extension TrackCountProvider where Self : PublishDateProvider { ... }
> 
> with a more logical format
> 
> extension TrackCountProvider & PublishDateProvider { ... }
> 
> > e.g.
> > 
> > extensionTrackCountProvider{
> > vartrackCountAndPublishDateText:String{
> > varinfos: [String] = []
> > 
> > iflettrackCount = trackCount{
> > infos.append("\(trackCount)")
> > 
> > }
> > 
> > ifletpublishDateText = publishDate?.text {
> > infos.append(publishDateText)
> > }
> > 
> > returninfos.joined(separator: seperator)
> > }
> > }
> > 
> > 
> > 
> > 
> > 
> ___
> 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] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Kasianowicz via swift-evolution]

I mean essentially what is known as a POD type (plain ol' data) in C++.  A
data payload without clever features.

In this instance, I don't *necessarily* care about whether it's a struct or
class from a 10,000 foot level, so long as it can copy and is composed of
only other value types.  A struct constraint gets us half-way there, but
only incidentally by virtue of value semantics.

In the Cocoa APIs, these are often defined as an NSDictionary with
key-value pairs.  You could subclass NSDictionary and mess with the
consuming API... but it's pretty clear that the consuming API only wants
data and doesn't want you to get clever about it.

(Not to detract from the enum discussion, because I really like where
that's headed re:Tony's email.)

On Fri, Oct 21, 2016 at 12:37 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Fri Oct 21 2016, Mike Kasianowicz  wrote:
>
> > Hooray, I'm not the only one.
> >
> > I agree copying is a much more nuanced issue- but sometimes struct is
> close
> > enough.
> >
> > What I would really like is "this is a data-only type" rather than
> > "struct".
>
> I'm not sure what you mean by “data-only,” but the constraint I want is
> “has value semantics.”
>
> --
> -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] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Adrian Zubarev via swift-evolution]

Does this constraint exclude COW or are we still allowed to have a reference 
type for storage behind the scenes?

-- 
Adrian Zubarev
Sent with Airmail

Am 21. Oktober 2016 um 19:50:31, Dave Abrahams via swift-evolution 
(swift-evolution@swift.org) schrieb:

I'm not sure what you mean by “data-only,” but the constraint I want is
“has value semantics.”
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Dave Abrahams via swift-evolution]

on Fri Oct 21 2016, Mike Kasianowicz  wrote:

> Hooray, I'm not the only one.
>
> I agree copying is a much more nuanced issue- but sometimes struct is close
> enough.
>
> What I would really like is "this is a data-only type" rather than
> "struct".  

I'm not sure what you mean by “data-only,” but the constraint I want is
“has value semantics.”

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Kasianowicz via swift-evolution]

Hooray, I'm not the only one.

I agree copying is a much more nuanced issue- but sometimes struct is close
enough.

What I would really like is "this is a data-only type" rather than
"struct".  But short-term, I'd take the struct restriction if it's a simple
change. If we ever had a more specific constraint like that, my
hypothetical API will break many more clients if people have implemented my
protocol as a class.  I'm considering runtime enforcement, but this is
clearly something that the compiler can do, and the question is whether it
should.  I would argue yes - one of the great things about Swift is getting
your head out of the technical weeds and thinking at a higher level.

Protocol-oriented programming could be much more concise and allow for some
really awesome high-level things to be done and enforced - ex: MVC, MVVM,
MVP, VIPER whatever your UI approach is today - you could codify the
infrastructural paradigm and then require data-only types for the models,
or enum-only types for the events, to prevent dependency violations.  Great
for making frameworks safer, enforcing coding standards, etc.

Maybe long-term there could be user-defined constraints similar to the
proposed property decorator/annotation notation?

On Fri, Oct 21, 2016 at 11:38 AM, T.J. Usiyan  wrote:

> I would like the ability to specify that something is an enum so that I
> could model a generic `Result` type.
>
> ```
> protocol Result : enum {
> associatedtype Payload
> case success(Payload)
> case failure(Error)
> }
> ```
>
> the basic idea being that I could then, while conforming, state which
> cases in the concrete type serve as the protocol's case.  I don't have a
> great vision for the syntax of spelling this conformance so I will make
> this painfully verbose to be clear
>
> ```
> enum UserParseResult {
> case success(User)
> case failure(Error)
> }
>
> extension UserParseResult : Result {
> protocol(Result) case success = UserParseResult.success
> protocol(Result) case failure = UserParseResult.failure
> }
> ```
>
>
> The benefit of this, in my opinion, is that we could have code commonly
> used on results everywhere written once on the protocol without sacrificing
> the ability to switch with guarantees. I can see that this suggestion has
> some rough points so all I will finish by restating the problem that I want
> to solve.
>
> There is code that is fairly common to enum types that have shared
> characteristics and/or purpose. I would find it useful to have a way to
> implement shared algorithms in a generic way while retaining core features
> of enums.
>
> On Fri, Oct 21, 2016 at 11:11 AM, Mike Kasianowicz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Just from an outside perspective, the class restriction seems to be there
>> as a kludge for technical reasons... but that's neither here nor there.
>>
>> It is not so much to enforce a lack of identity - in the struct case, it
>> would be to enforce copy-by-value semantics.  I think the strongest
>> argument I've got is, say, a serialization or caching framework where you
>> want to enforce that something is entirely writeable via memory pointer or
>> copyable.  A value-type restriction would get us mostly there, albeit there
>> would still be ways to break the contract.  However, as noted in my
>> previous email, I see a lot of possibilities for enums too - in that case
>> the protocol somewhat acts as 'base type' without adding the complexity of
>> a base type.
>>
>> I listed some of my examples in my previous email - I could elaborate if
>> it helps.
>>
>> On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner  wrote:
>>
>>> IIRC, the reason we have "class" there is for the optimiser, so it can
>>> optimise for the protocol being satisfied by a reference-counted type.
>>> Classes are semantically unique from values because they have identity,
>>> which is also something a protocol might want to codify.
>>>
>>> There may be some optimisation gains by requiring all conformers to be
>>> values, but I struggle to think of why you might want to codify that a
>>> conformer should not have identity.
>>>
>>> Personally I don't really like this asymmetry in the language either,
>>> and would support changes to make these two elements more explicit. For
>>> example, a magic "hasIdentity" protocol which is automatically satisfied
>>> only by classes, and moving the optimisation guides to usage site (e.g.
>>> when declaring a variable of type MyProto, I could declare it of type
>>> AnyClass or AnyValue instead, to annotate this specific
>>> instance as being refcountable or not, without making such optimisation
>>> hints part of the MyProto definition)
>>>
>>> - Karl
>>>
>>>
>>> On Oct 21, 2016 at 8:39 am, >> > wrote:
>>>
>>> Currently protocols can have the class constraint:
>>> protocol MyProtocol : class {}
>>>
>>> It would be (a) intuitive and (b) useful to allow such 

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Tony Allevato via swift-evolution]

I'd like to spin this a slightly different way.

While they're not exactly the same as structs because the compiler has
separate logic for exhaustiveness checking, enum cases have some
interesting properties that make them relatable:

* A case without a payload is like a static read-only property on the enum
type that is equal to a value of that type.
* A case with a payload is like a static function on the enum type that
creates and returns a value of that type.

The second point is interesting because if you have:

```
enum Foo {
  case bar(Int)
}
```

and you reference "Foo.bar" without a payload, what you get back is a
function of type (Int) -> Foo.

So instead of casting your example as "a protocol can be enum-constrained
and must contain certain cases", what if enums could just have their
conformance fall out naturally from the bullet point observations above?

In other words, your example protocol could be:

```
protocol Result {
  associatedtype Payload
  static func success(_ p: Payload) -> Self
  static func failure(_ e: Error) -> Self
}
```

and the cases provide the conformance without having to do anything extra:

```
enum UserParseResult: Result {
  typealias Payload = User  // can be omitted if it's inferred
  case success(User)
  case failure(Error)
}
```

Now there's a caveat here worth discussing: would the intention of an
"enum-constrained protocol" be to define the *only* cases it can have, or
just the minimal set? The former would let you do some interesting generic
protocol-constrained exhaustive pattern matching. However, given that no
other use of protocols defines an *exact* set (you don't say these are the
*only* methods/properties that a conforming type can implement), I think it
would be a hard sell to apply a stronger restriction specifically to enums.
In any case, it feels to me like an enum restricted to "only these exact
cases" calls more for a generic enum rather than a protocol-based solution.


On Fri, Oct 21, 2016 at 9:39 AM T.J. Usiyan via swift-evolution <
swift-evolution@swift.org> wrote:

> I would like the ability to specify that something is an enum so that I
> could model a generic `Result` type.
>
> ```
> protocol Result : enum {
> associatedtype Payload
> case success(Payload)
> case failure(Error)
> }
> ```
>
> the basic idea being that I could then, while conforming, state which
> cases in the concrete type serve as the protocol's case.  I don't have a
> great vision for the syntax of spelling this conformance so I will make
> this painfully verbose to be clear
>
> ```
> enum UserParseResult {
> case success(User)
> case failure(Error)
> }
>
> extension UserParseResult : Result {
> protocol(Result) case success = UserParseResult.success
> protocol(Result) case failure = UserParseResult.failure
> }
> ```
>
>
> The benefit of this, in my opinion, is that we could have code commonly
> used on results everywhere written once on the protocol without sacrificing
> the ability to switch with guarantees. I can see that this suggestion has
> some rough points so all I will finish by restating the problem that I want
> to solve.
>
> There is code that is fairly common to enum types that have shared
> characteristics and/or purpose. I would find it useful to have a way to
> implement shared algorithms in a generic way while retaining core features
> of enums.
>
> On Fri, Oct 21, 2016 at 11:11 AM, Mike Kasianowicz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Just from an outside perspective, the class restriction seems to be there
> as a kludge for technical reasons... but that's neither here nor there.
>
> It is not so much to enforce a lack of identity - in the struct case, it
> would be to enforce copy-by-value semantics.  I think the strongest
> argument I've got is, say, a serialization or caching framework where you
> want to enforce that something is entirely writeable via memory pointer or
> copyable.  A value-type restriction would get us mostly there, albeit there
> would still be ways to break the contract.  However, as noted in my
> previous email, I see a lot of possibilities for enums too - in that case
> the protocol somewhat acts as 'base type' without adding the complexity of
> a base type.
>
> I listed some of my examples in my previous email - I could elaborate if
> it helps.
>
> On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner  wrote:
>
> IIRC, the reason we have "class" there is for the optimiser, so it can
> optimise for the protocol being satisfied by a reference-counted type.
> Classes are semantically unique from values because they have identity,
> which is also something a protocol might want to codify.
>
> There may be some optimisation gains by requiring all conformers to be
> values, but I struggle to think of why you might want to codify that a
> conformer should not have identity.
>
> Personally I don't really like this asymmetry in the language either, and
> would support 

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Dave Abrahams via swift-evolution]

on Thu Oct 20 2016, Guoye Zhang  wrote:

> I propose to ban the top value in Int/UInt which is 0x... in
> hex. Int family would lose its smallest value, and UInt family
> would lose its largest value. Top value is reserved for nil in
> optionals. An additional benefit is that negating an Int would
> never crash.
 
 Well the “top value” for signed ints would have to be
 0x8000... not 0x... which is the representation of -1. The top
 value for unsigned ints cannot be banned because unsigned integers
 are often used as bit fields either directly or in OptionSets.
 
 Furthermore, how would the semantics of &+ and &- be affected? What
 about the performance of those two operators?
 
>>> I was originally going for the symmetry between Int and UInt as in
>>> compatible bit patterns. Now that I think of it, UInt is commonly
>>> used for bitwise operations, and it doesn't make sense to optimize
>>> for "UInt?" which is uncommon. So I agree that 0x80... is better.
>>> 
>>> Int performance would surely suffer because of current instruction sets, 
>>> but Int? would improve.
>> 
>> I wouldn’t want to trade Int performance off against Int?
>> performance. I think the former is much more common.
>
> Slowing down Int is never my intent. I hope to have Int? that gives on
> par performance with Int, and the possibility to have safe arithmetics
> that doesn't impose overhead.

Swift arithmetic is already safe.

-- 
-Dave

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

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[T.J. Usiyan via swift-evolution]

I would like the ability to specify that something is an enum so that I
could model a generic `Result` type.

```
protocol Result : enum {
associatedtype Payload
case success(Payload)
case failure(Error)
}
```

the basic idea being that I could then, while conforming, state which cases
in the concrete type serve as the protocol's case.  I don't have a great
vision for the syntax of spelling this conformance so I will make this
painfully verbose to be clear

```
enum UserParseResult {
case success(User)
case failure(Error)
}

extension UserParseResult : Result {
protocol(Result) case success = UserParseResult.success
protocol(Result) case failure = UserParseResult.failure
}
```


The benefit of this, in my opinion, is that we could have code commonly
used on results everywhere written once on the protocol without sacrificing
the ability to switch with guarantees. I can see that this suggestion has
some rough points so all I will finish by restating the problem that I want
to solve.

There is code that is fairly common to enum types that have shared
characteristics and/or purpose. I would find it useful to have a way to
implement shared algorithms in a generic way while retaining core features
of enums.

On Fri, Oct 21, 2016 at 11:11 AM, Mike Kasianowicz via swift-evolution <
swift-evolution@swift.org> wrote:

> Just from an outside perspective, the class restriction seems to be there
> as a kludge for technical reasons... but that's neither here nor there.
>
> It is not so much to enforce a lack of identity - in the struct case, it
> would be to enforce copy-by-value semantics.  I think the strongest
> argument I've got is, say, a serialization or caching framework where you
> want to enforce that something is entirely writeable via memory pointer or
> copyable.  A value-type restriction would get us mostly there, albeit there
> would still be ways to break the contract.  However, as noted in my
> previous email, I see a lot of possibilities for enums too - in that case
> the protocol somewhat acts as 'base type' without adding the complexity of
> a base type.
>
> I listed some of my examples in my previous email - I could elaborate if
> it helps.
>
> On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner  wrote:
>
>> IIRC, the reason we have "class" there is for the optimiser, so it can
>> optimise for the protocol being satisfied by a reference-counted type.
>> Classes are semantically unique from values because they have identity,
>> which is also something a protocol might want to codify.
>>
>> There may be some optimisation gains by requiring all conformers to be
>> values, but I struggle to think of why you might want to codify that a
>> conformer should not have identity.
>>
>> Personally I don't really like this asymmetry in the language either, and
>> would support changes to make these two elements more explicit. For
>> example, a magic "hasIdentity" protocol which is automatically satisfied
>> only by classes, and moving the optimisation guides to usage site (e.g.
>> when declaring a variable of type MyProto, I could declare it of type
>> AnyClass or AnyValue instead, to annotate this specific
>> instance as being refcountable or not, without making such optimisation
>> hints part of the MyProto definition)
>>
>> - Karl
>>
>>
>> On Oct 21, 2016 at 8:39 am, > > wrote:
>>
>> Currently protocols can have the class constraint:
>> protocol MyProtocol : class {}
>>
>> It would be (a) intuitive and (b) useful to allow such things as:
>> protocol Model : struct {} or protocol Event : enum {}
>>
>> These types of restrictions can help prevent accidental anti-patterns or
>> misuse of APIs.
>>
>> Seems simple and non-controversial... right?
>>
>> [Note: I'd like to see even more heavy-handed protocol restrictions in
>> the future.  For example, a protocol describing an enum with a common case,
>> or a struct with no reference members. Great stuff for defensively coding
>> APIs.]
>> ___ swift-evolution mailing
>> list swift-evolution@swift.org https://lists.swift.org/mailma
>> n/listinfo/swift-evolution
>>
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Karl Wagner via swift-evolution]

 
 
Copying is a much more nuanced issue than just reference-or-value though. I 
would also support some good copying protocols in the standard library, but 
that's additive.
 
   
 
 
 

 
 
 
 

 
 
>  
> On Oct 21, 2016 at 5:11 pm,  mailto:m...@ap14.com)>  wrote:
>  
>  
>  
> Just from an outside perspective, the class restriction seems to be there as 
> a kludge for technical reasons... but that's neither here nor there. 
>
>  
> It is not so much to enforce a lack of identity - in the struct case, it 
> would be to enforce copy-by-value semantics.I think the strongest 
> argument I've got is, say, a serialization or caching framework where you 
> want to enforce that something is entirely writeable via memory pointer or 
> copyable.A value-type restriction would get us mostly there, albeit there 
> would still be ways to break the contract.However, as noted in my 
> previous email, I see a lot of possibilities for enums too - in that case the 
> protocol somewhat acts as 'base type' without adding the complexity of a base 
> type.
>  
>
>  
> I listed some of my examples in my previous email - I could elaborate if it 
> helps.
>
>
>  
> On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner   (mailto:razie...@gmail.com)>  wrote:
>  
> >  
> >  
> >  
> > IIRC, the reason we have "class" there is for the optimiser, so it can 
> > optimise for the protocol being satisfied by a reference-counted type. 
> > Classes are semantically unique from values because they have identity, 
> > which is also something a protocol might want to codify.
> >  
> >
> >  
> > There may be some optimisation gains by requiring all conformers to be 
> > values, but   I struggle to think of why you might want to codify that a 
> > conformer should not have identity.
> >  
> >
> >  
> > Personally I don't really like this asymmetry in the language either, and 
> > would support changes to make these two elements more explicit. For 
> > example, a magic "hasIdentity" protocol which is automatically satisfied 
> > only by classes, and moving the optimisation guides to usage site (e.g. 
> > when declaring a variable of type MyProto, I could declare it of type 
> > AnyClass  or AnyValue  instead, to annotate this specific 
> > instance as being refcountable or not, without making such optimisation 
> > hints part of the MyProto definition)
> >
> >  
> >  
> >  
> >  
> >
> >  
> >  
> > - Karl
> >  
> >  
> >  
> >
> >  
> >  
> > >  
> > >  
> > >  
> > > On Oct 21, 2016 at 8:39 am,   > > (mailto:swift-evolution@swift.org)>  wrote:
> > >  
> > >  
> > >  
> > >  
> > >  
> > > Currently protocols can have the class constraint: 
> > > protocol MyProtocol : class {}
> > >  
> > >
> > >  
> > > It would be (a) intuitive and (b) useful to allow such things as:
> > >  
> > > protocol Model : struct {} or protocol Event : enum {}
> > >  
> > >
> > >  
> > > These types of restrictions can help prevent accidental anti-patterns or 
> > > misuse of APIs.
> > >  
> > >
> > >  
> > > Seems simple and non-controversial... right?
> > >  
> > >
> > >  
> > > [Note: I'd like to see even more heavy-handed protocol restrictions in 
> > > the future.For example, a protocol describing an enum with a common 
> > > case, or a struct with no reference members. Great stuff for defensively 
> > > coding APIs.]
> > >  
> > >  
> > >  
> > >   ___ swift-evolution mailing 
> > > list  swift-evolution@swift.org (mailto:swift-evolution@swift.org)   
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >  
> >  
> >  
> >  
> >  
>  
>  
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Adrian Zubarev via swift-evolution]

This is the thread that I mentioned before: Should we rename “class” when 
referring to protocol conformance?



-- 
Adrian Zubarev
Sent with Airmail

Am 21. Oktober 2016 um 17:12:37, Mike Kasianowicz via swift-evolution 
(swift-evolution@swift.org) schrieb:

Just from an outside perspective, the class restriction seems to be there as a 
kludge for technical reasons... but that's neither here nor there.

It is not so much to enforce a lack of identity - in the struct case, it would 
be to enforce copy-by-value semantics.  I think the strongest argument I've got 
is, say, a serialization or caching framework where you want to enforce that 
something is entirely writeable via memory pointer or copyable.  A value-type 
restriction would get us mostly there, albeit there would still be ways to 
break the contract.  However, as noted in my previous email, I see a lot of 
possibilities for enums too - in that case the protocol somewhat acts as 'base 
type' without adding the complexity of a base type.

I listed some of my examples in my previous email - I could elaborate if it 
helps.

On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner  wrote:
IIRC, the reason we have "class" there is for the optimiser, so it can optimise 
for the protocol being satisfied by a reference-counted type. Classes are 
semantically unique from values because they have identity, which is also 
something a protocol might want to codify.

There may be some optimisation gains by requiring all conformers to be values, 
but I struggle to think of why you might want to codify that a conformer should 
not have identity.

Personally I don't really like this asymmetry in the language either, and would 
support changes to make these two elements more explicit. For example, a magic 
"hasIdentity" protocol which is automatically satisfied only by classes, and 
moving the optimisation guides to usage site (e.g. when declaring a variable of 
type MyProto, I could declare it of type AnyClass or AnyValue 
instead, to annotate this specific instance as being refcountable or not, 
without making such optimisation hints part of the MyProto definition)

- Karl


On Oct 21, 2016 at 8:39 am,  wrote:

Currently protocols can have the class constraint:
protocol MyProtocol : class {}

It would be (a) intuitive and (b) useful to allow such things as:
protocol Model : struct {} or protocol Event : enum {}

These types of restrictions can help prevent accidental anti-patterns or misuse 
of APIs.

Seems simple and non-controversial... right?

[Note: I'd like to see even more heavy-handed protocol restrictions in the 
future.  For example, a protocol describing an enum with a common case, or a 
struct with no reference members. Great stuff for defensively coding APIs.]
___ 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] clang auto-attaching @discardableResult attribute on imported declarations

[Pär Strindevall via swift-evolution]

Hey!

I got sick of having to assign unused results with _ = when using Objective-C 
dependencies so I decided to fork and fix the one I was using before finishing 
the line. When I searched for solutions to the problem I stumbled upon SE-0047 
here: https://bugs.swift.org/browse/SR-1052 


I noted that suggested patch 3 was to change the clang importer to attach 
@discardableResult automatically to imported declarations like the one I was 
using. Did this not happen? Is there any way for me to suppress the warnings 
that flood Xcode when not assigning unused results to nada if the dependency 
I’m bleep-blooping with is implemented in Objective-C?

Swiftly,

Pär Strindevall___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Kasianowicz via swift-evolution]

Just from an outside perspective, the class restriction seems to be there
as a kludge for technical reasons... but that's neither here nor there.

It is not so much to enforce a lack of identity - in the struct case, it
would be to enforce copy-by-value semantics.  I think the strongest
argument I've got is, say, a serialization or caching framework where you
want to enforce that something is entirely writeable via memory pointer or
copyable.  A value-type restriction would get us mostly there, albeit there
would still be ways to break the contract.  However, as noted in my
previous email, I see a lot of possibilities for enums too - in that case
the protocol somewhat acts as 'base type' without adding the complexity of
a base type.

I listed some of my examples in my previous email - I could elaborate if it
helps.

On Fri, Oct 21, 2016 at 9:51 AM, Karl Wagner  wrote:

> IIRC, the reason we have "class" there is for the optimiser, so it can
> optimise for the protocol being satisfied by a reference-counted type.
> Classes are semantically unique from values because they have identity,
> which is also something a protocol might want to codify.
>
> There may be some optimisation gains by requiring all conformers to be
> values, but I struggle to think of why you might want to codify that a
> conformer should not have identity.
>
> Personally I don't really like this asymmetry in the language either, and
> would support changes to make these two elements more explicit. For
> example, a magic "hasIdentity" protocol which is automatically satisfied
> only by classes, and moving the optimisation guides to usage site (e.g.
> when declaring a variable of type MyProto, I could declare it of type
> AnyClass or AnyValue instead, to annotate this specific
> instance as being refcountable or not, without making such optimisation
> hints part of the MyProto definition)
>
> - Karl
>
>
> On Oct 21, 2016 at 8:39 am,  > wrote:
>
> Currently protocols can have the class constraint:
> protocol MyProtocol : class {}
>
> It would be (a) intuitive and (b) useful to allow such things as:
> protocol Model : struct {} or protocol Event : enum {}
>
> These types of restrictions can help prevent accidental anti-patterns or
> misuse of APIs.
>
> Seems simple and non-controversial... right?
>
> [Note: I'd like to see even more heavy-handed protocol restrictions in the
> future.  For example, a protocol describing an enum with a common case, or
> a struct with no reference members. Great stuff for defensively coding
> APIs.]
> ___ 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] Non-class type requirements on protocols (eg : struct, : enum)

[Karl Wagner via swift-evolution]

 
 
IIRC, the reason we have "class" there is for the optimiser, so it can optimise 
for the protocol being satisfied by a reference-counted type. Classes are 
semantically unique from values because they have identity, which is also 
something a protocol might want to codify.
 

 
There may be some optimisation gains by requiring all conformers to be values, 
but   I struggle to think of why you might want to codify that a conformer 
should not have identity.
 
 
 
Personally I don't really like this asymmetry in the language either, and would 
support changes to make these two elements more explicit. For example, a magic 
"hasIdentity" protocol which is automatically satisfied only by classes, and 
moving the optimisation guides to usage site (e.g. when declaring a variable of 
type MyProto, I could declare it of type AnyClass  or 
AnyValue  instead, to annotate this specific instance as being 
refcountable or not, without making such optimisation hints part of the MyProto 
definition)
 
 
 
 
 

 
 
- Karl
 
 
 

 
 
>  
> On Oct 21, 2016 at 8:39 am,   (mailto:swift-evolution@swift.org)>  wrote:
>  
>  
>  
> Currently protocols can have the class constraint: 
> protocol MyProtocol : class {}
>  
>
>  
> It would be (a) intuitive and (b) useful to allow such things as:
>  
> protocol Model : struct {} or protocol Event : enum {}
>  
>
>  
> These types of restrictions can help prevent accidental anti-patterns or 
> misuse of APIs.
>  
>
>  
> Seems simple and non-controversial... right?
>  
>
>  
> [Note: I'd like to see even more heavy-handed protocol restrictions in the 
> future.For example, a protocol describing an enum with a common case, or 
> a struct with no reference members. Great stuff for defensively coding APIs.]
>  
>  ___ swift-evolution mailing list 
>  swift-evolution@swift.org (mailto:swift-evolution@swift.org)   
> https://lists.swift.org/mailman/listinfo/swift-evolution
>  
 
 
 ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Mike Kasianowicz via swift-evolution]

Apologies- I did try finding existing documentation or discussion, but all
I found was a stack overflow question asking how to do this.

The way I see it, it would be as simple as implicitly declaring protocols
on a type when a type is declared: class implies ReferenceType, struct
implies ValueType, etc.

In my opinion, this is very similar to the open/sealed argument about class
inheritance.  The API should be able to more strictly communicate the
protocol usage, so it can provide more built-in functionality and better
establish its contract with the consuming code.

I can see some interesting scenarios like-

// API can return success, but relies on dependency injection to
communicate other results
protocol Result : EnumType {
case success
}

---
// serialization/communication frameworks
protocol Payload : ValueType, OnlyDataType {
}

class MyPayload : Payload { } // error

---

// this type is a collection of types and not a concrete type. it better
indicates intent.
protocol ModuleDefinition : ProtocolType {
associatedtype View
associatedtype Model
// etc
}




On Fri, Oct 21, 2016 at 3:25 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> We had similar talks about that topic before. There is a thread somewhere
> on this, but it’s mainly focused on value type semantics.
>
> If I remember correctly we might even discussed to remove the class
> constraint completely from the language and introduce a protocol solution
> to this problem.
>
> There are also some words about the class constraint in the
> GenericsManifesto.md
> 
>
> Generalized class constraints
>
> The class constraint can currently only be used for defining protocols.
> We could generalize it to associated type and type parameter declarations,
> e.g.,
>
> protocol P {
>  associatedtype A : class
> }
>
> func foo(t: T) { }
>
> As part of this, the magical AnyObject protocol could be replaced with an
> existential with a class bound, so that it becomes a typealias:
>
> typealias AnyObject = protocol
>
> See the “Existentials” section, particularly “Generalized existentials”,
> for more information.
>
>
>-
>
>Instead of : class we might use : AnyObject as a constraint (or :
>AnyReference?).
>-
>
>Instead of : struct/enum we should have something like : value or even
>better : AnyValue.
>
> --
>
> I believe we should focus on existential types first before fixing this
> gap in Swift. Any might receive the mentioned constraints and could
> create something like this:
>
> typealias AnyObject = Any
> typealias AnyValue = Any
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 21. Oktober 2016 um 08:55:40, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> What's your use case for distinguishing structs and enums?
> On Fri, Oct 21, 2016 at 1:40 AM Mike Kasianowicz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Currently protocols can have the class constraint:
>> protocol MyProtocol : class {}
>>
>> It would be (a) intuitive and (b) useful to allow such things as:
>> protocol Model : struct {} or protocol Event : enum {}
>>
>> These types of restrictions can help prevent accidental anti-patterns or
>> misuse of APIs.
>>
>> Seems simple and non-controversial... right?
>>
>> [Note: I'd like to see even more heavy-handed protocol restrictions in
>> the future.  For example, a protocol describing an enum with a common case,
>> or a struct with no reference members. Great stuff for defensively coding
>> APIs.]
>> ___
>> 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] Refining Identifier and Operator Symbology

[Ben Rimmington via swift-evolution]

> On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
> 
> Brackets and symbols are definitely operators.  Different brackets are used 
> to represent various quantum mechanical forms and operations.

The brackets are mostly "bracket pieces":

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [:Block=Miscellaneous_Technical:]



> Arrows are also useful as operators, including but not restricted to chemical 
> reactions.

Including arrows, there are 740 operators:

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:name=EMPTY SET:]
- [:name=INFINITY:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [[:Block=Arrows:]
   [:Block=General_Punctuation:]
   [:Block=Latin_1_Supplement:]
   [:Block=Mathematical_Operators:]
   [:Block=Miscellaneous_Mathematical_Symbols_A:]
   [:Block=Miscellaneous_Symbols_And_Arrows:]
   [:Block=Supplemental_Arrows_A:]
   [:Block=Supplemental_Arrows_B:]
   [:Block=Supplemental_Mathematical_Operators:]]



-- Ben

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Benjamin Spratling via swift-evolution]

Brackets and symbols are definitely operators.  Different brackets are used to 
represent various quantum mechanical forms and operations.
Arrows are also useful as operators, including but not restricted to chemical 
reactions.

-Ben

Sent from my iPhone.

> On Oct 21, 2016, at 7:20 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 20 Oct 2016, at 15:29, Jonathan S. Shapiro wrote:
>> 
>> Quick poll as a sanity check on a possible alternative for operators:
>> 
>> If we admitted [:Sm:] and [:So:] and the traditional ASCII operator 
>> characters, would that cover the things that people currently feel 
>> passionate about? That would almost certainly be compliant with UAX31 once 
>> it settles, and I think it covers all of the cases people have raised here.
> 
> I'd exclude [:So:], arrows, brackets and "Miscellaneous Mathematical Symbols 
> B".
> 
>[:Math_Symbol:]
>- [:name=/\bANGLE\b/:]
>- [:name=EMPTY SET:]
>- [:name=INFINITY:]
>- [:Emoji:]
>- [:ID_Continue:]
>- [:NFC_Quick_Check=No:]
>& [:Script_Extensions=Common:]
>& [[:Block=Latin_1_Supplement:]
>   [:Block=General_Punctuation:]
>   [:Block=Mathematical_Operators:]
>   [:Block=Miscellaneous_Mathematical_Symbols_A:]
>   [:Block=Supplemental_Mathematical_Operators:]]
> 
> 
> 
> Is there a property to test for "pictographic" characters?
> 
> -- Ben
> 
> ___
> 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] Refining Identifier and Operator Symbology

[Ben Rimmington via swift-evolution]

> On 20 Oct 2016, at 15:29, Jonathan S. Shapiro wrote:
> 
> Quick poll as a sanity check on a possible alternative for operators:
> 
> If we admitted [:Sm:] and [:So:] and the traditional ASCII operator 
> characters, would that cover the things that people currently feel passionate 
> about? That would almost certainly be compliant with UAX31 once it settles, 
> and I think it covers all of the cases people have raised here.

I'd exclude [:So:], arrows, brackets and "Miscellaneous Mathematical Symbols B".

[:Math_Symbol:]
- [:name=/\bANGLE\b/:]
- [:name=EMPTY SET:]
- [:name=INFINITY:]
- [:Emoji:]
- [:ID_Continue:]
- [:NFC_Quick_Check=No:]
& [:Script_Extensions=Common:]
& [[:Block=Latin_1_Supplement:]
   [:Block=General_Punctuation:]
   [:Block=Mathematical_Operators:]
   [:Block=Miscellaneous_Mathematical_Symbols_A:]
   [:Block=Supplemental_Mathematical_Operators:]]



Is there a property to test for "pictographic" characters?

-- Ben

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

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Adrian Zubarev via swift-evolution]

We had similar talks about that topic before. There is a thread somewhere on 
this, but it’s mainly focused on value type semantics.

If I remember correctly we might even discussed to remove the class constraint 
completely from the language and introduce a protocol solution to this problem.

There are also some words about the class constraint in the GenericsManifesto.md

Generalized class constraints

The class constraint can currently only be used for defining protocols. We 
could generalize it to associated type and type parameter declarations, e.g.,

protocol P {
 associatedtype A : class
}

func foo(t: T) { }
As part of this, the magical AnyObject protocol could be replaced with an 
existential with a class bound, so that it becomes a typealias:

typealias AnyObject = protocol
See the “Existentials” section, particularly “Generalized existentials”, for 
more information.
Instead of : class we might use : AnyObject as a constraint (or : 
AnyReference?).

Instead of : struct/enum we should have something like : value or even better : 
AnyValue.

I believe we should focus on existential types first before fixing this gap in 
Swift. Any might receive the mentioned constraints and could create 
something like this:

typealias AnyObject = Any
typealias AnyValue = Any


-- 
Adrian Zubarev
Sent with Airmail

Am 21. Oktober 2016 um 08:55:40, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

What's your use case for distinguishing structs and enums?
On Fri, Oct 21, 2016 at 1:40 AM Mike Kasianowicz via swift-evolution 
 wrote:
Currently protocols can have the class constraint:
protocol MyProtocol : class {}

It would be (a) intuitive and (b) useful to allow such things as:
protocol Model : struct {} or protocol Event : enum {}

These types of restrictions can help prevent accidental anti-patterns or misuse 
of APIs.

Seems simple and non-controversial... right?

[Note: I'd like to see even more heavy-handed protocol restrictions in the 
future.  For example, a protocol describing an enum with a common case, or a 
struct with no reference members. Great stuff for defensively coding APIs.]
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

[Xiaodi Wu via swift-evolution]

What's your use case for distinguishing structs and enums?
On Fri, Oct 21, 2016 at 1:40 AM Mike Kasianowicz via swift-evolution <
swift-evolution@swift.org> wrote:

> Currently protocols can have the class constraint:
> protocol MyProtocol : class {}
>
> It would be (a) intuitive and (b) useful to allow such things as:
> protocol Model : struct {} or protocol Event : enum {}
>
> These types of restrictions can help prevent accidental anti-patterns or
> misuse of APIs.
>
> Seems simple and non-controversial... right?
>
> [Note: I'd like to see even more heavy-handed protocol restrictions in the
> future.  For example, a protocol describing an enum with a common case, or
> a struct with no reference members. Great stuff for defensively coding
> APIs.]
> ___
> 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