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

[Jonathan Hull via swift-evolution]

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 useful to write code that looks like the 
language they use in their everyday life, why do we need to stop them?  It 
doesn’t have to be useful to everyone to be incredibly useful (and 
communicative) for them.

And it’s not just math. I was able to use custom operators in Swift to mimic 
the standard PEG grammar (with only a few small differences), and it is 
incredibly useful.  The ability to transcribe a grammar directly from a 
research paper without having to translate to another (much less clear) 
language is enormously beneficial to me.  I am able to see the structure 
directly instead of having to “read” it from code (and translate back to my 
working language) the way you have to in most languages. That results in being 
able to put together much more complicated and full featured systems and still 
be able to understand them better at a glance.  That is actually one of the 
main reasons I have been using Swift over Objective C.


> It's more practical to make breaking changes now and introduce the "right 
> set" (that is, a standards-based set of mathematical operators) at a future 
> date, than to justify keeping things as is and removing operators at a future 
> date.
Define practical. How is breaking shipping code to solve a theoretical problem 
practical?  I have yet to see any evidence that the current system is actually 
causing ANY real world problems.

You can break EVERYTHING now, or break only a small subset of that (which is 
the part which most people probably aren’t using anyway) when you know the 
standards for certain. I don’t understand the mindset that breaking more is 
better.  This is one of those cases, where if the eventual standard breaks too 
many things, then you have chosen your standard incorrectly, because it doesn’t 
reflect reality.  The market will speak about what is useful.

Why not say: “These are definitely going to be identifiers. These are 
definitely going to be operators.  Everything else is currently undefined and 
will stay where it is, but may change in the future to match X spec”.  I don’t 
see how that is any more harmful to the growth of Swift, and it is certainly 
less harmful to the rest of us while we wait.

> Beginning with Swift 4, there will be a major push to ensure that backwards
> compatibility with existing code is not broken. It will be possible to
> expand the operator character set, but very difficult to shrink it.
IMO that point has been crossed already. Swift 3 was for all the breaking 
changes, and now for Swift 4 there is a much higher barrier. We are past the 
point of breaking everything for the sake of breaking them because adding is 
easier.

Honestly, there are a lot of helpful improvements in Swift 3, but I would be 
hard pressed to find any of the panicked “we have to break it now or we won’t 
be able to later” changes that were made among them.  Those things are just 
broken, waiting for someone to fix them in an undefined future time.  Given 
that I am still waiting for Apple to fix bugs from Panther, I am not holding my 
breath.

> 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 is an anti-goal to
> support repurposing the union operator for any other purpose than forming a
> union of two sets, for instance.
There are many different branches of math which use symbols in different ways.  
Higher order logic, for instance, uses the union symbol as an operation (which 
is not the union of two sets). I have an old book on computer chip design which 
uses the union symbol as a way to optimally place logic gates.   

I wrote a program (just for myself) that helped me solve a math problem in 
graph theory that I had been working on for 10 years.  10 years… and the 
program helped me solve it in a matter of days.  If I find that symbol useful 
for my computations, but it isn’t the union of two sets, why is that a problem?

There are also many other fields besides math which use symbols for short hand. 
 The ‘+’ symbol is used for addition, but it is also used for concatenation of 
Strings.

My point is that as much as you think you know my goals or context, you don’t.  
It is an anti-goal for us to be the language style police… restricting people’s 
expression because we don’t understand their context, and limiting them to 
problem spaces which we find interesting. In my experience, that sort of thing 
is the root of all evil (and the root of bad UI/UX).

I used to work on a language 

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

[Jonathan S. Shapiro via swift-evolution]

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 variable names after all. And as much as I’d like
> to see the upside-down ampersand (⅋) as an operator, that too can wait.
>

Unfortunately we *do* need to make changes. At the very least, the current
definition of operators includes completely undefined codepoints. That's
just not OK. There are also *many* elements that are unlikely to be
incorporated in UAX31, and we want to be careful about backwards
compatibility issues and also cross-language interop issues. Including too
much risks incompatibility with future evolutions of UAX31 that other
languages are likely to adopt as a gold standard of interop.

I am hopeful that this proposal will be revised to focus solely on adopting
> UAX-31.
>

That's definitely the goal, but we don't yet have a draft "operator
identifier" proposal in UAX31 to adopt. I think Xiaodi's goal here was to
arrive at a subset that would be future proof.

I've put in an email to the proposing group, and I expect there will be a
response, but I don't want to speak as if I'm representing the consensus
until I hear back from them. Can I ask everyone to engage patience on this
issue until some time tomorrow?

You are all very definitely being heard!


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]

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 am hopeful that this proposal will be revised to focus solely on adopting
UAX-31. I am not yet familiar with the specifics of that document, and I
expect I am not alone in that regard. Since the proposal indicates several
thousand characters will no longer be valid in identifiers, it seems quite
possible that some of them may be controversial.

I think it is far more productive to spend our collective efforts on making
sure we get identifiers right for Swift 4. We can deal with operators in a
similar manner once official Unicode guidelines are put forth, so we should
not spend time on them now.

Nevin



On Thu, Oct 20, 2016 at 12:44 AM, Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini  wrote:
>
>> Grammar changes
>>
>> operator → operator-head operator-characters[opt]
>>
>> operator-head → ! % & * + - / < = > ? ^ | ~
>> operator-head → operator-dot operator-dots
>> operator-character → operator-head
>> operator-characters → operator-character operator-character[opt]
>>
>> operator-dot → .
>> operator-dots → operator-dot operator-dots[opt]
>>
>>
>> 
>>
>>
>> I think there's a mismatch between the English and grammar.  For example,
>> is +..+ allowed or not?
>>
>> The English rule does allow +..+ because its dots appear in a run of two.
>>
>> The grammar allows a run of one or more dots as an operator head, but
>> never allows dots as characters appearing in the middle of an operator,
>> regardless of how many dots appear next to each other.  The grammar
>> wouldn't allow +..+ because the dots don't come at the beginning.
>>
>>
>>
>> Here's an alternate version of the grammar that matches the "two or more"
>> rule.  Because we no longer distinguish between which characters are
>> allowed as the first character of an operator vs a character inside,
>> there's no longer a need for a separate operator-head.
>>
>> operator --> operator-character operator-OPT
>>
>> operator-character --> ! % & * + - / < = > ? ^ | ~
>> operator-character --> operator-dots
>>
>> operator-dots --> .. operator-additional-dots-OPT
>> operator-additional-dots --> . operator-additional-dots-OPT
>>
>
> There is a typo in that operator-character[opt] should be
> operator-characters[opt]. Aside from that, though, I believe the grammar as
> written accepts +..+ already. Take a look at the following series of
> substitutions based on the grammar rules:
>
> operator
> operator-head operator-characters
> + operator-characters
> + operator-character operator-characters[opt]
> + operator-head operator-head
> + operator-dot operator-dots operator-head
> + . . +
>
>
> ___
> 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

[Jonathan Hull via swift-evolution]

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

This is the first proposal I have seen, where if it goes through, I will 
actually have to stop using Swift (or find a way not to upgrade)!

Seriously, this proposal would break the vast majority of my code.  One of the 
first things I wrote for Swift was a packrat parser which lets me define 
rulesets that look like standard PEG using swift operators.  I have now written 
several different projects on top of that.  I also have a private extension for 
≤,≥,≠ that I use in my projects.

What happened to needing extra justification for breaking changes? We can add 
them back later, you say. This seems to be breaking things just for the fun of 
it then…. If you are going to need to break things later to become compatible 
with something, then break them later.  Don’t break my production code now to 
avoid a 1% chance you might have to break my production code in the future.

> [begin quote]
> 
> • Operators suffer from low discoverability and difficult readability. They
> use symbols, not names. This places a cognitive cost on users with respect
> to both recall ("What is the operator that applies the behavior I need?")
> and recognition ("What does the operator in this code do?").
> • This cost is obviously highest when symbols are not tied to conventional
> standards like `∪` for union and `⊇` for superset. `∪` is a standard,
> mathematical representation. It’s widely accepted and widely used. Even so,
>  recognizing `formUnion(with:)` may work better for many coders than
> recalling what the `∪` (or, worse, `⊇`) operator does, even when you end up
> having to create suites of specialized selectors. As operators become more
> self-defined or esoteric, costs rise.
> 
> [end quote]
With all due respect, my day job is in the cognitive sciences (I have a 
master’s degree in Cognitive Psychology) and this is pure bullshit.  The entire 
reason we use symbols is that the opposite is true.  Yes, there is temporarily 
a greater burden on people who are new to a symbol, but once they learn it, it 
has much faster recall and recognition. That is why we use icons all over the 
place. It is why mathematicians use symbols.  It is why you see all those 
symbols on signs at the airport.

There are a bunch of symbols in unicode which are hard to tell apart, and those 
are bad for recognition, and we should deal with that, but this proposal is 
throwing the baby out with the bathwater, then lighting the baby on fire.  
Honestly, I would propose we find a way to have Swift see certain classes of 
characters as identical.  Can’t decide which of the thousand + symbols should 
be the one true + symbol?  Have them all map to one of them.  That emoji X 
symbol looks like X, so map it to X.

This proposal is lazy and unreasonable.  I think we can all agree that there 
needs to be thought around confusable symbols… but most of us just aren’t using 
the confusable symbols.  The argument seems to be “Let’s break EVERYTHING now 
so we don’t have to break it later”, which is pure ridiculousness.  Don’t break 
anything now… and then when you are ready to deal with confusables (which, 
again, most people aren’t actually using) do it surgically then.  You will be 
breaking a strictly smaller amount of code…




___
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 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 believe
we should make only minor and obvious changes right now, because there is
no sense in “jumping the gun” and causing unnecessary source-breaking
changes.

In particular, we should make it clear that Swift will most likely adopt
the Unicode operator conventions when they become available, so people are
aware and prepared.

When the time comes, we should deprecate any operator characters that
Unicode recommends against (unless we have a good reason not to), before
removing them in the next major release. The deprecation period ensures
that source-breaking changes result in a warning at first, so developers
have time to adapt.

I just went through all the valid operator characters in Swift, and the
only ones I would recommend to eliminate at this time are:
U+2800 – U+28FF (Braille patterns)
U+3021 – U+3029 (Hangzhou numerals)
U+2205 and U+221E (Empty set and Infinity)

Additionally, I propose to *add* one operator that is missing:
U+214B (Turned ampersand)

• • •

As for the rest of the proposal, I suppose normalizing identifiers and
dealing with confusable characters in a sensible way.

Regarding emoji, I look at them rather like the “I’m feeling lucky” button
on Google—essentially nobody uses it, but when they tried getting rid of it
people didn’t like the result. So I agree with Brent about that we should
keep them for cultural, not technical, reasons.

• • •

Returning to the discussion of operators, I am reminded of what happened
when we eliminated argument labels from functions passed as parameters. The
intent was and still is to reinstate them in a more robust manner.

However, during the interim the result has been a regression that goes
against the core tenets and philosophy of Swift. I would not want to repeat
that while waiting for official Unicode operator guidelines.

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 remain as they
are until official Unicode recommendations exist, at which point we should
deprecate as necessary.

Nevin



On Wed, Oct 19, 2016 at 5:53 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> 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 the punctuation operators to relieve stress on non-english keyboard
> users.
>
>
> I don’t agree that there is no realistic hope of that changing.  It
> appears to be pretty reasonable to anticipate that we’ll all be using
> software-driven keyboards that can display software-defined symbols on the
> keys in the relatively near future (probably 5 years, certainly 10).  All
> kinds of interesting things become possible when that happens, including
> the ability to make unicode operators much easier to discover and type in a
> programmer’s editor.
>
>
> ___
> 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

[Xiaodi Wu via swift-evolution]

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 serious, and we should be adamant
about this one thing:

Even if your primary language is not English, and even if your use of Swift
takes you beyond emulating the narrow set of standard library and
Foundation API names, you can still take all the care and attention in
naming things that we would want to promote in Swift by using your own
primary language. We want this to be the case wherever you were born,
whatever language your mother taught you, and we want to support this on
principle, whether or not we can find empiric evidence of open-source
projects on GitHub that make use of any particular language which we know
to be used in the world.

Previously, as we tackled this Unicode problem, a not-illegitimate critique
was that Swift's support of Unicode identifiers appeared to be frivolous,
because the only examples given in documentation are of emoji, and as you
say, it is there to be cute or whimsical. This appearance undermines that
very serious idea described above.

UAX#31 makes room for the removal of obsolete scripts such as Egyptian
hieroglyphics from the range of valid identifier characters on the basis
(at least in my reading of the document) that it adds to the burden of a
programming language without serving the weighty purpose of expressing
themselves in their primary language. By analogy, emoji similarly do not
serve that purpose, and since their parsing changes with every Unicode
update, we would be making changes to Swift every minor release for the
purpose of chasing a modish whimsy.


On Thu, Oct 20, 2016 at 04:46 Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> 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 state of the discussion over in Unicode land, I think
it would probably be safe from a compatibility standpoint to admit code
points that fall into the following (Unicode-style) code point set:
>
> [:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] -
pictographics - emoji

