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

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:

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

e.g. extension TrackCountProvider & PublishDateProvider { var trackCountAndPublishDateText: String { var infos: [String] = [] if let trackCount = trackCount { infos.append("\(trackCount)") } if let publishDateText =

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

On Thu, Oct 20, 2016 at 12:25 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Would it be possible to do the following: > > • Have 1 group which are always used as identifiers. This would probably > be the identifiers from this proposal. > > • Have a 2nd group which

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

> On Oct 20, 2016, at 2:52 AM, Benjamin Spratling via swift-evolution > wrote: > > struct Note { > /// half-steps from middle-C, nil means the note is a rest > var pitch:Int? > //more properties > init?(xmlNode: XMLNode) { > if

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

On Thu, Oct 20, 2016 at 9:29 AM, Jonathan S. Shapiro via swift-evolution < swift-evolution@swift.org> 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

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

> On Oct 20, 2016, at 8:25 AM, Haravikk via swift-evolution > wrote: > > >> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution >> wrote: >> >> Hello, >> >>> It's just that a common data type wasting almost half the space seems

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

On Thu, Oct 20, 2016 at 8:22 AM, Alex Blewitt wrote: > The "Symbol, Other" category contains "Sign of the Horns" 落 which was > one of the problems with the identifier/operator that kicked off these > discussions. > Actually not. In the interests of sanity I didn't give the

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

> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution > wrote: > > Hello, > >> It's just that a common data type wasting almost half the space seems >> inefficient. I guess this is also the reason why they didn't adopt optional >> integers widely in stdlib.

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

The "Symbol, Other" category contains "Sign of the Horns" 落 which was one of the problems with the identifier/operator that kicked off these discussions. http://www.fileformat.info/info/unicode/char/1f918/index.htm So it would break some existing cases, e.g.: 1> let \U+1F913 = "nerd face" 邏:

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

On Thu, Oct 20, 2016 at 8:18 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > I fully agree. It’s hella presumptuous to decide that I’m not allowed to > express whimsy, frustration, humor, or any other emotions in my code. Or to > tell an 8 year old using Playgrounds on

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

On Thu, Oct 20, 2016 at 8:08 AM, Erica Sadun wrote: > I really liked Jonathan's suggestion that removed the distinction between > operators and identifiers entirely. You could mark a one-argument function > as postfix or prefix, and a two-argument function as infix and use

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

I’m fairly confident the author of the collection has to make those checks for memory-safety, but in theory there’s wins in only doing the check once, and as early as possible. Smaller values to pass, and less checks. This is definitely micro-micro-optimization, though. Unlikely to matter for

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

> On Oct 20, 2016, at 12:37 AM, Russ Bishop via swift-evolution > wrote: > > >> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution >> > wrote: >> >> I was in the middle of writing about

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

Operators, Nouns, and Verbs There's an issue that I think it's worth bringing it out into the open for everyone to see so that we all know it is present. Solutions are possible, but they go beyond the scope of the identifier proposal. Here's the brief statement of the problem: 1. Operators

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

> On Oct 19, 2016, at 11:17 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 1:31 PM, David Waite via swift-evolution > > wrote: > The problem is that this set does not just

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

> 在 2016年10月20日，05:45，Jeremy Pereira 写道： > >> >> On 19 Oct 2016, at 16:13, Guoye Zhang wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via

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

> On Oct 20, 2016, at 9:29 AM, Jonathan S. Shapiro via swift-evolution > 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

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

Hello, It's just that a common data type wasting almost half the space seems inefficient. I guess this is also the reason why they didn't adopt optional integers widely in stdlib. When someone is really interested in fitting an optional integer into one machine word, then the best way would

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

On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris wrote: > Sent from my iPhone > > On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution < >

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

Sent from my iPhone > On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution > wrote: > >> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution >> wrote: >> >> Freeze the set of allowed emoji to whatever the

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

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

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

Said differently: A monkey with a tool is still a monkey. I.e. Swift cannot force somebody to become a good programmer no matter what rules it imposes. As far as limiting personal freedoms goes: everybody (kid’s included) should be able to use whatever pleases them - within the possibilities of

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

I'm sympathetic to the arguments you raise here. However, they were brought up during the SetAlgebra API discussion and rejected in favor of the current API. Now is not the time to re-litigate that thread. The point I'm making is that it's all right if Swift's operators happen to support the

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

> On 19 Oct 2016, at 19:00,Xiaodi Wu wrote: > > However, it's specifically the set algebra operators that I have the > greatest objection to cherrypicking: > > * Each of these operators has a specific meaning; it is an anti-goal to > support repurposing the union operator for any other purpose

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

Howdy, It seems the main question in discussing this proposal is “If $0, $1, $2, $3 are automatic closure parameters, then what is “$”?”. Another thing that has also recently come to my attention that Swift does not have a “result of previous expression” magic identifier as some

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

> On 19 Oct 2016, at 16:13, Guoye Zhang wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>> >>> Currently, Swift Int family and

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

> On 20 Oct 2016, at 08:34,Nevin Brackett-Rozinsky wrote: > > So I am strongly—adamantly—opposed to the operator-eviscerating portion of > this proposal. > > We should make Braille characters, Hangzhou numerals, the empty set and the > infinity sign into identifiers. All other operators should

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

Sent from my iPhone > On 20 Oct 2016, at 07:54, Russ Bishop via swift-evolution > wrote: > > >> On Oct 17, 2016, at 11:45 PM, Rien via swift-evolution >> wrote: >> >> “culturally offensive” is not a logical argument. >> A programming

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

Is there a compromise we can come up with, maybe? Allow emoji in identifiers, but freeze the set of allowed emoji to whatever the current version of the Unicode spec defines with the intention that 'automatic expansion' of the allowed character set to accommodate future emoji is a non-goal?

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

Point well taken, but FWIW, there is a large difference between *you* expressing whimsy and committing the language to an open-ended series of continuous revisions for the sole purpose of enabling one particular form of whimsy. It's rather an overstatement to say that we are proposing to "squash

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

> On Oct 17, 2016, at 11:45 PM, Rien via swift-evolution > wrote: > > “culturally offensive” is not a logical argument. > A programming language should be logically consistent no matter how many > cultures are offended by it. > If Swift is driven by SJW’s then very

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

> Le 20 oct. 2016 à 02:11, Xiaodi Wu via swift-evolution > a écrit : > > I actually take the opposite view of emoji, and I was convinced of this by > arguments from some of the other authors (though they may not come to the > same conclusions as I do): > > The

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

> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I was in the middle of writing about my opposition to the original proposal > when I went to bed last night, and was going to advocate something like this: > >> Given the current

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

Strong -1 from me as currently written. There is no reason to remove Emoji from identifiers, nor to restrict operators to ASCII only (especially since the corresponding UAX spec is still under construction). Emoji are just as much a part of modern communication as the Latin alphabet. Swift