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

The problem is that this set does not just contain mathematical operators, but includes among other examples \u2205 (Empty Set) and \u221E (infinity). -DW > On Oct 19, 2016, at 1:49 PM, Paul Cantrell via swift-evolution > wrote: > At the very least, Swift ought to

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

> On Oct 19, 2016, at 12:21 PM, Rob Mayoff via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution > > wrote: > In any case, I’d specifically hate to lose these: > > -

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

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 state of the discussion over in Unicode land, I think it > would probably be safe from a compatibility standpoint to

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

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,

Re: [swift-evolution] private & fileprivate

On Fri, Oct 14, 2016, at 02:54 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan wrote: >> >> >> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky >> wrote: >>> Daniel, I would be

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

> On Oct 19, 2016, at 12:29 PM, Jonathan S. Shapiro via swift-evolution > wrote: > > On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution > > wrote: > IMO, the best argument against using

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

> On Oct 18, 2016, at 11:34 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > However, Swift's current identifier and operator character sets do not > conform to any Unicode standards, nor have they been rationalized in the > language or compiler

Re: [swift-evolution] Some clarity lost from the great renaming

I wrote a script to find “needless words” in our function names and made a similar discovery. If “doXWithY(_ y: Y)” gets renamed to “doX(with y: Y)” and Y happened to be a enum or have static members, at use site it become a little awkward. Following Brandon’s first example: 1. “normal” is an

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

> > > IMO, the best argument against using unicode symbols for operators defined by > mathematics is that they are currently difficult to type. > > And there is no realistic hope of that changing. This issue is so compelling > that C and C++ introduced standardized text-ascii alternatives for

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

On Mon, Oct 17, 2016, at 11:25 PM, Jean-Denis Muys via swift-evolution wrote: > Now for the elephant in the room: '$' is a currency symbol. As such it > should be handled like any other currency symbol. Thinking otherwise > would be very culturally offensive. > > So can I use € as an variable name

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

Dear Swift-Evolution community, A few of us have been preparing a proposal to refine the definitions of identifiers & operators. This includes some changes to the permitted Unicode characters. The latest (perhaps final?) draft is available here:

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

Before and above anything else, if I read the proposal correctly, we will not be able any more to use math operator signs as operators, beyond the paltry half dozen or so in the ASCII character set??? I strongly oppose such a restriction. Maths symbols (including ∪) are widely recognised in

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

Hi, while I don’t really have an opinion on the proposal overall, the following > As an exception, in homage to Swift's origins, we permit  and  in > identifiers. seems pointless and complicates things for no apparent gain (other than satisfying Chris’ requirement… ;)), so I’d remove those

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

The restriction to ASCII operators need not be permanent. However, we were unable to converge on a subset of mathematical symbols that we could definitively consider to be operators in contradistinction to those not included in that subset. Future Unicode recommendations on operators are pending,

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

Howdy, Some good points about standardizing identifiers. Some extremely short-sighted points about deleting my formal operators that are widely recognized as operators, and that I’ve spent months adding into my code. Frankly, I just couldn’t upgrade until you put them back in. > Operators > >

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

I support this in principle, having suggested similar things in the past. I would suggest, however, that to simplify the discussion and the proposal itself, that 'reserving operators at this time' and 'appease specific example that Chris Lattner proposed just so that it isn't outright denied'

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

> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution > wrote: > > Currently, Swift Int family and UInt family have compact representations that > utilize all available values, which is inherited from C. However, it is > horribly inefficient to implement

Re: [swift-evolution] Constant initialization and unreachable code.

Hi David, I find these warning useful at times, annoying at others - like in your case. I've personally come to a solution where I've declared a struct that contains these values: struct Debug { static let useFoo = true } if Debug.useFoo { print("yes") } else { print("no") } I've

[swift-evolution] Constant initialization and unreachable code.

Hey all, I don’t know if this is really an ‘evolution’ topic per se, and I’m not on Swift Dev, but thought someone here could shed some light on this. Often when developing code, if I need create mode switches (constant Bools) so that I can move back and forth between different

Re: [swift-evolution] [pitch] make @nonobjc the default

Ok, good to know that's just a bug. But I still think that implicit @objc should be removed. For bridged classes with obj-c-specific interfaces (for example a method that takes a selector), it would be better if the Swift-side interface was forced to make a Swifty interface that hides it. This

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

> On 18 Oct 2016, at 20:46, Guoye Zhang via swift-evolution > wrote: > >> >> 在 2016年10月18日，15:30，David Waite > > 写道： >> >> >>> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution >>>

Re: [swift-evolution] [Pitch] deprecating ManagedBufferPointer