I suspect we can probably also do something about emoji, since I doubt UAX
#31 is going to. Given that they are all static pictures of people or
things, I think we can decide they are all nouns and thus all identifier
characters. If we think there are some which might be declared operators
later, we can exclude them for now, but I'd like to at least see the bulk
of them brought in.

I think addressing emoji is important not for any technical reason, but for
nontechnical ones. Emoji are a statement about Swift's modern approach;
modernity is important. They are fun and whimsical; whimsy is important.

And most importantly, emoji identifiers are part of Swift's culture. It's
widely understood that you don't use them in real code, but they are very
common in examples. Just as we worry about source compatibility and binary
compatibility, so we should worry about culture compatibility. Removing
emoji would cause a gratuitous cultural regression.

--
Brent Royal-Gordon
Architechies

___
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] deprecating ManagedBufferPointer

[Erik Eckstein via swift-evolution]

> 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 ManagedBufferPointer is largely unnecessary. However it’s seeming a 
> lot like ManagedBuffer (and its equivalents) are suboptimal for the standard 
> library’s purposes too!
> 
> In particular, pretty much every one of these buffers that I see wants to be 
> a subclass of some NS* collection so that it can be toll-free bridged into 
> objective C. This means that all those types are forced to directly drop down 
> to allocWithTailElems, rather than using a nice abstraction that does it for 
> them. Array does this right now, and I’ve got a PR up for review that’s doing 
> the same thing to the HashedCollections. It’s an outstanding bug that String 
> isn’t doing this (forcing its buffer to be wrapped in another class to be 
> bridged).
> 
> I don’t really feel any pain from directly using allocWithTailElems, it’s a 
> great API. It just leaves me at a loss for when I’d reach for ManagedBuffer 
> at all, as it’s very limited.

I think we can implement a replacement for ManagedBufferPointer. But it would 
have a different API. Something like that:

public struct ManagedBufferPointer2 {

  public init(minimumCapacity: Int,
  initWith factory: (StorageClass) throws -> ()
  ) rethrows {
buffer = Builtin.allocWithTailElems_1(
 StorageClass.self, minimumCapacity._builtinWordValue, Element.self)
try factory(buffer)
  }
  // ...
  let buffer: StorageClass
}


> 
> 
>> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution 
>> > wrote:
>> 
>> I created a proposal: https://github.com/apple/swift-evolution/pull/545 
>> 
>> 
>>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Tue Oct 11 2016, Károly Lőrentey >> > wrote:
>>> 
 +1
 
 ManagedBuffer has been really useful a couple of times, but I never
 found a use for ManagedBufferPointer. I can’t even say I’m entirely
 sure what need it was originally designed to fulfill.
>>> 
>>> The real need is/was to be able to do the same kind of storage
>>> management in classes not derived from ManagedBuffer.  This can be
>>> important for bridging, where the buffers of various native swift
>>> containers need to be derived from, e.g., NSString or NSArray.  That is,
>>> however, an extremely stdlib-specifc need.
>>> 
>>> 
> On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
 > wrote:
> 
> The purpose of ManagedBufferPointer is to create a buffer with a custom 
> class-metadata to be able
 to implement a custom deinit (e.g. to destroy the tail allocated elements).
> It was used in Array (before I replaced it with the new 
> tail-allocated-array-built-ins). But now
 it’s not used anymore in the standard library.
> 
> As a replacement for ManagedBufferPointer one can just derive a class 
> from ManagedBuffer and implement the deinit in the derived class.
> 
> final class MyBuffer : ManagedBuffer {
>  deinit {
>// do whatever needs to be done
>  }
> }
> 
> // creating MyBuffer:
> let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in 
> return MyHeader(...) })
> 
> IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t 
> need this custom
 bufferClass to be passed to the constructor). Also ManagedBufferPointer 
 doesn’t use SIL
 tail-allocated arrays internally. Although this is not something visible 
 to the programmer, it makes
 life easier for the compiler.
> 
> So I suggest that we deprecate ManagedBufferPointer.
> 
> Erik
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 
>>> 
>>> -- 
>>> -Dave
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> 

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

[Brent Royal-Gordon via swift-evolution]

> 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, but I'm in favor.

I don't think the Dollar library is a good design, but I think there *are* good 
designs which could use an extremely short, distinctive identifier like `$`. 
These would be cases where there is a single, specific object, operation, or 
type which is absolutely central to the problem domain. jQuery is a good 
example of this: it is used in browsers, where DOM manipulation is such a big 
part of what you're doing that an extremely shorthanded syntax is appropriate. 
Other examples might include parsing or generating strings. In general, 
anything where a Swift file is effectively "embedded" or acting as a "plugin" 
might benefit from `$`.

Certainly that is not most Swift code, but this is a harmless change when you 
don't need it, and a helpful change when you do. And certainly code using it 
may be a little sloppy unless there's preprocessing involved, but sometimes a 
sloppy solution is the most expressive one.

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

Maybe. It certainly is possible to design around it by switching to a single 
identifier character, but few of those stand out in the same way `$` does.

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

I think it does. Swift disfavors boilerplate, and the places I imagine `$` 
ought to be used are those where a longer name would introduce unacceptable 
amounts of boilerplate.

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

`$` is certainly a rather popular identifier in Javascript.

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

Not much more than a glance.

-- 
Brent Royal-Gordon
Architechies

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

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

[David Goodine via swift-evolution]

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 prefer to avoid it 
unless absolutely necessary.  Thanks for the 
head up on Active Compilation Conditions William, I wasn’t aware of it.  
Anything I can do to avoid the Build Settings tab is more than welcome.
-d


> On Oct 19, 2016, at 1:57 PM, William Sumner  wrote:
> 
> 
>> 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 code, if I need create mode switches (constant Bools) 
>> so that I can move back and forth between different features/implementations 
>> for testing, developing experimental features, migration, etc.  Currently if 
>> I write the following:
>> 
>> let useFoo = true
>> 
>> if useFoo {
>> // Foo code
>> } else {
>> // Non-Foo code
>> }
>> 
>> I will get compiler warnings either way that there’s unreachable code based 
>> on the value of useFoo.  That makes sense in most cases, but in some cases I 
>> need to leave the code as is for a while, and I hate leaving long-standing 
>> compiler warnings in production code.  (If it’s yellow, you need to pay 
>> attention to it.)  So I poked around and discovered that if I use the 
>> following declaration of useFoo, the warnings go away.
>> 
>> let useFoo = { return true }()
>> 
>> So, the question is, is this intentional? The compiler could certainly 
>> ascertain that useFoo will always be true and carry out the same dead code 
>> detection as for the first declaration.  If this isn’t intentional, and the 
>> compiler may at some point optimize away the closure and trigger dead code 
>> warnings, I might come up with a proposal that there is some idiom that 
>> allows one to do the above without the warnings.  I’m really not a fan of 
>> #define (because it’s just butt-ugly in such a beautiful language), but its 
>> existence is unavoidable for some cases.  
>> 
>> And, as I write this, I realized I haven’t tried declaring useFoo as var, 
>> but I expect that would trigger a warning that useFoo is not modified and 
>> should be defined by let.  I think this is a use case that, for practical 
>> purposes, should be covered to allow this type of evolution of code without 
>> generating warnings.  If the current behavior is intentional and going to 
>> stay, then that’s probably the best solution.
>> 
>> -d
> 
> You should use Active Compilation Conditions to create flags for conditional 
> compilation you can check with #if. If you’re not yet using Xcode 8, you can 
> manually define the flags under the Other Swift Flags build setting (e.g., 
> -DUSEFOO).
> 
> Preston

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

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

[Alexis via swift-evolution]

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 (and its equivalents) are suboptimal for the standard 
library’s purposes too!

In particular, pretty much every one of these buffers that I see wants to be a 
subclass of some NS* collection so that it can be toll-free bridged into 
objective C. This means that all those types are forced to directly drop down 
to allocWithTailElems, rather than using a nice abstraction that does it for 
them. Array does this right now, and I’ve got a PR up for review that’s doing 
the same thing to the HashedCollections. It’s an outstanding bug that String 
isn’t doing this (forcing its buffer to be wrapped in another class to be 
bridged).

I don’t really feel any pain from directly using allocWithTailElems, it’s a 
great API. It just leaves me at a loss for when I’d reach for ManagedBuffer at 
all, as it’s very limited.


> On Oct 13, 2016, at 3:11 PM, Erik Eckstein via swift-evolution 
>  wrote:
> 
> I created a proposal: https://github.com/apple/swift-evolution/pull/545 
> 
> 
>> On Oct 11, 2016, at 11:32 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Tue Oct 11 2016, Károly Lőrentey > > wrote:
>> 
>>> +1
>>> 
>>> ManagedBuffer has been really useful a couple of times, but I never
>>> found a use for ManagedBufferPointer. I can’t even say I’m entirely
>>> sure what need it was originally designed to fulfill.
>> 
>> The real need is/was to be able to do the same kind of storage
>> management in classes not derived from ManagedBuffer.  This can be
>> important for bridging, where the buffers of various native swift
>> containers need to be derived from, e.g., NSString or NSArray.  That is,
>> however, an extremely stdlib-specifc need.
>> 
>> 
 On 2016-10-11, at 00:12, Erik Eckstein via swift-evolution
>>> > wrote:
 
 The purpose of ManagedBufferPointer is to create a buffer with a custom 
 class-metadata to be able
>>> to implement a custom deinit (e.g. to destroy the tail allocated elements).
 It was used in Array (before I replaced it with the new 
 tail-allocated-array-built-ins). But now
>>> it’s not used anymore in the standard library.
 
 As a replacement for ManagedBufferPointer one can just derive a class from 
 ManagedBuffer and implement the deinit in the derived class.
 
 final class MyBuffer : ManagedBuffer {
  deinit {
// do whatever needs to be done
  }
 }
 
 // creating MyBuffer:
 let b = MyBuffer.create(minimumCapacity: 27, makingHeaderWith: { myb in 
 return MyHeader(...) })
 
 IMO ManagedBuffer is much cleaner than ManagedBufferPointer (it doesn’t 
 need this custom
>>> bufferClass to be passed to the constructor). Also ManagedBufferPointer 
>>> doesn’t use SIL
>>> tail-allocated arrays internally. Although this is not something visible to 
>>> the programmer, it makes
>>> life easier for the compiler.
 
 So I suggest that we deprecate ManagedBufferPointer.
 
 Erik
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> 
>> 
>> -- 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
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

[Matthew Johnson via swift-evolution]

> 
> 
> 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 the 
> punctuation operators to relieve stress on non-english keyboard users.

I don’t agree that there is no realistic hope of that changing.  It appears to 
be pretty reasonable to anticipate that we’ll all be using software-driven 
keyboards that can display software-defined symbols on the keys in the 
relatively near future (probably 5 years, certainly 10).  All kinds of 
interesting things become possible when that happens, including the ability to 
make unicode operators much easier to discover and type in a programmer’s 
editor.

___
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

[Brent Royal-Gordon via swift-evolution]

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 admit code points 
> that fall into the following (Unicode-style) code point set:
> 
> [:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] - 
> pictographics - emoji

I suspect we can probably also do something about emoji, since I doubt UAX #31 
is going to. Given that they are all static pictures of people or things, I 
think we can decide they are all nouns and thus all identifier characters. If 
we think there are some which might be declared operators later, we can exclude 
them for now, but I'd like to at least see the bulk of them brought in.

I think addressing emoji is important not for any technical reason, but for 
nontechnical ones. Emoji are a statement about Swift's modern approach; 
modernity is important. They are fun and whimsical; whimsy is important.

And most importantly, emoji identifiers are part of Swift's culture. It's 
widely understood that you don't use them in real code, but they are very 
common in examples. Just as we worry about source compatibility and binary 
compatibility, so we should worry about culture compatibility. Removing emoji 
would cause a gratuitous cultural regression.

-- 
Brent Royal-Gordon
Architechies

___
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

[David Sweeris via swift-evolution]

> 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 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 the 
> punctuation operators to relieve stress on non-english keyboard users.

Wait, what? They’re only hard to type because people don’t seem to realize they 
can make their own keyboard layouts to use while they’re waiting for the USB 
Consortium to notice that it’s not the '80s anymore and update the class driver 
spec to allow keyboards to directly type unicode characters.
For macOS, I use Ukelele 
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=ukelele). I don’t 
know what tools there are for Windows or Linux, but I’d be *shocked* if they 
didn’t exist.

- Dave Sweeris___
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

[Joe Groff via swift-evolution]

> 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 documentation.

This isn't entirely true. Swift's current identifier set derives from the C 
working group WG14's proposal N1518, "Recommendations for extended identifier 
characters for C and C++":

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3146.html 


which unfortunately isn't called out anywhere in the compiler docs except this 
old language reference:

https://github.com/apple/swift/blob/master/docs/archive/LangRefNew.rst#identifier-tokens
 


-Joe
___
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

[David Waite via swift-evolution]

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 support operators using symbols from the 
> Unicode blocks called “Mathematical Operators” and “Supplemental Mathematical 
> Operators.”
> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode 
> 
> 
> It’s right there in the name!™

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

Re: [swift-evolution] private & fileprivate

[Kevin Ballard via swift-evolution]

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 interested to hear what, exactly, are the
>>> benefits your project has realized from the new “private” compared
>>> to the old “private” (which is now called “fileprivate”).
>>
>> There's no amazing insight here. The benefit is more granular
>> control. The more people work on a project, the more useful this
>> becomes.
>>
>
> More granular control *within a single file*. That is where I have a
> hard time imagining the benefits, and thus am asking for details.
>
> If there are multiple types within a single file, it is usually
> because they need to share implementation details.

Just because they need to share some implementation details doesn't mean
they should share all of them. Or better yet, a private/fileprivate type
in a file doesn't have to share any implementation details, it can
define a proper API that it exposes to the rest of the file while
keeping its implementation details private, just as it would if it were
an internal or public type.

> The only things that I see which scope-based access (the new
> “private”) brings to the table are:
> • Scope-private members from other parts of the file are unavailable
> (and thus don’t show in autocomplete).
> • Different extensions of a type can have scope-private members with
> the same name as each other.
>
> The former seems negligible, because you are working *within the same
> file*. The API that a type vends within its own file is hardly worth
> optimizing for.
>
> And the latter I would say is an anti-feature. Using multiple
> different members with the same name in extensions just makes it
> harder to rearrange the implementation, because those scope-private
> members will collide if moved into the same extension.
>
> So I *really* don’t see the benefits. Yes, I understand that there is
> now more granular control over access within a single file. I am
> asking for examples of how that additional granularity provides
> *benefits*.

Just because you're within a single file doesn't mean you need to throw
away the principles of API design. Sure, it's not nearly as important as
something that's more widely-visible, but that's not the same thing as
saying it's not important at all. Careful control of implementation
details vs exposed API even within a single file is still useful, either
because it's much easier to make the type public if desired, or because
it makes any future refactoring much easier. And it also helps you to
reason about the code as you're looking at it, because when you're
looking at a private declaration, you only have to consider the
immediate enclosing scope, as opposed to a fileprivate declaration where
you have to consider the whole file.

-Kevin Ballard

>  On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>   wrote:
>>
>> You might as well ask "why not make everything public" if private and
>> fileprivate makes no difference to you.
>
> That is not a fair assertion at all. The API which a type vends to
> other files within its module, and to clients outside its module, are
> significant parts of a quality and maintainable design.
>
> I do not think the API which a type vends *within its own file*
> warrants such lofty prioritization.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>>  wrote:
>>>
>>>
>>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky
>>>  wrote:
>>>
>>> As I see it, two significant drawbacks of the new “private” are
>>> increased complexity in the access control model, and encumbrance of
>>> the old “private” with the unwieldy moniker “fileprivate”.
>>
>> The first drawback is a truism: every language addition of feature
>> makes it more complex.
>
> You can’t just write off the complexity cost like that. The new scope-
> based “private” access level brings *substantial* complexity, to both
> the implementation and the mental programming model. It creates
> *unutterable* access levels, where a scope can see a member of another
> scope, but cannot create its own member with the same access level.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>>  wrote:
>>
>>
>> So we need to measure the benefit with other costs, which brings us
>> to your second "drawback". I'm having a hard time understanding it.
>> Is it too hard to type? If so, as an Objective-C survivor I disagree.
>> The experience of reading code is harder and therefore more important
>> than that of authoring code. "fileprivate" was chosen over many other
>> alternatives because it's obvious to the reader. A shorter but
>> equally obvious name would have been nice. But "unwieldy" is not
>> enough reason to justify such source-breaking change at the moment.
>
> Right, 

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

[Kevin Ballard via swift-evolution]

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?

-Kevin Ballard

On Tue, Oct 18, 2016, at 09:39 AM, Nevin Brackett-Rozinsky via swift-evolution 
wrote:
> It seems natural to me that currency symbols should be operators. This
> would allow, for example, prefix and postfix operators that take a
> number and return a “Currency” instance:
>
> let inMyPocket = $20
> let lochNess = £3.50
> let twoBits = 25¢
>
> if (inMyPocket - lochNess) > twoBits { … }
>
> Of course, the unnamed closure parameter identifiers would conflict
> with that use of the dollar sign. However, I think Anton has the right
> idea. We already use the number sign for compiler magic, so it would
> make sense to call the closure parameters #0, #1, etc. In my view
> those even read better than what we have now.
>
> Nevin
>
>
> On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution
>  wrote:
>>
>> on Mon Oct 17 2016, Jean-Denis Muys > evolut...@swift.org> wrote:
>>
>>  > While I already tersely supported this proposal, following all the
>>  > negative reactions, I feel compelled to revisit my position. The
>>  > main reason is that it strikes me that most points of view so far,
>>  > including mine, were really culturally short sighted, and far too
>>  > much US-centric.
>>  >
>>  > I totally agree that '$' being use by one (or even several) piece
>>  > of code is not reason enough to change the language. But I also
>>  > think that it being used by only one piece of code is no reason to
>>  > reject the change.
>>  >
>>  > Most of us, including me, have been blinded by two things:
>>  >
>>  > 1- the use of the $ sign in other programming languages 2- the use
>>  > of the $ sign in Swift as a prefix for implicitly declared closure
>>  > parameters
>>  >
>>  > I think this second use is not Swifty at all. It clearly (to me)
>>  > would fail the litmus test "if it wasn't there, would you add it
>>  > to the language?". Of course, it has been blessed by time, and it
>>  > has *become* Swifty, by usage because it's a useful feature,
>>  > despite the choice of its syntax being so ugly (to my non-american
>>  > eyes).
>>
>> I don't think it's un-swifty by any measure.  It's not particularly
>>  beautiful, I agree, but what would make a better, extremely
>>  terse, way
>>  to refer to a posiitional parameter of a closure?  Unless we
>>  can think
>>  of something that's obviously better, then it is thoroughly
>>  swifty: a
>>  pragmatic solution for an important problem.  Unless we can think
>>  of something that's obviously better, then it certainly *is* what we
>>  would have added to the language.
>>
>>  > Similarly, I believe the use of the $ in other language should not
>>  > be a guide in the decision here, either positively, nor
>>  > negatively. We may pay some mild attention to the concern that we
>>  > should perhaps avoid some confusion. I haven't seen much of that.
>>  >
>>  > 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.
>>
>> 
>>
>>  >
>>  > In conclusion, I believe this proposal must be accepted, and
>>  > actually expanded to include ¥, ¢, £, and also to make it explicit
>>  > that currency symbols can be used in variable names as first and
>>  > only character, as first of many characters, and at any position.
>>  >
>>  > This would make $0, $1, $2… legal variable names. I believe this
>>  > is OK.
>>  >
>>  > What would happen to implicitly declared closure parameters then?
>>  > Nothing. They would continue to be implicitly declared in the
>>  > context of closures that do not declare their parameters
>>  > explicitly, similarly to `self` being implicitly declared in the
>>  > context of a class. A user willing to use $0 there would be facing
>>  > a name collision, which is OK.
>>  >
>>  > Note that such a change is purely additive: no legal source code
>>  > today would fail with this change.
>>
>> That is actually a relatively un-swifty answer in some ways.
>> It means
>>  there are magic identifiers that are usable in all contexts
>>  but given
>>  special meaning in some contexts.  I think making the lexical
>>  roles of
>>  various currency symbols more consistent is a worthy goal, but
>>  I'm not
>>  sure this is the way to do it.
>>
>>  > I hope that at the very least, I opened a new perspective on this
>>  > proposal, and I hope we can find a way to be less culturally
>>  > biased.
>>
>> If there's cultural bias here, it's a bias based on programming
>> language
>>  precedent. \$[0-9] has a long history of use as a positional
>>  

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

[Kevin Ballard via swift-evolution]

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 in Swift? According to Xcode
> 8.1B3, yes.
> Can I use any currency symbol as an variable name in Swift? According
> to Xcode 8.1B3, not quite, but almost all of them.
>
> [snip]
>
> Of course, this is just a data point, and Xcode8.1B3 should not be the
> arbiter here. But I believe whether Swift accepts currency symbols as
> variable names should be consistent. Either it accepts all of them, or
> it includes all of them.
>
> I see no reason to exclude them. On the contrary, it was a design
> feature of Swift to relieve use from the shackles of the ASCII
> character set.
>
> In conclusion, I believe this proposal must be accepted, and actually
> expanded to include ¥, ¢, £, and also to make it explicit that
> currency symbols can be used in variable names as first and only
> character, as first of many characters, and at any position.

Swift doesn't care about currency symbols. The Currency_Symbol general
category is not special to Swift. And the fact that $, ¥, ¢, and £ (and
don't forget about ¤, which you didn't list) aren't valid identifiers is
a consequence of how they're categorized by Unicode, not some
intentional decision by Swift. Specifically, all of the currency symbols
that are in the Basic Latin block (e.g. any currency symbol in the range
U+–U+00FF) have the Pattern_Syntax property. And the Pattern_Syntax
property is defined by Unicode (see UAX #31) as a stable set of
characters that are appropriate to use for syntax in
patterns/expressions (e.g. programming language syntax, regular
expressions, ICU number formats, etc). I don't have a good way to test
this (UnicodeChecker has no way to search for all characters with the
Pattern_Syntax property), but AFAIK all Pattern_Syntax characters are
not legal identifiers in Swift, with any character not already reserved
for use by the Swift grammar (e.g. $ being used for positional
parameters) being available for operators.

-Kevin Ballard
___
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

[Paul Cantrell via swift-evolution]

> 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:
> 
> - approximate equality: ≈
> - set operations: ∩, ∪ 
> - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
> - set membership: ∌, ∋, ∈, ∉
> - logical operators: ¬, ∧, ∨
> 
> I'd add ≤ ≥ ≠ to that set. 

I have production code that uses ± and ≈.

As with all operator overloads, there is room for abuse — but I’ve been using 
these operators to mean what it looks like they should mean, and am very 
pleased with the readability benefits.

At the very least, Swift ought to support operators using symbols from the 
Unicode blocks called “Mathematical Operators” and “Supplemental Mathematical 
Operators.”
https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode 


It’s right there in the name!™

Cheers, P



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

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

[Daniel Duan via swift-evolution]

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 adjective, and preposition followed by adjective (“for 
normal”, “to default”, “with misc”) is ungrammatical. It’s very common to have 
enum cases being an adjective.
2. if the argument is a literal value (as opposed to a variable), the type 
information is not immediately obvious at use site. The function reads better 
if the enum type prefix is preserved: `botton.setTitle(“Test”, for: 
UIControlState.normal)`.

In these cases, we chose to preserve the words after the preposition to make 
the call site clearer.

These aren’t problems from the API Design Guideline. They should be considered 
carefully case by case. And yeah, not really something we can fix on this list 
:)

> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Oct 18 2016, Brandon Knope  > wrote:
> 
>> I meant to bring this up a bit ago but just came across it again.
>> 
>> I find this to not read properly:
>> 
>> button.setTitle("Test", for: .normal) //for normal what?
>> 
>> The for argument is really only clear in meaning when you are typing
>> it out and see that it is a UIControlState type. While reading it
>> without this context is it as clear? .normal doesn't seem descriptive
>> enough on its own.
>> 
>> Contrast this with UISegmentedControl:
>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
>> .normal, barMetrics:
>> .default)
>> 
>> Here the parameter labels are needed because there needs to be a
>> distinction in the method between left and right. But here it is not
>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>> 
>> So my question is: why was this not setTitle(forControlState:) or 
>> forButtonState, etc...?
> 
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
> 
> -- 
> -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] make @nonobjc the default

[Joe Groff via swift-evolution]

> 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 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 
 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 unnecessary 
>>> Objective-C selector collisions.
>>> 
 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 way, the people 
 maintaining an interface have to either a) write a wrapper with a Swifty 
 interface; or b) explicitly cop out and use @objc and inform their users 
 that they may also have to do the same in some situations; or c) persuade 
 their employers to let them port the whole thing to pure Swift, which 
 sounds like a lot of fun and is probably what they really want to do :D.
>>> 
>>> I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit 
>>> the amount of glue code one needs to write.
>>> 
 I'm not really sure how this works though, at what level this is applied? 
 Maybe it's more to do with the default build settings in Xcode than Swift 
 itself? I just would rather see Swift stand alone by default.
>>> 
>>> I think it’s a Swift language change: we should only infer ‘@objc’ when the 
>>> API
>>> 
>>> * Overrides of an @objc API,
>>> * Satisfies a requirement of an @objc protocol, or
>>> * Uses a Swift feature that requires the Objective-C runtime (e.g., 
>>> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)
>> 
>> It might also be nice if referring to a method with #selector automatically 
>> tried to make it @objc.
> 
> How would this work?  In all other cases it is clear that a method will 
> become @objc at the declaration site.  In this case it would not be.

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 be enforced by the operation that demands an 
ObjC method, whether that be an attribute on the declaration itself or an 
operation that references the declaration.

-Joe

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

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

[Charles Srstka via swift-evolution]