> On Oct 19, 2016, at 3:28 PM, Alexis wrote: > > A bit late to this game, because I didn’t fully understand the “point” of > ManagedBuffer(Pointer). After a good week of messing around with these in > Dictionary/Array/String, I now have Opinions. > > I agree

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

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 real and very weighty reason Swift should support Unicode identifiers is that naming things is hard, and it is

Re: [swift-evolution] [Pitch] deprecating ManagedBufferPointer

A bit late to this game, because I didn’t fully understand the “point” of ManagedBuffer(Pointer). After a good week of messing around with these in Dictionary/Array/String, I now have Opinions. I agree ManagedBufferPointer is largely unnecessary. However it’s seeming a lot like ManagedBuffer

Re: [swift-evolution] Constant initialization and unreachable code.

William and Alex, thanks for the reply. I’m aware of the compile-time option. My post was originally to ask if the difference between constant and closure initialization for constants was intentional (and likely to remain) or just a temporary idiosyncrasy. I find #ifdef to be ugly and like

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

An EXTREME -1 from me as well. The restrictions on operators is FAR too severe. At the very least, I need the upside-down question mark and exclamation points ¿ ¡, as well as the ≤,≥,≠ operators. I mean, you are getting rid of the division sign ÷. How could that ever be controversial as an

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

I strongly oppose the proposed mass-removal of operator characters. It would be a major loss to the Swift language if that were to occur even temporarily. The long-term goal is for Swift to adopt the official Unicode guidance for operator characters, which is still under development. Therefore I

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

Thinking about it further, I am not convinced we need to make *any* change to the set of operator characters at this time. It’s not like people are clamoring to have Braille variable names after all. And as much as I’d like to see the upside-down ampersand (⅋) as an operator, that too can wait. I

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

If someone wants to write their variable names in Spanish or Japanese, they should be able to. That is one of the main reasons for including unicode. (Note it might make it more difficult for me to read, but it makes it easier for them and their team). If a group of mathematicians find it

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

On Wed, Oct 19, 2016 at 10:26 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > Thinking about it further, I am not convinced we need to make *any* change > to the set of operator characters at this time. It’s not like people are > clamoring to have Braille

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

I very much support the proposal to rationalize our handling of identifier characters. I also support doing something similar for operator symbols. However, I agree feedback from others that this proposal goes way to far in removing our ability to use mathematical operators. If I’m

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

Well, this is a very valuable contribution to the discussion. What non-ASCII operators are you currently using in Swift code? How did you decide on those operators instead of ASCII ones? Obviously, we would want to enable as many operators as possible to continue functioning. There is, however, a

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

http://reference.wolfram.com/language/tutorial/Operators.html They’ve been selling products to mathematicians and scientists for decades. Some of those symbols are their own, i.e. not included in unicode. > On Oct 19, 2016, at 8:54 AM, Xiaodi Wu wrote: > > Sorry, I've

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

> On Oct 14, 2016, at 12:59 PM, Chris Lattner wrote: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md > * What is your evaluation of the proposal? I know this is cutting against the grain,

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

+ on the emoji-related parts, +1 in general spirit, +1 for the identifier cleanup, -103 for being needlessly overly-restrictive for operators; net -1 overall. Operator abuse is a social problem, and even if a technical fix is possible this isn’t that…and despite the messiness of the relevant

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

> 在 2016年10月19日，11:43，Kevin Nattinger 写道： > >> >> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >> wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> >>> On 18 Oct 2016, at

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

I think this is a promising direction. Getting us in line with Unicode recommendations is an important first step, and being conservative about the treatment of operator characters and emoji is a good engineering approach, though certainly unfortunate in the short term for users who've adopted

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

> On Oct 19, 2016, at 9:16 AM, Guoye Zhang via swift-evolution > wrote: > >> >> 在 2016年10月19日，11:43，Kevin Nattinger 写道： >> >>> >>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] Some clarity lost from the great renaming

Sorry! I was unsure if this would be a breaking change so thought I would seek feedback. It sounds like I'm not the only one bothered by this so I will file a radar Brandon Sent from my iPad > On Oct 18, 2016, at 9:43 PM, Dave Abrahams via swift-evolution >

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

> 在 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 UInt family have compact representations >> that utilize all available

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

> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution > wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>>

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

> On Oct 19, 2016, at 7:41 AM, Matthew Johnson via swift-evolution > wrote: > > I very much support the proposal to rationalize our handling of identifier > characters. > > I also support doing something similar for operator symbols. However, I > agree feedback

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

On Wed, Oct 19, 2016 at 6:41 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > If I’m reading the proposal and discussion properly, the group has not > able to reach consensus on the right criteria for operator symbols, but is > hopeful that will be possible after the

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Oct 19, 2016, at 4:53 AM, Jay Abbott > > wrote: >> >> Ok, good to know that's just a bug. But I still think that implicit @objc >>

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