> 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 be enforced by the operation that 
> demands an ObjC method, whether that be an attribute on the declaration 
> itself or an operation that references the declaration.

Unless you’re making a library or a plugin or something that can’t completely 
know whether it’s being accessed by Objective-C clients.

Charles

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

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

[Matthew Johnson via swift-evolution]

> 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 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 unnecessary 
>> Objective-C selector collisions.
>> 
>>> 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 way, the people 
>>> maintaining an interface have to either a) write a wrapper with a Swifty 
>>> interface; or b) explicitly cop out and use @objc and inform their users 
>>> that they may also have to do the same in some situations; or c) persuade 
>>> their employers to let them port the whole thing to pure Swift, which 
>>> sounds like a lot of fun and is probably what they really want to do :D.
>> 
>> I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit 
>> the amount of glue code one needs to write.
>> 
>>> I'm not really sure how this works though, at what level this is applied? 
>>> Maybe it's more to do with the default build settings in Xcode than Swift 
>>> itself? I just would rather see Swift stand alone by default.
>> 
>> I think it’s a Swift language change: we should only infer ‘@objc’ when the 
>> API
>> 
>>  * Overrides of an @objc API,
>>  * Satisfies a requirement of an @objc protocol, or
>>  * Uses a Swift feature that requires the Objective-C runtime (e.g., 
>> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)
> 
> It might also be nice if referring to a method with #selector automatically 
> tried to make it @objc.

How would this work?  In all other cases it is clear that a method will become 
@objc at the declaration site.  In this case it would not be.

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

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

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

[Joe Groff via swift-evolution]

> 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 
>>> > 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 
 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 unnecessary 
>>> Objective-C selector collisions.
>>> 
 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 way, the people 
 maintaining an interface have to either a) write a wrapper with a Swifty 
 interface; or b) explicitly cop out and use @objc and inform their users 
 that they may also have to do the same in some situations; or c) persuade 
 their employers to let them port the whole thing to pure Swift, which 
 sounds like a lot of fun and is probably what they really want to do :D.
>>> 
>>> I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit 
>>> the amount of glue code one needs to write.
>>> 
 I'm not really sure how this works though, at what level this is applied? 
 Maybe it's more to do with the default build settings in Xcode than Swift 
 itself? I just would rather see Swift stand alone by default.
>>> 
>>> I think it’s a Swift language change: we should only infer ‘@objc’ when the 
>>> API
>>> 
>>> * Overrides of an @objc API,
>>> * Satisfies a requirement of an @objc protocol, or
>>> * Uses a Swift feature that requires the Objective-C runtime (e.g., 
>>> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)
>> 
>> It might also be nice if referring to a method with #selector automatically 
>> tried to make it @objc.
> 
> It might, although I don’t love the impact on the implementation: we either 
> end up creating one-off categories associated with the references to 
> non-@objc methods or our type checker has to process function bodies to 
> answer the question “is this method exposed to Objective-C”?

I don't think Sema necessarily needs to be involved. We could collect the full 
set of ObjC methods we need to emit for a class in a module and defer building 
a single category or class method table to IRGen time.

-Joe

___
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

[Matthew Johnson via swift-evolution]

> 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 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 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 Unicode Consortium completes its 
>> work.  I think it would be far better to defer the changes to valid operator 
>> symbols until that time (removing only symbols which are currently treated 
>> as operators but for which the proposal suggests should be available for 
>> identifiers instead).
> 
> It's more practical to make breaking changes now and introduce the "right 
> set" (that is, a standards-based set of mathematical operators) at a future 
> date, than to justify keeping things as is and removing operators at a future 
> date.

I think that depends on who you ask.  I think I understand the argument for 
taking that approach.  I just don’t necessarily agree with it.  I haven’t seen 
a compelling enough argument that this is actually causing a problem *in 
practice* or in some way preventing the language from moving forward.  

If we can find a way to include a sizable subset of mathematical operators we 
believe will be included that goes beyond those suggested by plx I would 
support that.  I just think going all the way back to basic ascii operators is 
much to far and believe we should be able to find a better “temporary” solution 
while waiting on the Unicode Consortium.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[William Sumner via swift-evolution]

> 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 code, if I need create mode switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }
> 
> I will get compiler warnings either way that there’s unreachable code based 
> on the value of useFoo.  That makes sense in most cases, but in some cases I 
> need to leave the code as is for a while, and I hate leaving long-standing 
> compiler warnings in production code.  (If it’s yellow, you need to pay 
> attention to it.)  So I poked around and discovered that if I use the 
> following declaration of useFoo, the warnings go away.
> 
> let useFoo = { return true }()
> 
> So, the question is, is this intentional? The compiler could certainly 
> ascertain that useFoo will always be true and carry out the same dead code 
> detection as for the first declaration.  If this isn’t intentional, and the 
> compiler may at some point optimize away the closure and trigger dead code 
> warnings, I might come up with a proposal that there is some idiom that 
> allows one to do the above without the warnings.  I’m really not a fan of 
> #define (because it’s just butt-ugly in such a beautiful language), but its 
> existence is unavoidable for some cases.  
> 
> And, as I write this, I realized I haven’t tried declaring useFoo as var, but 
> I expect that would trigger a warning that useFoo is not modified and should 
> be defined by let.  I think this is a use case that, for practical purposes, 
> should be covered to allow this type of evolution of code without generating 
> warnings.  If the current behavior is intentional and going to stay, then 
> that’s probably the best solution.
> 
> -d

You should use Active Compilation Conditions to create flags for conditional 
compilation you can check with #if. If you’re not yet using Xcode 8, you can 
manually define the flags under the Other Swift Flags build setting (e.g., 
-DUSEFOO).

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

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

[Joe Groff via swift-evolution]

> 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 
>> 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 unnecessary Objective-C selector 
> collisions.
> 
>> 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 way, the people 
>> maintaining an interface have to either a) write a wrapper with a Swifty 
>> interface; or b) explicitly cop out and use @objc and inform their users 
>> that they may also have to do the same in some situations; or c) persuade 
>> their employers to let them port the whole thing to pure Swift, which sounds 
>> like a lot of fun and is probably what they really want to do :D.
> 
> I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit 
> the amount of glue code one needs to write.
> 
>> I'm not really sure how this works though, at what level this is applied? 
>> Maybe it's more to do with the default build settings in Xcode than Swift 
>> itself? I just would rather see Swift stand alone by default.
> 
> I think it’s a Swift language change: we should only infer ‘@objc’ when the 
> API
> 
>   * Overrides of an @objc API,
>   * Satisfies a requirement of an @objc protocol, or
>   * Uses a Swift feature that requires the Objective-C runtime (e.g., 
> @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)

It might also be nice if referring to a method with #selector automatically 
tried to make it @objc.

-Joe

___
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 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 Unicode Consortium completes its
> work.  I think it would be far better to defer the changes to valid
> operator symbols until that time (removing only symbols which are currently
> treated as operators but for which the proposal suggests should be
> available for identifiers instead).
>

Beginning with Swift 4, there will be a major push to ensure that backwards
compatibility with existing code is not broken. It will be possible to
expand the operator character set, but very difficult to shrink it.

Given the current state of the discussion over in Unicode land, I think it
would probably be safe from a compatibility standpoint to admit code points
that fall into the following (Unicode-style) code point set:

[:S:] - [:Sc:] - [:xidcontinue:] - [:nfcqc=n:] & [:scx=Common:] -
pictographics - emoji


into operator characters. In English, this would be:

All symbols excluding currency symbols, provided they are not already in
regular identifiers, requiring that they are legal under NFC normalization
and also that they live in the Common script.

Explicitly exclude pictographics and emojis, not as a value judgment of
UAX31, but because different languages seem to be choosing to go different
ways about whether these are part of normal identifiers or operator
identifiers.

Similar rationale for currency symbols, though I personally believe those
should be operators rather than regular identifiers.


It's possible that other things will go in to UAX31, but it's very hard to
imagine that anything in the set above will end up getting excluded. In
particular, there is some inclination to add some punctuation symbols in
UAX31, but that's going to take some work to ensure that we don't make a
mess inadvertently.

As a transitional matter, I think it would be conservatively safe to add
the code points identified above. Note that it's important to exclude ASCII
code points that are currently "punctuation reserved words". In Swift this
(at least) includes:

. (period, when it does not appear [at least] two times in sequence)
; (Semicolon)
: (Full colon)
$ (Dollar sign - used in special identifiers, which I consider a flaw)
any and all brackets (for now).


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 the punctuation operators to relieve stress on non-english keyboard
users.

This is an argument with a limited lifespan and should not carry more
> weight than it deserves in the design of a language positioned to be the
> language for the next 20 years.  I strongly believe that removing them,
> even temporarily, is a mistake.
>

I think it's good to be a little conservative given the fact that the issue
is more broadly "in flight". That said, I personally believe that the
current proposal has cut back too far.


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

[Erica Sadun via swift-evolution]

> 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 from others that this proposal goes way to far in removing our 
> ability to use mathematical operators.  
> 
> 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 Unicode Consortium completes its work.  I 
> think it would be far better to defer the changes to valid operator symbols 
> until that time (removing only symbols which are currently treated as 
> operators but for which the proposal suggests should be available for 
> identifiers instead).

It's more practical to make breaking changes now and introduce the "right set" 
(that is, a standards-based set of mathematical operators) at a future date, 
than to justify keeping things as is and removing operators at a future date.

-- E

___
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 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 operations: ∩, ∪
>> - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
>> - set membership: ∌, ∋, ∈, ∉
>> - logical operators: ¬, ∧, ∨
>>
>
> I'd add ≤ ≥ ≠ to that set.
>

All of these seem reasonable to me. Can we please confirm that all of these
lie within

[:S:] - [:Sc]


Thanks!

Rationale will become clear in just a moment.


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 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 grammar.  For example,
> is +..+ allowed or not?
>

The intent is that this is allowed. Your alternative grammar captures the
intent correctly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Guoye Zhang via swift-evolution]

> 在 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 via swift-evolution 
  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 UInt family have compact representations 
>> that utilize all available values, which is inherited from C. However, 
>> it is horribly inefficient to implement optional integers. It takes 
>> double the space to store [Int?] than to store [Int] because of 
>> alignment.
> 
> Is this a general problem with Swift? Are lots of people complaining that 
> they are running out of space for their Optional arrays?
> 
 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.
>>> 
>>> I’ve only needed an array of optionals once, maybe twice. I don’t think 
>>> arrays of optionals are widely used to begin with, and the reason there are 
>>> few optional integers in the stdlib is because the interface is from objc, 
>>> which doesn’t have optionals. I doubt any thought at all was given in 
>>> designing the standard library to the extra space for an optional.
>>> 
>> Swift stdlib is independent from objc. Currently, "Int?" storage has a 
>> tradeoff between less space (n + 1 bytes) and unaligned access, and more 
>> space (n * 2 bytes) and fast access. Neither of them is optimal.
> 
> Something worth considering at a higher level is whether Array ought to align 
> storage at all. Modern Intel and Apple CPUs pay much less of a penalty for 
> unaligned access than older microarchitectures, and the memory savings of 
> packing arrays of Int? and similar types would be significant. (There are C 
> compatibility issues here too, since C's semantic model requires pointers to 
> be well-aligned for their type, and we want Swift.Arrays of C types to be 
> cheaply interoperable with pointer-based C APIs. This could perhaps be dealt 
> with by guaranteeing that C basic types and structs always have sizeof(T) % 
> alignof(T) == 0, and well-aligning the beginning of arrays.)
> 
> -Joe
> 
That would be great, and certainly needs exploring before locking ABI.

- Guoye

>> 
> 
>> 
>> 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.
>>> 
>>> In my experience, ints are used orders of magnitude more often than 
>>> optional int?s. Why optimize for the rare case?
>>> 
>> If we were to have safe arithmetic that produces optionals, or lenient 
>> subscript, it is important to have efficient optional integers. I do agree 
>> that Int slowing down is unacceptable.
>> 
>> - Guoye
>> ___
>> 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

[Rob Mayoff via swift-evolution]

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 operators: ¬, ∧, ∨
>

I'd add ≤ ≥ ≠ to that set.
___
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

[Alex Martini via swift-evolution]

> 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 ... are allowed, but <.< is not. We also 
> reserve the .. operator, permitting the compiler to use .. for a "method 
> cascade" syntax in the future, as supported by Dart 
> .
> 
> Motivations for incorporating the two-dot rule are:
> 
> It helps avoid future lexical complications arising from lone .s.
> 
> It's a conservative approach, erring towards overly restrictive. Dropping the 
> rule in future (thereby allowing single dots) may be possible.
> 
> It doesn't require special cases for existing infix dot operators in the 
> standard library, ... (closed range) and ..< (half-open range). It also 
> leaves the door open for the standard library to add analogous half-open and 
> fully-open range operators <.. and <..<.
> 
> If we fail to adopt this rule now, then future backward-compatibility 
> requirements will preclude the introduction of some potentially useful 
> language enhancements.
> 
>  
> Grammar
>  changes
> 
> operator → operator-head operator-characters[opt]
> 
> operator-head → ! % & * + - / < = > ? ^ | ~
> operator-head → operator-dot operator-dots
> operator-character → operator-head
> operator-characters → operator-character operator-character[opt]
> 
> operator-dot → .
> operator-dots → operator-dot operator-dots[opt]
>  
> I
>  think there's a mismatch between the English and grammar.  For example, is 
> +..+ allowed or not?

The English rule does allow +..+ because its dots appear in a run of two.

The grammar allows a run of one or more dots as an operator head, but never 
allows dots as characters appearing in the middle of an operator, regardless of 
how many dots appear next to each other.  The grammar wouldn't allow +..+ 
because the dots don't come at the beginning.



Here's an alternate version of the grammar that matches the "two or more" rule. 
 Because we no longer distinguish between which characters are allowed as the 
first character of an operator vs a character inside, there's no longer a need 
for a separate operator-head.

operator --> operator-character operator-OPT

operator-character --> ! % & * + - / < = > ? ^ | ~
operator-character --> operator-dots

operator-dots --> .. operator-additional-dots-OPT
operator-additional-dots --> . operator-additional-dots-OPT___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 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
 optional integers. It takes double the space to store [Int?] than
 to store [Int] because of alignment.
>>> 
>>> Is this a general problem with Swift? Are lots of people complaining that 
>>> they are running out of
> space for their Optional arrays?
>>> 
>> 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.
>
> I’ve only needed an array of optionals once, maybe twice. I don’t
> think arrays of optionals are widely used to begin with, and the
> reason there are few optional integers in the stdlib is because the
> interface is from objc, 

For the record, the interface of the stdlib is not from objc.

> which doesn’t have optionals. I doubt any thought at all was given in
> designing the standard library to the extra space for an optional.

That's not true; we made several implementation changes based on that
extra space.  We never felt there was a good reason to consider it in
making API choices, though.

>>> 
 
 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.
>
> In my experience, ints are used orders of magnitude more often than
> optional int?s. Why optimize for the rare case?

Yes, that's the core of the issue.

>> 
 
 So what do you think? Can we break C compatibility a bit for better Swift 
 types?
>>> 
>>> 
>>> Well it’s not just C compatibility, it’s underlying processor
>>> compatibility. And actually, yes, I think C compatibility is vastly
>>> more important than being able to make your [Int?] arrays smaller
>>> considering that full 2’s complement numbers is what the OS calls
>>> and libc calls are expecting.
>>> 
>> Yes, that is also the result Joe said of their previous internal
>> discussion. Anyway, I know this is improbable, and I'm just glad
>> that this possibility is considered.
>> 
>> - Guoye
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

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

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

[Jonathan S. Shapiro via swift-evolution]

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 couldn’t upgrade until you put them back in.
>

Benjamin:

The situation "behind the scenes" is that I've been working with Mark Davis
to add Unicode standard properties for operator start and operator continue
character sets in Unicode UAX31. That's a process whose scope needs to be
broader than just Swift, and it's something that Swift will want to be
compatible with. I think the intention would be to adopt that new part of
UAX31 as soon as practical, and I am hopeful that specification will meet
your needs and objectives. If not, I'd very much like to pick up that
conversation with you offline to see how we can improve matters in UAX31.

The UAX31 discussion seems to be converging rapidly. The proposal here is
to *temporarily* limit operator identifiers to the ASCII operator
characters. This is mainly intended to provide a bridge solution until
UAX31 changes can be published in draft form. One reason to take a
temporary step back is to ensure that we do not unintentionally specify
something now that will become incompatible as soon as the UAX31 draft
emerges.

Changes to the operator identifier space are well-localized in the compiler
implementation, and don't have any large-scale impact on later passes. They
are one of the few kinds of compiler changes that can safely be made late
in a development cycle. If this part of UAX31 converges as quickly as I
expect, I think we can get that result reflected into Swift 4, and we can
get a draft version implemented sooner.


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

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

[Dave Abrahams via swift-evolution]

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 UInt family have compact
>>> representations that utilize all available values, which is
>>> inherited from C. However, it is horribly inefficient to implement
>>> optional integers. It takes double the space to store [Int?] than
>>> to store [Int] because of alignment.
>> 
>> Is this a general problem with Swift? Are lots of people complaining that 
>> they are running out of
> space for their Optional arrays?
>> 
> 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.

For the record, we made no explicit choice to avoid optional integers.
We'd use them wherever it was appropriate.

>>> 
>>> 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.
>
>>> 
>>> So what do you think? Can we break C compatibility a bit for better Swift 
>>> types?
>> 
>> 
>> Well it’s not just C compatibility, it’s underlying processor
>> compatibility. And actually, yes, I think C compatibility is vastly
>> more important than being able to make your [Int?] arrays smaller
>> considering that full 2’s complement numbers is what the OS calls
>> and libc calls are expecting.
>> 
> Yes, that is also the result Joe said of their previous internal
> discussion. Anyway, I know this is improbable, and I'm just glad that
> this possibility is considered.
>
> - Guoye
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

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

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

[Dave Abrahams via swift-evolution]

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, at 6:43 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Tue Oct 18 2016, Brandon Knope > >
> wrote:
>> 
>>> I meant to bring this up a bit ago but just came across it again.
>>> 
>>> I find this to not read properly:
>>> 
>>> button.setTitle("Test", for: .normal) //for normal what?
>>> 
>>> The for argument is really only clear in meaning when you are typing
>>> it out and see that it is a UIControlState type. While reading it
>>> without this context is it as clear? .normal doesn't seem descriptive
>>> enough on its own.
>>> 
>>> Contrast this with UISegmentedControl:
>>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
>>> .normal, barMetrics:
>>> .default)
>>> 
>>> Here the parameter labels are needed because there needs to be a
>>> distinction in the method between left and right. But here it is not
>>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>>> 
>>> So my question is: why was this not setTitle(forControlState:) or 
>>> forButtonState, etc...?
>> 
>> This is really not an evolution question at this point.  I suggest
>> filing radars against UIKit for things whose names could be improved.
>> 
>> -- 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

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

[Alex Martini via swift-evolution]

> 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 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 features/implementations 
>> for testing, developing experimental features, migration, etc.  Currently if 
>> I write the following:
>> 
>> let useFoo = true
>> 
>> if useFoo {
>> // Foo code
>> } else {
>> // Non-Foo code
>> }
> 
> In your debugging, do you actually need this condition to be evaluated at 
> runtime?  For example, in the debugger, are you changing the value of useFoo 
> at runtime to switch which branch is used?
> 
> If not, maybe #if would be better — it makes the decision at compile time.  I 
> don't get any warnings from the following code:
> 
> let useFoo = true
> 
> #if useFoo
> print("foo code")
> #else
> print("non-foo code")
> #endif

Sorry, I hit Send too soon.  That listing should read:

#if useFoo
print("foo code")
#else
print("non-foo code")
#endif

You switch useFoo on and off by passing "-D useFoo" to the compiler.  For 
example:

% swift test.swift
non-foo code

% swift -D useFoo test.swift
foo code

___
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]

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 is an anti-goal to
support repurposing the union operator for any other purpose than forming a
union of two sets, for instance.

* Thus, the only rationale for inclusion of these operators is to support
aliasing the set algebra protocol members.

* Now, if it is appropriate for these set algebra operations to be
accessible through these operators, then the standard library should be
providing them.

* However, exactly such an API has been trialled on a Swift branch, and the
set algebra renaming debate of 2015 (or was it early 2016?) on this very
list resulted in a renaming that *rejected* the use of these operators.

* Given that these operators have been deemed not appropriate for the only
methods that should use them, we should *not* specifically enable these
symbols as valid operator characters.

It is of course true that a user can essentially choose to alias any method
using any other identifier. However, this particular scenario is different
because you are advocating for Swift to make express allowance in the
grammar for solely that purpose. In other words, the language design would
be saying to the user, "We don't think this is a good idea at all;
otherwise, it'd be in the standard library. We literally tried that and
decided against it. However, we're specifically going to let you act on
this not-very-good idea by explicitly leaving room for it."

Now, if we had a complete set of operator characters, which would include
set algebra operators, then it wouldn't be problematic in the same way. In
that scenario, the language would be no more responsible for your renaming
formUnion() to the union symbol than to nonsenseAsdf(), since in neither
case would the underlying characters have been included among valid
operator or identifier characters, respectively, for the express purpose of
making possible that renaming.
On Wed, Oct 19, 2016 at 23:48 plx via swift-evolution <
swift-evolution@swift.org> wrote:

> + 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 unicode
> categories, this proposal goes far too far.
>
> For operators, the reasonable thing to do at this time would be to
> hand-select a small subset of the mathematical characters to allow as
> operators—the “greatest hits” so to speak—and move on. If any grave
> oversights are discovered those characters can be included in subsequent
> major revisions; if the consortium ever finishes its recommendation it can
> be adopted at that time.
>
> There’s no need to exhaustively re-do the consortium’s work and there’s no
> need to make a correct-for-all-time decision on each character at this
> time; pick the low-hanging fruit and leave the rest for later.
>
> That not everyone will be perfectly happy with any specific subset is
> predictable and not interesting; not everyone is going to be perfectly
> happy with this proposal’s proposed subset, either.
>
> In any case, I’d specifically hate to lose these:
>
> - approximate equality: ≈
> - set operations: ∩, ∪
> - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
> - set membership: ∌, ∋, ∈, ∉
> - logical operators: ¬, ∧, ∨
>
> …although there are many more that would be nice to keep available.
>
> On Oct 19, 2016, at 1:34 AM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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:
>
>
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>
> We'd welcome your initial thoughts, and will probably submit a PR soon to
> the swift-evolution repo for a formal review. Full text follows below.
>
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
>
>
> Refining Identifier and Operator Symbology
>
>- Proposal: SE-
>
> 
>- Authors: Jacob Bandes-Storch , Erica
>Sadun , Xiaodi Wu ,
>Jonathan Shapiro
>- Review Manager: TBD
>- Status: Awaiting review
>
>
> 

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

[Alex Martini via swift-evolution]

> 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 code, if I need create mode switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }

In your debugging, do you actually need this condition to be evaluated at 
runtime?  For example, in the debugger, are you changing the value of useFoo at 
runtime to switch which branch is used?

If not, maybe #if would be better — it makes the decision at compile time.  I 
don't get any warnings from the following code:

let useFoo = true

#if useFoo
print("foo code")
#else
print("non-foo code")
#endif

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

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

[Douglas Gregor via swift-evolution]

> 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 unnecessary Objective-C selector 
collisions.

> 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 way, the people maintaining an 
> interface have to either a) write a wrapper with a Swifty interface; or b) 
> explicitly cop out and use @objc and inform their users that they may also 
> have to do the same in some situations; or c) persuade their employers to let 
> them port the whole thing to pure Swift, which sounds like a lot of fun and 
> is probably what they really want to do :D.

I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit the 
amount of glue code one needs to write.

> I'm not really sure how this works though, at what level this is applied? 
> Maybe it's more to do with the default build settings in Xcode than Swift 
> itself? I just would rather see Swift stand alone by default.

I think it’s a Swift language change: we should only infer ‘@objc’ when the API

* Overrides of an @objc API,
* Satisfies a requirement of an @objc protocol, or
* Uses a Swift feature that requires the Objective-C runtime (e.g., 
@NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)

It’s hard to justify pushing for this in Swift 4 stage 1, because changing 
defaults doesn’t affect the ABI, but it’s something I’d love to see us do at 
some point in Swift 4.

- Doug

> 
> 
> 
> On Wed, 19 Oct 2016 at 03:51 Douglas Gregor  > wrote:
> 
> 
> Sent from my iPhone
> 
> > On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution 
> > > wrote:
> >
> > Currently, if you extend a class that comes from obj-c, Swift assumes you 
> > want to make those methods available to call from obj-c code. If you add 
> > operators, you must declare them as @nonobjc otherwise the bridging header 
> > which is generated declares obj-c methods with the operator character as 
> > the method name, which isn't valid in obj-c and causes compile errors.
> 
> The operators bit is an outright bug, which I believe has already been fixed 
> in master.
> 
> > I'm just wondering how others feel about this - my feeling is that a Swift 
> > developer should not have to know anything about obj-c when doing Swifty 
> > things to a bridged class from a framework (such as extending it). As far 
> > as they are concerned the framework class should compile the same as if it 
> > were fully implemented in Swift.
> 
> Modulo bugs like the above, I think we already have this property? Swift 
> declarations are exposed to Objective-C if they can be. One doesn't generally 
> have to think about it unless you're trying to use those declarations from 
> Objective-C.
> 
> > Thoughts?
> 
> I actually thought you were going further with this, eliminating the inferred 
> @objc except in cases where it's needed to work with an existing framework. 
> That's something I'd love to see someone working on.
> 
>   - Doug
> 

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

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

[Joe Groff via swift-evolution]

> 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:
>>> 
>>> 
 在 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 values, which is inherited from C. However, it 
> is horribly inefficient to implement optional integers. It takes double 
> the space to store [Int?] than to store [Int] because of alignment.
 
 Is this a general problem with Swift? Are lots of people complaining that 
 they are running out of space for their Optional arrays?
 