> On Oct 19, 2016, at 7:18 AM, Xiaodi Wu wrote: > How did you decide on those operators instead of ASCII ones? They are the “correct” mathematical symbols. On my machine, there is a block of characters explicitly marked as “Math Symbols". It’s a pretty good start (until

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

On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > In any case, I’d specifically hate to lose these: > > - approximate equality: ≈ > - set operations: ∩, ∪ > - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋ > - set membership: ∌, ∋, ∈, ∉ > - logical

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

> 在 2016年10月19日，12:21，Joe Groff 写道： > >> >> On Oct 19, 2016, at 9:16 AM, Guoye Zhang via swift-evolution >> wrote: >> >>> >>> 在 2016年10月19日，11:43，Kevin Nattinger 写道： >>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang

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

On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini via swift-evolution < swift-evolution@swift.org> wrote: > > > > > I think there's a mismatch between the English and

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

On Wed, Oct 19, 2016 at 10:21 AM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution < > swift-evolution@swift.org> wrote: > >> In any case, I’d specifically hate to lose these: >> >> - approximate equality: ≈ >> - set

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 4:53 AM, Jay Abbott wrote: > > Ok, good to know that's just a bug. But I still think that implicit @objc > should be removed. Oh, I agree that implicit @objc should be removed. I suspect it’s responsible for a nontrivial amount of code bloat and

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

Personally, a *very* limited cherrypicking might be OK, on the understanding that it must be done with very stringent inclusion criteria. 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

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

On Wed, Oct 19, 2016 at 4:09 AM, Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Some extremely short-sighted points about deleting my formal operators > that are widely recognized as operators, and that I’ve spent months adding > into my code. Frankly, I just

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

on Wed Oct 19 2016, Kevin Nattinger wrote: >> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >> wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> > >>> On 18 Oct 2016, at

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

> Dots in operators > > The current requirements for dots in operator names are: > > If an operator doesn’t begin with a dot, it can’t contain a dot elsewhere. > This proposal changes the rule to: > > Dots may only appear in operators in runs of two or more. > Under the revised rule, ..< and

Re: [swift-evolution] Constant initialization and unreachable code.

> On Oct 19, 2016, at 4:50 AM, David Goodine via swift-evolution > wrote: > > Hey all, > > I don’t know if this is really an ‘evolution’ topic per se, and I’m not on > Swift Dev, but thought someone here could shed some light on this. > > Often when developing

Re: [swift-evolution] Constant initialization and unreachable code.

> On Oct 19, 2016, at 9:37 AM, Alex Martini via swift-evolution > wrote: > >> >> On Oct 19, 2016, at 4:50 AM, David Goodine via swift-evolution >> > wrote: >> >> Hey all, >> >> I don’t know if this is

Re: [swift-evolution] Some clarity lost from the great renaming

on Tue Oct 18 2016, Hooman Mehr wrote: > Is changing the mapping of Cocoa API considered a source breaking > change or can we report such incidents as bugs if we think they don’t > match API guidelines? You can report them as bugs even if it would be source breaking. > > >> On Oct 18, 2016,

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

on Wed Oct 19 2016, 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 Oct 19, 2016, at 12:27 PM, Erica Sadun wrote: > > >> On Oct 19, 2016, at 7:41 AM, Matthew Johnson via swift-evolution >> wrote: >> >> I very much support the proposal to rationalize our handling of identifier >> characters. >> >> I

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 10:53 AM, Douglas Gregor wrote: > >> >> On Oct 19, 2016, at 10:37 AM, Joe Groff > > wrote: >> >>> >>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution > wrote: > > >> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Oct 19, 2016, at 4:53 AM, Jay

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 11:24 AM, Matthew Johnson wrote: > >> >> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution >> > wrote: >> >> >>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 1:26 PM, Joe Groff via swift-evolution > wrote: > > If we move to this on-demand model for @objc-ness, then it seems to me we can > potentially get away from @objc having to be a thing. The constraints on > being representable in ObjC can still

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

Sorry, I've not been very clear on my question. What non-ASCII operators are in use in your production code? What ASCII equivalents did you consider and discard for those particular operators? It's important to remember that math *symbols* are not all operators. We cannot merely transpose Unicode

Re: [swift-evolution] Constant initialization and unreachable code.

> On Oct 19, 2016, at 5:50 AM, David Goodine via swift-evolution > wrote: > > Hey all, > > I don’t know if this is really an ‘evolution’ topic per se, and I’m not on > Swift Dev, but thought someone here could shed some light on this. > > Often when developing