>>> 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.
>> 
>> I’ve only needed an array of optionals once, maybe twice. I don’t think 
>> arrays of optionals are widely used to begin with, and the reason there are 
>> few optional integers in the stdlib is because the interface is from objc, 
>> which doesn’t have optionals. I doubt any thought at all was given in 
>> designing the standard library to the extra space for an optional.
>> 
> Swift stdlib is independent from objc. Currently, "Int?" storage has a 
> tradeoff between less space (n + 1 bytes) and unaligned access, and more 
> space (n * 2 bytes) and fast access. Neither of them is optimal.

Something worth considering at a higher level is whether Array ought to align 
storage at all. Modern Intel and Apple CPUs pay much less of a penalty for 
unaligned access than older microarchitectures, and the memory savings of 
packing arrays of Int? and similar types would be significant. (There are C 
compatibility issues here too, since C's semantic model requires pointers to be 
well-aligned for their type, and we want Swift.Arrays of C types to be cheaply 
interoperable with pointer-based C APIs. This could perhaps be dealt with by 
guaranteeing that C basic types and structs always have sizeof(T) % alignof(T) 
== 0, and well-aligning the beginning of arrays.)

-Joe

> 
 
> 
> 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.
>> 
>> In my experience, ints are used orders of magnitude more often than optional 
>> int?s. Why optimize for the rare case?
>> 
> If we were to have safe arithmetic that produces optionals, or lenient 
> subscript, it is important to have efficient optional integers. I do agree 
> that Int slowing down is unacceptable.
> 
> - Guoye
> ___
> 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

[Joe Groff via swift-evolution]

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 custom 
operators or found interesting uses for emoji identifiers in Swift 3 and 
earlier.

In the discussion about operators, I wonder whether it makes sense to formally 
separate "identifier" and "operator" characters at all. My hunch is that there 
isn't going to be any perfect categorization; there are so many symbols and 
scripts out there that it's going to be difficult to definitively characterize 
many symbols as "obviously" an operator or identifier. Not every developer has 
the mathematical background to even recognize common math operators beyond the 
elementary arithmetic ones. Something to consider would be to change the way 
operators work in the language so that they can use *any* symbols (subject to 
canonicalization, visibility, and confusability constraints), but require their 
use to always be explicitly declared in a source file that uses an operator 
outside of the standard library. For example, you would have to say something 
like:

import Sets
import operator Sets.∪

to make the '∪' symbol available as an operator in the import declaration's 
scope. This would provide more obvious evidence in the source code of what 
tokens are being employed as operators, and lessen the need to have formally 
distinct identifier and operator character sets.

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

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

[Guoye Zhang via swift-evolution]

> 在 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 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 optional integers. It takes double 
 the space to store [Int?] than to store [Int] because of alignment.
>>> 
>>> Is this a general problem with Swift? Are lots of people complaining that 
>>> they are running out of space for their Optional arrays?
>>> 
>> 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.
> 
> I’ve only needed an array of optionals once, maybe twice. I don’t think 
> arrays of optionals are widely used to begin with, and the reason there are 
> few optional integers in the stdlib is because the interface is from objc, 
> which doesn’t have optionals. I doubt any thought at all was given in 
> designing the standard library to the extra space for an optional.
> 
Swift stdlib is independent from objc. Currently, "Int?" storage has a tradeoff 
between less space (n + 1 bytes) and unaligned access, and more space (n * 2 
bytes) and fast access. Neither of them is optimal.

>>> 
 
 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.
> 
> In my experience, ints are used orders of magnitude more often than optional 
> int?s. Why optimize for the rare case?
> 
If we were to have safe arithmetic that produces optionals, or lenient 
subscript, it is important to have efficient optional integers. I do agree that 
Int slowing down is unacceptable.

- Guoye
___
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

[plx via swift-evolution]

+ 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 unicode categories, 
this proposal goes far too far.

For operators, the reasonable thing to do at this time would be to hand-select 
a small subset of the mathematical characters to allow as operators—the 
“greatest hits” so to speak—and move on. If any grave oversights are discovered 
those characters can be included in subsequent major revisions; if the 
consortium ever finishes its recommendation it can be adopted at that time.

There’s no need to exhaustively re-do the consortium’s work and there’s no need 
to make a correct-for-all-time decision on each character at this time; pick 
the low-hanging fruit and leave the rest for later. 

That not everyone will be perfectly happy with any specific subset is 
predictable and not interesting; not everyone is going to be perfectly happy 
with this proposal’s proposed subset, either.

In any case, I’d specifically hate to lose these:

- approximate equality: ≈
- set operations: ∩, ∪ 
- set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
- set membership: ∌, ∋, ∈, ∉
- logical operators: ¬, ∧, ∨

…although there are many more that would be nice to keep available. 

> On Oct 19, 2016, at 1:34 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 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:
> 
> 
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
> We'd welcome your initial thoughts, and will probably submit a PR soon to the 
> swift-evolution repo for a formal review. Full text follows below.
> 
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
> 
> 
> Refining Identifier and Operator Symbology
> 
> Proposal: SE- 
> 
> Authors: Jacob Bandes-Storch , Erica Sadun 
> , Xiaodi Wu , Jonathan 
> Shapiro
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks to refine and rationalize Swift's identifier and operator 
> symbology. Specifically, this proposal:
> 
> adopts the Unicode recommendation for identifier characters, with some minor 
> exceptions;
> restricts the legal operator set to the current ASCII operator characters;
> changes where dots may appear in operators; and
> disallows Emoji from identifiers and operators.
>  
> Prior
>  discussion threads & proposals
> 
> Proposal: Normalize Unicode identifiers 
> 
> Unicode identifiers & operators 
> ,
>  with pre-proposal 
>  (a 
> precursor to this document)
> Lexical matters: identifiers and operators 
> 
> Proposal: Allow Single Dollar Sign as Valid Identifier 
> 
> Free the '$' Symbol! 
> 
> Request to add middle dot (U+00B7) as operator character? 
> 
>  
> Guiding
>  principles
> 
> Chris Lattner has written:
> 
> …our current operator space (particularly the unicode segments covered) is 
> not super well considered. It would be great for someone to take a more 
> systematic pass over them to rationalize things.
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> …any proposal that breaks:
> 
> let  = "moof"
> will not be tolerated. :-) :-)
>  
> 

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

[Kevin Nattinger via swift-evolution]

> 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:
>>> 
>>> 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 optional integers. It takes double the 
>>> space to store [Int?] than to store [Int] because of alignment.
>> 
>> Is this a general problem with Swift? Are lots of people complaining that 
>> they are running out of space for their Optional arrays?
>> 
> 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.

I’ve only needed an array of optionals once, maybe twice. I don’t think arrays 
of optionals are widely used to begin with, and the reason there are few 
optional integers in the stdlib is because the interface is from objc, which 
doesn’t have optionals. I doubt any thought at all was given in designing the 
standard library to the extra space for an optional.

>> 
>>> 
>>> 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.

In my experience, ints are used orders of magnitude more often than optional 
int?s. Why optimize for the rare case?

> 
>>> 
>>> So what do you think? Can we break C compatibility a bit for better Swift 
>>> types?
>> 
>> 
>> Well it’s not just C compatibility, it’s underlying processor compatibility. 
>> And actually, yes, I think C compatibility is vastly more important than 
>> being able to make your [Int?] arrays smaller considering that full 2’s 
>> complement numbers is what the OS calls and libc calls are expecting.
>> 
> Yes, that is also the result Joe said of their previous internal discussion. 
> Anyway, I know this is improbable, and I'm just glad that this possibility is 
> considered.
> 
> - Guoye
> ___
> 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] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

> 在 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 values, which is inherited from C. However, it is 
>> horribly inefficient to implement optional integers. It takes double the 
>> space to store [Int?] than to store [Int] because of alignment.
> 
> Is this a general problem with Swift? Are lots of people complaining that 
> they are running out of space for their Optional arrays?
> 
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.
> 
>> 
>> 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.

>> 
>> So what do you think? Can we break C compatibility a bit for better Swift 
>> types?
> 
> 
> Well it’s not just C compatibility, it’s underlying processor compatibility. 
> And actually, yes, I think C compatibility is vastly more important than 
> being able to make your [Int?] arrays smaller considering that full 2’s 
> complement numbers is what the OS calls and libc calls are expecting.
> 
Yes, that is also the result Joe said of their previous internal discussion. 
Anyway, I know this is improbable, and I'm just glad that this possibility is 
considered.

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

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

[Brandon Knope via swift-evolution]

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 
>  wrote:
> 
> 
>> on Tue Oct 18 2016, Brandon Knope  wrote:
>> 
>> I meant to bring this up a bit ago but just came across it again.
>> 
>> I find this to not read properly:
>> 
>> button.setTitle("Test", for: .normal) //for normal what?
>> 
>> The for argument is really only clear in meaning when you are typing
>> it out and see that it is a UIControlState type. While reading it
>> without this context is it as clear? .normal doesn't seem descriptive
>> enough on its own.
>> 
>> Contrast this with UISegmentedControl:
>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
>> .normal, barMetrics:
>> .default)
>> 
>> Here the parameter labels are needed because there needs to be a
>> distinction in the method between left and right. But here it is not
>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>> 
>> So my question is: why was this not setTitle(forControlState:) or 
>> forButtonState, etc...?
> 
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
> 
> -- 
> -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] [Proposal] Refining Identifier and Operator Symbology

[Benjamin Spratling via swift-evolution]

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

___
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]

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 characters labeled "mathematical" into our
set of operators because many (such as the null set symbol) do not operate
on anything and instead represent mathematical objects, which therefore
suggests that if anything those should be valid identifier characters and
not operator characters. This task becomes impossible once one considers
that, in mathematics, symbols such as nabla are both used as operators
_and_ may stand alone.

The bottom line is that this laborious work of classification is what the
Unicode Consortium is for. I am convinced that we, the Swift community, are
not capable of undertaking this task with any semblance of coherence. Jacob
and I spent two or three emails going back and forth about the inclusion of
"tiny" and "miny," two symbols I'll bet you've never contemplated using in
your code. We also discussed whether pentagons and hexagons were
appropriate (and yes, these are classed as mathematical symbols; on the one
hand, these are plausibly operator-looking characters, but on the other
hand, angles are not considered operators, and shapes can no more take an
operand than can angles). Extending this work throughout the disparate
ranges of mathematical symbols in Unicode 9 is untenable.

Note that while Unicode does not _yet_ have recommendations on operator
characters, and while we cannot wait until it does in order to move
forward, it is not out of the question that a future version of Swift could
incorporate that work even if we remove non-ASCII characters today.
However, if we move ahead with an ad-hoc selection of Unicode characters,
we may never be able to converge with a future Unicode recommendation
without breaking backwards source compatibility.

Thus, I think it's important to be specific about what code you can no
longer write if non-ASCII operators are removed. It is not true that we
have removed "almost every operator." Although we are proposing the removal
of the vast majority of currently valid operator characters, based on our
survey of code bases available to us, we believe that we are removing _zero
or very nearly zero operators_ in usage today. Should you have a use case
we haven't contemplated, I'd be very very keen to hear about it.


On Wed, Oct 19, 2016 at 21:06 Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:


> 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 you get to the section where latin characters are just
drawn in different fonts,at which point, I make no assertions).  ASCII is
not the future.  We have unicode for a reason, so we can type what we mean.

>  Obviously, we would want to enable as many operators as possible to
continue functioning.
I don’t find this statement to be consistent with the others.  From my
perspective, it looks like the proposal deleted as many operators as
possible.

>   •   Operators suffer from low discoverability and difficult
readability. They use symbols, not names. This places a cognitive cost on
users with respect to both recall ("What is the operator that applies the
behavior I need?") and recognition ("What does the operator in this code
do?").

Requiring a developer to read “formUnion(with:)” is a large cognitive
burden for someone trying to use Swift to solve problems in their field.
Not all developers are only UI app makers or coding philosophers.  Many are
engineers and scientists trying to find a tool to get their job done.  For
these fields, using the correct mathematical operators significantly
reduces the difficulty in reading code, which reduces the difficulty
finding bugs.  Swift offers a major performance improvement over the tools
they may currently be using to get their jobs done, i.e. MatLab and
Mathematica.  While those tools offer other features Swift never will,
there is always a push in research fields for better performance and
independence from a desktop meta-tool, so battle tested algorithms are
frequently moved out into stand-alone libraries.  Yes, at times, that has
been my job.  Occasionally, someone working on advanced math libraries
chimes in on the forum, I know there are folks working on vector libraries
out there, I’m sure their code would be more legible using the correct
vector-oriented operators.  With the ascii-only operators, there is a lack
of distinction between scalar products, and vector products, for example.
Something which can be represented easily with extended unicode operators.

If someone really wants to 

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

[Matthew Johnson via swift-evolution]

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 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 Unicode Consortium completes its work.  I think it 
would be far better to defer the changes to valid operator symbols until that 
time (removing only symbols which are currently treated as operators but for 
which the proposal suggests should be available for identifiers instead).

The argument against symbols is reasonable for *new* operators, defined by an 
individual programmer.  But operator symbols that have been defined by 
mathematics for a very long time are extremely useful.  Notation matters.  They 
impose very little additional burden when learned along side the mathematical 
concepts.  IMO, the best argument against using unicode symbols for operators 
defined by mathematics is that they are currently difficult to type.  This is 
an argument with a limited lifespan and should not carry more weight than it 
deserves in the design of a language positioned to be the language for the next 
20 years.  I strongly believe that removing them, even temporarily, is a 
mistake.


> On Oct 19, 2016, at 1:34 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 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:
> 
> 
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
> We'd welcome your initial thoughts, and will probably submit a PR soon to the 
> swift-evolution repo for a formal review. Full text follows below.
> 
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
> 
> 
> Refining Identifier and Operator Symbology
> 
> Proposal: SE- 
> 
> Authors: Jacob Bandes-Storch , Erica Sadun 
> , Xiaodi Wu , Jonathan 
> Shapiro
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks to refine and rationalize Swift's identifier and operator 
> symbology. Specifically, this proposal:
> 
> adopts the Unicode recommendation for identifier characters, with some minor 
> exceptions;
> restricts the legal operator set to the current ASCII operator characters;
> changes where dots may appear in operators; and
> disallows Emoji from identifiers and operators.
>  
> Prior
>  discussion threads & proposals
> 
> Proposal: Normalize Unicode identifiers 
> 
> Unicode identifiers & operators 
> ,
>  with pre-proposal 
>  (a 
> precursor to this document)
> Lexical matters: identifiers and operators 
> 
> Proposal: Allow Single Dollar Sign as Valid Identifier 
> 
> Free the '$' Symbol! 
> 
> Request to add middle dot (U+00B7) as operator character? 
> 
>  
> Guiding
>  principles
> 
> Chris Lattner has written:
> 
> …our current operator space (particularly the unicode segments covered) is 
> not super well considered. It would be great for someone to take a more 
> systematic pass over them to rationalize things.
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> …any proposal that breaks:
> 
> let  = "moof"
> will not be tolerated. 

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

[Benjamin Spratling via swift-evolution]

> 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 you get to the section where latin characters are just drawn in 
different fonts,at which point, I make no assertions).  ASCII is not the 
future.  We have unicode for a reason, so we can type what we mean.

>  Obviously, we would want to enable as many operators as possible to continue 
> functioning.
I don’t find this statement to be consistent with the others.  From my 
perspective, it looks like the proposal deleted as many operators as possible.

>   •   Operators suffer from low discoverability and difficult 
> readability. They use symbols, not names. This places a cognitive cost on 
> users with respect to both recall ("What is the operator that applies the 
> behavior I need?") and recognition ("What does the operator in this code 
> do?"). 

Requiring a developer to read “formUnion(with:)” is a large cognitive burden 
for someone trying to use Swift to solve problems in their field.  Not all 
developers are only UI app makers or coding philosophers.  Many are engineers 
and scientists trying to find a tool to get their job done.  For these fields, 
using the correct mathematical operators significantly reduces the difficulty 
in reading code, which reduces the difficulty finding bugs.  Swift offers a 
major performance improvement over the tools they may currently be using to get 
their jobs done, i.e. MatLab and Mathematica.  While those tools offer other 
features Swift never will, there is always a push in research fields for better 
performance and independence from a desktop meta-tool, so battle tested 
algorithms are frequently moved out into stand-alone libraries.  Yes, at times, 
that has been my job.  Occasionally, someone working on advanced math libraries 
chimes in on the forum, I know there are folks working on vector libraries out 
there, I’m sure their code would be more legible using the correct 
vector-oriented operators.  With the ascii-only operators, there is a lack of 
distinction between scalar products, and vector products, for example.  
Something which can be represented easily with extended unicode operators.

If someone really wants to make the operator sets so restricted, fine, make 
that a policy at your company.  Please don’t delete it from the language.  In 
the course on Swift 3 that I’m teaching, I even recommend users don’t create 
operators they can’t easily type, but keyboards are going to get better.  Heck, 
I’m paying as much for an Apple keyboard these days as I paid for a cell phone 
back in 2001.

Look, go easy on me.  I’m still reeling from discovering that weak references 
cause memory to be persisted until the app itself acts as a garbage collector.  
I was unable to bring myself to write code for 2 days following that.  Please 
don’t take away my icing, too.  I’m not sure I can keep writing code if you do. 
 Removing standard math operators would make my code look I’m constantly 
writing 1980’s work arounds instead of clean code.

I have a hard time accepting that essentially reverting the character set for 
Swift to ASCII is really a good move forward.  I think the proposal reflects 
some good work on codifying identifiers, but I think the removal of emoji and 
almost every operator means there’s more work to be done before this proposal 
is ready for acceptance.

-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

[Xiaodi Wu via swift-evolution]

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 very strong argument for restricting operator
characters to ASCII. I'm going to quote from Erica Sadun, who's put this
much better than I can:

[begin quote]

• Operators suffer from low discoverability and difficult readability. They
use symbols, not names. This places a cognitive cost on users with respect
to both recall ("What is the operator that applies the behavior I need?")
and recognition ("What does the operator in this code do?").
• This cost is obviously highest when symbols are not tied to conventional
standards like `∪` for union and `⊇` for superset. `∪` is a standard,
mathematical representation. It’s widely accepted and widely used. Even so,
 recognizing `formUnion(with:)` may work better for many coders than
recalling what the `∪` (or, worse, `⊇`) operator does, even when you end up
having to create suites of specialized selectors. As operators become more
self-defined or esoteric, costs rise.

[end quote]

As to your specific example, there are indeed good reasons why it is not
unreasonable to jettison support for, say, less-than-or-equal-to. For one,
even if you have a configurable keyboard, every reasonable keyboard that
could have the less-than-or-equal-to symbol will also have < and =, and <=
is the standard operator in Swift for that concept.

As for emoji, their not being included is based on the reasoning that they
are not required to support any real-world language; removal of "moof" is
not a dealbreaker.

On Wed, Oct 19, 2016 at 19:09 Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

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

Swift operator characters will be limited to only the following ASCII
characters:

! % & * + - . / < = > ? ^ | ~

For a mathematician / scientist / engineer, they have an easier time
catching errors when the code on their screen look more like what they
write on paper.  Hence the only good reasons to leave sin() as a global
function instead of a computed property.  Obviously, we don’t have 2D
layout in Swift, but finally using the right operator characters instead of
the ridiculous ascii hacks was a breath of fresh air Swift breathed into my
code.  The state of operators in C languages was abysmal, and its legacy is
still here.  Take the blinders off for a moment and realize that
“repetition” isn’t a great semantic: “&&” and “===“.  They're a side effect
of the hardware & character encoding sets available to developers in past
decades, not a goal for the future.  Sure, we don’t have screens on every
key so I can set up my own domain specific operator character sets without
having to scroll through a giant list of unused characters, but finally the
second barrier had fallen.  And at least there are prototypes and rumors of
those keyboards out in the wild.

There’s just no good reason to make
≤ ≥ ≠ ±
not valid operators.

“in homage to Swift's origins, we permit  and  in identifiers."

That’s a blatant attempt at a cheat.  Wrong answer.

It’s true there are inconsistencies of the choice of whether a particular
symbol is an operator or identifier, but I’d rather resolve that instead of
blow everything away.

- - From me

-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] Constant initialization and unreachable code.

[Charlie Monroe via swift-evolution]

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 come to realize that this has a huge advantage of keeping all the 
debugging options together within the entire project and it eliminates any 
warnings.

> On Oct 19, 2016, at 1:50 PM, 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 code, if I need create mode switches (constant Bools) 
> so that I can move back and forth between different features/implementations 
> for testing, developing experimental features, migration, etc.  Currently if 
> I write the following:
> 
> let useFoo = true
> 
> if useFoo {
> // Foo code
> } else {
> // Non-Foo code
> }
> 
> I will get compiler warnings either way that there’s unreachable code based 
> on the value of useFoo.  That makes sense in most cases, but in some cases I 
> need to leave the code as is for a while, and I hate leaving long-standing 
> compiler warnings in production code.  (If it’s yellow, you need to pay 
> attention to it.)  So I poked around and discovered that if I use the 
> following declaration of useFoo, the warnings go away.
> 
> let useFoo = { return true }()
> 
> So, the question is, is this intentional? The compiler could certainly 
> ascertain that useFoo will always be true and carry out the same dead code 
> detection as for the first declaration.  If this isn’t intentional, and the 
> compiler may at some point optimize away the closure and trigger dead code 
> warnings, I might come up with a proposal that there is some idiom that 
> allows one to do the above without the warnings.  I’m really not a fan of 
> #define (because it’s just butt-ugly in such a beautiful language), but its 
> existence is unavoidable for some cases.  
> 
> And, as I write this, I realized I haven’t tried declaring useFoo as var, but 
> I expect that would trigger a warning that useFoo is not modified and should 
> be defined by let.  I think this is a use case that, for practical purposes, 
> should be covered to allow this type of evolution of code without generating 
> warnings.  If the current behavior is intentional and going to stay, then 
> that’s probably the best solution.
> 
> -d
> 
> ___
> 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] make @nonobjc the default

[Jay Abbott via swift-evolution]

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 way, the people maintaining an interface have to either a) write a
wrapper with a Swifty interface; or b) explicitly cop out and use @objc and
inform their users that they may also have to do the same in some
situations; or c) persuade their employers to let them port the whole thing
to pure Swift, which sounds like a lot of fun and is probably what they
really want to do :D.

I'm not really sure how this works though, at what level this is applied?
Maybe it's more to do with the default build settings in Xcode than Swift
itself? I just would rather see Swift stand alone by default.



On Wed, 19 Oct 2016 at 03:51 Douglas Gregor  wrote:

>
>
> Sent from my iPhone
>
> > On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Currently, if you extend a class that comes from obj-c, Swift assumes
> you want to make those methods available to call from obj-c code. If you
> add operators, you must declare them as @nonobjc otherwise the bridging
> header which is generated declares obj-c methods with the operator
> character as the method name, which isn't valid in obj-c and causes compile
> errors.
>
> The operators bit is an outright bug, which I believe has already been
> fixed in master.
>
> > I'm just wondering how others feel about this - my feeling is that a
> Swift developer should not have to know anything about obj-c when doing
> Swifty things to a bridged class from a framework (such as extending it).
> As far as they are concerned the framework class should compile the same as
> if it were fully implemented in Swift.
>
> Modulo bugs like the above, I think we already have this property? Swift
> declarations are exposed to Objective-C if they can be. One doesn't
> generally have to think about it unless you're trying to use those
> declarations from Objective-C.
>
> > Thoughts?
>
> I actually thought you were going further with this, eliminating the
> inferred @objc except in cases where it's needed to work with an existing
> framework. That's something I'd love to see someone working on.
>
>   - Doug
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Constant initialization and unreachable code.

[David Goodine via swift-evolution]

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 features/implementations for 
testing, developing experimental features, migration, etc.  Currently if I 
write the following:

let useFoo = true

if useFoo {
// Foo code
} else {
// Non-Foo code
}

I will get compiler warnings either way that there’s unreachable code based on 
the value of useFoo.  That makes sense in most cases, but in some cases I need 
to leave the code as is for a while, and I hate leaving long-standing compiler 
warnings in production code.  (If it’s yellow, you need to pay attention to 
it.)  So I poked around and discovered that if I use the following declaration 
of useFoo, the warnings go away.

let useFoo = { return true }()

So, the question is, is this intentional? The compiler could certainly 
ascertain that useFoo will always be true and carry out the same dead code 
detection as for the first declaration.  If this isn’t intentional, and the 
compiler may at some point optimize away the closure and trigger dead code 
warnings, I might come up with a proposal that there is some idiom that allows 
one to do the above without the warnings.  I’m really not a fan of #define 
(because it’s just butt-ugly in such a beautiful language), but its existence 
is unavoidable for some cases.  

And, as I write this, I realized I haven’t tried declaring useFoo as var, but I 
expect that would trigger a warning that useFoo is not modified and should be 
defined by let.  I think this is a use case that, for practical purposes, 
should be covered to allow this type of evolution of code without generating 
warnings.  If the current behavior is intentional and going to stay, then 
that’s probably the best solution.

-d

___
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]

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
> 
> Swift operator characters will be limited to only the following ASCII 
> characters:
> 
> ! % & * + - . / < = > ? ^ | ~
> 

For a mathematician / scientist / engineer, they have an easier time catching 
errors when the code on their screen look more like what they write on paper.  
Hence the only good reasons to leave sin() as a global function instead of a 
computed property.  Obviously, we don’t have 2D layout in Swift, but finally 
using the right operator characters instead of the ridiculous ascii hacks was a 
breath of fresh air Swift breathed into my code.  The state of operators in C 
languages was abysmal, and its legacy is still here.  Take the blinders off for 
a moment and realize that “repetition” isn’t a great semantic: “&&” and “===“.  
They're a side effect of the hardware & character encoding sets available to 
developers in past decades, not a goal for the future.  Sure, we don’t have 
screens on every key so I can set up my own domain specific operator character 
sets without having to scroll through a giant list of unused characters, but 
finally the second barrier had fallen.  And at least there are prototypes and 
rumors of those keyboards out in the wild.

There’s just no good reason to make
≤ ≥ ≠ ± 
not valid operators.

“in homage to Swift's origins, we permit  and  in identifiers."

That’s a blatant attempt at a cheat.  Wrong answer.

It’s true there are inconsistencies of the choice of whether a particular 
symbol is an operator or identifier, but I’d rather resolve that instead of 
blow everything away.

- - From me

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

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

[Jeremy Pereira via swift-evolution]

> 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 optional integers. It takes double the 
> space to store [Int?] than to store [Int] because of alignment.

Is this a general problem with Swift? Are lots of people complaining that they 
are running out of space for their Optional arrays?


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

> 
> So what do you think? Can we break C compatibility a bit for better Swift 
> types?


Well it’s not just C compatibility, it’s underlying processor compatibility. 
And actually, yes, I think C compatibility is vastly more important than being 
able to make your [Int?] arrays smaller considering that full 2’s complement 
numbers is what the OS calls and libc calls are expecting.

> 
> - Guoye
> ___
> 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

[Alex Blewitt via swift-evolution]

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' are probably 
not appropriate within this document. It would be better to have a sound basis 
accepted, then propose specific variations on top of it at a later stage (such 
as 'Allow dogcow as an identifier').

Amongst other things, this proposal permits face and MK as an identifier, 
which is probably not intentional. It would probably be better to define:

identifier -> identifier-head identifier-characters
identifier -> 

which would thus prevent the use of  on its own (or  on its own) being used 
in an identifier.

Alex

> On 19 Oct 2016, at 07:34, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 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:
> 
> 
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
> We'd welcome your initial thoughts, and will probably submit a PR soon to the 
> swift-evolution repo for a formal review. Full text follows below.
> 
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
> 
> 
> Refining Identifier and Operator Symbology
> 
> Proposal: SE- 
> 
> Authors: Jacob Bandes-Storch , Erica Sadun 
> , Xiaodi Wu , Jonathan 
> Shapiro
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks to refine and rationalize Swift's identifier and operator 
> symbology. Specifically, this proposal:
> 
> adopts the Unicode recommendation for identifier characters, with some minor 
> exceptions;
> restricts the legal operator set to the current ASCII operator characters;
> changes where dots may appear in operators; and
> disallows Emoji from identifiers and operators.
>  
> Prior
>  discussion threads & proposals
> 
> Proposal: Normalize Unicode identifiers 
> 
> Unicode identifiers & operators 
> ,
>  with pre-proposal 
>  (a 
> precursor to this document)
> Lexical matters: identifiers and operators 
> 
> Proposal: Allow Single Dollar Sign as Valid Identifier 
> 
> Free the '$' Symbol! 
> 
> Request to add middle dot (U+00B7) as operator character? 
> 
>  
> Guiding
>  principles
> 
> Chris Lattner has written:
> 
> …our current operator space (particularly the unicode segments covered) is 
> not super well considered. It would be great for someone to take a more 
> systematic pass over them to rationalize things.
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> …any proposal that breaks:
> 
> let  = "moof"
> will not be tolerated. :-) :-)
>  
> Motivation
> 
> By supporting custom Unicode operators and identifiers, Swift attempts to 
> accomodate programmers and programming styles from many languages and 
> cultures. It deserves a well-thought-out specification of which characters 
> are valid. 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 documentation.
> 
> Identifiers, which serve as names for 

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

[Alex Blewitt via swift-evolution]

> 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 
>>> > 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.
>> 
>> There are two ways to do this (using Int8 for example)
>> 1. 0xFF reserved to mean nil. As this normally means -1, all negative 
>> numbers now use complements rather than two’s complement form. This breaks a 
>> lot of binary math.
>> 
>> 2. 0x80 reserved to mean nil. This is normally -128. Overflow would have to 
>> be modified in order to support this (otherwise, 127 + 1 == nil). bit 
>> padding no longer works (0x80 would expand to 0xFF80 for a Int16 with bit 
>> padding, not 0x8000)
> 
> Yes, 0x80 is better for arithmetic, checking for nil might be slower.
> 
>> 
>>> 
>>> Interacting with C/Obj-C is a major concern, but since we are already 
>>> importing some of the unsigned integers as Int which loses half the values, 
>>> one value is not such big a drawback. Alternatively, we could leave current 
>>> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
>>> generate any instructions since the invalid value already represents nil.
>>> 
>> 
>> As the appropriate integer minimum value may already be in use in C or 
>> Objective C code, I believe you would need to define a new integer types to 
>> support this sort of constrained type. 
>> 
>> Where I would see something like this be most appropriate would be for 
>> supporting a “BigNumber” type in the language, preferably as the default 
>> integer type. Ruby does this for example with Fixnum/Bignum - all values in 
>> Ruby are actually tagged pointers (where the lower bits are set to cause 
>> invalid alignment of a pointer in order to indicate it is a special case 
>> immediate value). So if the lowest bit is set, the value is a FixNum integer 
>> with a lower max/higher min than a traditional integer. On overflow, the 
>> value is promoted to be a BigNum, which is a reference to an arbitrary sized 
>> integer on the heap.
>> 
>> -DW
> 
> I would also like to see big number some day.

I've just finished the implementation of Decimal in Foundation on Linux, which 
provides for a greater (though not unlimited) space of numbers.

https://github.com/apple/swift-corelibs-foundation/pull/687

Alex___
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]

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, and Swift can expand its operator characters accordingly in the
future.

Moreover, we do not know of any non-ASCII operators in the wild at present.
A branch of the Swift standard library tried out set algebra operators, but
that has not become the chosen API.

Finally, ASCII-only operators allow us to postpone design of more
sophisticated confusables checking to a later point. Unicode has seven or
eight varieties of forward slashes, at least several of which are plausible
and distinct operator characters, and figuring out how to deal with this
scenario would benefit from work from the Unicode Consortium that is still
pending.
On Wed, Oct 19, 2016 at 15:47 Jean-Denis Muys via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 the scientific community and this change, IIUC, is
> very hostile to any scientific computing.
>
> Jean-Denis
>
>
>
> On 19 Oct 2016, at 08:34, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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:
>
>
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>
> We'd welcome your initial thoughts, and will probably submit a PR soon to
> the swift-evolution repo for a formal review. Full text follows below.
>
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
>
>
> Refining Identifier and Operator Symbology
>
>- Proposal: SE-
>
> 
>- Authors: Jacob Bandes-Storch , Erica
>Sadun , Xiaodi Wu ,
>Jonathan Shapiro
>- Review Manager: TBD
>- Status: Awaiting review
>
>
> 
> Introduction
>
> This proposal seeks to refine and rationalize Swift's identifier and
> operator symbology. Specifically, this proposal:
>
>- adopts the Unicode recommendation for identifier characters, with
>some minor exceptions;
>- restricts the legal operator set to the current ASCII operator
>characters;
>- changes where dots may appear in operators; and
>- disallows Emoji from identifiers and operators.
>
>
> Prior
> discussion threads & proposals
>
>- Proposal: Normalize Unicode identifiers
>
>- Unicode identifiers & operators
>
> ,
>with pre-proposal
> (a
>precursor to this document)
>- Lexical matters: identifiers and operators
>
> 
>- Proposal: Allow Single Dollar Sign as Valid Identifier
>
>- Free the '$' Symbol!
>
> 
>- Request to add middle dot (U+00B7) as operator character?
>
> 
>
>
> Guiding
> principles
>
> Chris Lattner has written:
>
> …our current operator space (particularly the unicode segments covered) is
> not super well considered. It would be great for someone to take a more
> systematic pass over them to rationalize things.
>
> We need a token to be unambiguously an operator or identifier - we can
> have different rules for the leading and subsequent characters though.
>
> …any proposal that breaks:
>
> let  = "moof"
>
> will not be tolerated. :-) :-)
>
>
> 

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

[Jean-Denis Muys via swift-evolution]

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 the scientific community and this change, IIUC, is very hostile 
to any scientific computing.

Jean-Denis



> On 19 Oct 2016, at 08:34, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> 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:
> 
> 
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
> We'd welcome your initial thoughts, and will probably submit a PR soon to the 
> swift-evolution repo for a formal review. Full text follows below.
> 
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
> 
> 
> Refining Identifier and Operator Symbology
> 
> Proposal: SE- 
> 
> Authors: Jacob Bandes-Storch , Erica Sadun 
> , Xiaodi Wu , Jonathan 
> Shapiro
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks to refine and rationalize Swift's identifier and operator 
> symbology. Specifically, this proposal:
> 
> adopts the Unicode recommendation for identifier characters, with some minor 
> exceptions;
> restricts the legal operator set to the current ASCII operator characters;
> changes where dots may appear in operators; and
> disallows Emoji from identifiers and operators.
>  
> Prior
>  discussion threads & proposals
> 
> Proposal: Normalize Unicode identifiers 
> 
> Unicode identifiers & operators 
> ,
>  with pre-proposal 
>  (a 
> precursor to this document)
> Lexical matters: identifiers and operators 
> 
> Proposal: Allow Single Dollar Sign as Valid Identifier 
> 
> Free the '$' Symbol! 
> 
> Request to add middle dot (U+00B7) as operator character? 
> 
>  
> Guiding
>  principles
> 
> Chris Lattner has written:
> 
> …our current operator space (particularly the unicode segments covered) is 
> not super well considered. It would be great for someone to take a more 
> systematic pass over them to rationalize things.
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> …any proposal that breaks:
> 
> let  = "moof"
> will not be tolerated. :-) :-)
>  
> Motivation
> 
> By supporting custom Unicode operators and identifiers, Swift attempts to 
> accomodate programmers and programming styles from many languages and 
> cultures. It deserves a well-thought-out specification of which characters 
> are valid. 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 documentation.
> 
> Identifiers, which serve as names for various entities, are linguistic in 
> nature and must permit a variety of characters to properly serve 
> non–English-speaking coders. This issue has been considered by the 
> communities of many programming languages already, and the Unicode Consortium 
> has published recommendations on how to choose identifier character sets — 
> Swift should make an effort to conform to these recommendations.
> 
> Operators, on the other hand, 

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

[Daniel Vollmer via swift-evolution]

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 as well.

Daniel.

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

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

[Jacob Bandes-Storch via swift-evolution]

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:


https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md

We'd welcome your initial thoughts, and will probably submit a PR soon to
the swift-evolution repo for a formal review. Full text follows below.

—Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro


Refining Identifier and Operator Symbology

   - Proposal: SE-
   

   - Authors: Jacob Bandes-Storch , Erica Sadun
   , Xiaodi Wu , Jonathan
   Shapiro
   - Review Manager: TBD
   - Status: Awaiting review


Introduction

This proposal seeks to refine and rationalize Swift's identifier and
operator symbology. Specifically, this proposal:

   - adopts the Unicode recommendation for identifier characters, with some
   minor exceptions;
   - restricts the legal operator set to the current ASCII operator
   characters;
   - changes where dots may appear in operators; and
   - disallows Emoji from identifiers and operators.

Prior
discussion threads & proposals

   - Proposal: Normalize Unicode identifiers
   
   - Unicode identifiers & operators
   
,
   with pre-proposal
    (a
   precursor to this document)
   - Lexical matters: identifiers and operators
   

   - Proposal: Allow Single Dollar Sign as Valid Identifier
   
   - Free the '$' Symbol!
   

   - Request to add middle dot (U+00B7) as operator character?
   


Guiding
principles

Chris Lattner has written:

…our current operator space (particularly the unicode segments covered) is
not super well considered. It would be great for someone to take a more
systematic pass over them to rationalize things.

We need a token to be unambiguously an operator or identifier - we can have
different rules for the leading and subsequent characters though.

…any proposal that breaks:

let  = "moof"

will not be tolerated. :-) :-)


Motivation

By supporting custom Unicode operators and identifiers, Swift attempts to
accomodate programmers and programming styles from many languages and
cultures. It deserves a well-thought-out specification of which characters
are valid. 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 documentation.

Identifiers, which serve as *names* for various entities, are linguistic in
nature and must permit a variety of characters to properly serve
non–English-speaking coders. This issue has been considered by the
communities of many programming languages already, and the Unicode
Consortium has published recommendations on how to choose identifier
character sets — Swift should make an effort to conform to these
recommendations.

Operators, on the other hand, should be rare and carefully chosen, because
they suffer from low discoverability and difficult readability. They are by
nature *symbols*, not names. This places a cognitive cost on users with
respect to both recall ("What is the operator that applies the behavior I
need?") and recognition ("What does the operator in this code do?").
While *almost
every* nontrivial program defines many new identifiers, most programs do
not define new operators.

As operators become more esoteric or customized, the cognitive cost rises.
Recognizing a function name like formUnion(with:) is simpler for many
programmers than recalling what the ∪ operator does. Swift's current
operator character set includes many characters that aren't traditional and