Re: [swift-evolution] Proposal SE-0009 Reconsideration

[Paul Ossenbruggen via swift-evolution]

While not as nice, Vladimir’s colon suggestion could work. :g()

Reminds a bit of C++ but not bad.

> On May 26, 2016, at 2:05 PM, Brent Royal-Gordon  
> wrote:
> 
>> * Already very similar notation for enums where you leave off the entity 
>> name when it can be implied.
> 
> That's the problem. Leading dot already means something—it means "look up a 
> static member of the type we're expecting here". (That's what you're actually 
> doing when you access an "enum case".) It can't mean two different things in 
> the same place.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Paul Ossenbruggen via swift-evolution]

+1 can we get rid of void?

> On Apr 19, 2016, at 7:11 AM, Patrick Smith via swift-evolution 
>  wrote:

> I think () reads nicer than Void, and has a sort of beauty that () literally 
> looks like nothing, unlike some word. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Discussion] Deprecation Linking

[Paul Ossenbruggen via swift-evolution]

I work on an API and like any API, we frequently deprecate methods (more than 
we would like). I think would be useful, when you deprecate something there is 
a link from the old method to the new method(s). With this facility it would be 
possible to match the old parameter name with the new names, assuming they 
match in type and name and automatically fill in much of the information so you 
don’t have to do as much work to adopt the new API. The user would just have to 
add the new parameters, if a parameter is removed, it would delete it. There 
would also be some basic checking done to make sure the new API matched. This 
would work on the vast bulk of APIs. When there are multiple choices, multiple 
replacements would be shown and selected in the IDE. It would use most of the 
current attributes available in Swift. I am thinking of syntax something like 
this, very rough: 

#begindeprecation(message=“optional comment”, available=iOS 8.0)
func fetchProjects(query query : String?) {
   // some code
}
#replacement(message=“some comment”), available=iOS 9.0)
func fetchProjects(query query : String?, scope : String?) {
   // some code
}
#replacement(message=“some comment 2”, available=iOS 9.0) 
func fetchProjects((query query : String?, scope : NSPredicate) {
}
#enddeprecation

In this example, the IDE would show the two replacements, and let you select 
one of them, then it would automatically fill in the “query" with the 
replacement, and then leave a place for you to enter the “scope” parameter. If 
it is just deprecated with no replacements you would just leave out the 
#replacement part. The comment part is optional. The comments would also appear 
in the documentation for the method as it currently does with the deprecation 
attributes. Eventually when you are done supporting the deprecation, you would 
remove the # and the old methods. 

The idea is to enhance the process of deprecation, as well as simplify and 
speed adoption of the new APIs. The user would not have to spend as much time 
researching the new way to do things, they would just be presented with the new 
way. I imagine this would also be useful to developers on the same team. I 
speak specifically of methods here but this would apply to other entities that 
you might want to deprecate as well. I am sure there is more to consider here 
but thought I would start out simple and the most common case. 

- Paul 






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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

How about: 

notprivateatall
notveryprivate
mostlyprivate
stayout!!!private

Sorry. April fools.. :-) 

> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> "or within my whole program (external)". That caused a double-take on its own.
> 
> external things are not within, they are outside. 'external' could be a 
> replacement term for 'public', not for 'internal'.
> 
> This may well be a subjective thing, but I don't think in files, I think in 
> modules because that's been the default for several years now. If I create a 
> new type I am implicitly making it visible to everywhere within this module; 
> it is not outside the module so it is not external. I may then choose to make 
> it less visible, but it does not 'go inside' when I do this.
> 
> If you think in files, I cannot say you are wrong, because it is subjective. 
> But this is why I have been arguing for non-subjective keywords. I cannot 
> make 'fileprivate' pretty for you but I do know that when we both read it we 
> both understand what it means. That's why it hasn't gone away: it satisfies 
> the criterion of clarity.
> 
> Find a pretty alternative with the word 'file' baked into it and I'm with you.
> 
> On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  > wrote:
> A new type is implicitly visible *outside* of the file it is defined in and 
> hence it is “external” from that point of view. This arrangement seems more 
> “human” to me. Someone just learning isn’t going to know about modules or how 
> the compiler is treating things anyway and they would almost never run into 
> “external” because it’s the default and there’s no reason to specify it most 
> of the time. IMO, this “fits” how I think about source code while I’m writing 
> it - where do I want to be able to use this symbol? Either hidden away and 
> safe (private), inside this file I’m working with (internal), or within my 
> whole program (external).
> 
> l8r
> Sean
> 
> 
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien  > > wrote:
> >
> > A new type is implicitly internal to a module. Implicitly specifying it as 
> > 'external' is just plain confusing.
> >
> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution 
> > > wrote:
> > I know this is kind of winding down, and there seems to be a kind of 
> > begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), 
> > but I still really don’t like it so I’m going to toss out my current 
> > favorite configuration and try to stop caring and defer to the core team to 
> > make an executive decision so we can all move on with our lives. :P
> >
> > public - unchanged, visible “everywhere"
> > external - visible outside of the file (module, the default)
> > internal - visible only within the file
> > private - visible only within the scope
> >
> > I really like the existing private and I use it a lot to build collections 
> > of small classes and structs that work together rather than a large 
> > class/struct that tries to “be everything”. In those scenarios, traditional 
> > OO private would be too restrictive and even a “protected” access type 
> > wouldn’t work because I’m trying to avoid building inheritance hierarchies. 
> > I really need something like “friend” (ugly) or the, imo, much more elegant 
> > file-scoped access and if that one is renamed “fileprivate” I’ll be really 
> > sad seeing such an ugly label all over the place. I’d go so far as to 
> > suggest that an ugly name for this access level would actively discourage 
> > its use and while some might have that as a goal, to me that would 
> > encourage the creation of larger “do everything” classes instead of 
> > clusters of smaller classes and structs and protocols.
> >
> > l8r
> > Sean
> >
> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution 
> > > > wrote:
> > >
> > >> I’ve seen a number of concerns on this list about moduleprivate, and how 
> > >> it penalizes folks who want to explicitly write their access control.  
> > >> I’ve come to think that there is yes-another possible path forward here 
> > >> (which I haven’t seen mentioned so far):
> > >>
> > >> public
> > >> internal
> > >> fileprivate
> > >> private
> > >>
> > >> The advantages, as I see them are:
> > >> 1) We keep public and private meaning the “right” and “obvious” things.
> > >> 2) The declmodifiers “read” correctly.
> > >> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> > >> changes is that some uses of Swift 2 “private” will be migrated to 
> > >> “fileprivate”, which makes the intent of the code much more clear.
> > >> 4) fileprivate is the unusual and 
> > >> not-really-precedented-in-other-languages modifier, and it would still 
> > >> be 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

If not interfile I can suggest infile again too.

> On Mar 31, 2016, at 12:38 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I’ve seen a number of concerns on this list about moduleprivate, and how it 
>> penalizes folks who want to explicitly write their access control.  I’ve 
>> come to think that there is yes-another possible path forward here (which I 
>> haven’t seen mentioned so far):
>> 
>> public
>> internal
>> fileprivate
>> private
> 
> I don't like how this ends up penalizing `fileprivate` with an ugly compound 
> keyword. I feel like, with the way I tend to factor my code, I would continue 
> using it reasonably often, and it would suck to have to use an ugly keyword.
> 
> Consider some of the places where we're still going to need `fileprivate`:
> 
> * Members used by operators or other free functions.
> * Members of nested types meant to be used only by the containing type.
> * Code which splits a type up into extensions. (We want to encourage this.)
> * Code which pairs a type with an extension adding an API using that type to 
> another type. (We want to encourage this too.)
> 
> These are all things we want to encourage, and things where just making them 
> `internal` is going to be tempting. Access control is a delicate thing; using 
> tight access control imposes obvious short-term costs for subtle long-term 
> gains, and so you're always tempted to cheat by making things broader than 
> they should be for your own convenience. The only thing keeping you from 
> cheating is your own discipline.
> 
> I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome 
> keyword, and `internal` works just as well but requires no typing at all, a 
> lot of people are going to do the wrong thing. We don't want that to happen.
> 
> -- 
> 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] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

One bonus it is a real word so autocorrect doesn’t fix it! I checked the 
dictionary and there are no negative or misleading meaning. 

It is a verb though, this is not being used as a verb in this case. 

http://www.dictionary.com/browse/interfile 


> On Mar 30, 2016, at 10:04 PM, Paul Ossenbruggen  wrote:
> 
> public
> internal
> interfile
> private
> 
> still googleable and very clear its scope and meaning, nice latin root. 
> Doesn’t overload “private”, slightly shorter. 
> 
> 
>> On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> Looks good to me.
>> 
>> -Thorsten 
>> 
>>> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution 
>>> :
>>> 
 On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
 How about we continue this trend, and follow other existing Swift keywords 
 that merge two lowercase words (associatedtype, typealias, etc), and use:
 
  public
  moduleprivate
  fileprivate
  private
 
 The advantages, as I see them are:
 1) We keep public and private meaning the “right” and “obvious” things.
 2) The declmodifiers “read” correctly.
 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
 parenthesized keyword approach.
 4) The unusual ones would be “googable”.
 5) Support for named submodules could be “dropped in” by putting the 
 submodule name/path in parens: private(foo.bar.baz) or 
 moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
 natural than putting keywords in parens.
>>> 
>>> I’ve seen a number of concerns on this list about moduleprivate, and how it 
>>> penalizes folks who want to explicitly write their access control.  I’ve 
>>> come to think that there is yes-another possible path forward here (which I 
>>> haven’t seen mentioned so far):
>>> 
>>> public
>>> internal
>>> fileprivate
>>> private
>>> 
>>> The advantages, as I see them are:
>>> 1) We keep public and private meaning the “right” and “obvious” things.
>>> 2) The declmodifiers “read” correctly.
>>> 3) Compared to Swift 2, there is almost no change.  The only thing that 
>>> changes is that some uses of Swift 2 “private” will be migrated to 
>>> “fileprivate”, which makes the intent of the code much more clear.
>>> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
>>> modifier, and it would still be “googable”.
>>> 5) The addresses the “excessively long” declmodifier problem that several 
>>> people are concerned with.
>>> 6) Support for named submodules could be “dropped in” by parameterizing 
>>> “internal”.
>>> 
>>> Thoughts?
>>> 
>>> -Chris
>>> ___
>>> 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] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

One more possibility:

public
intermodule
interfile 
private

slightly longer but reads well.

> On Mar 30, 2016, at 9:11 PM, Paul Ossenbruggen  wrote:
> 
> Ok speaking up, not a fan of fileprivate and moduleprivate because 
> 
> 1) very long
> 2) doesn’t flow. 
> 3) not really private. 
> 
> I would be fine with filewide and modulewide and infile and inmodule with a 
> slight preference for the infile and inmodule because it is shorter and 
> conveys the same meaning and flows about the same. 
> 
>> I still prefer the latter ones, but I wonder if -wide ones will be a happier 
>> compromise? Those unhappy with xxxprivate, please speak up!
>> 
>> A.
>> 
> 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

Ok speaking up, not a fan of fileprivate and moduleprivate because 

1) very long
2) doesn’t flow. 
3) not really private. 

I would be fine with filewide and modulewide and infile and inmodule with a 
slight preference for the infile and inmodule because it is shorter and conveys 
the same meaning and flows about the same. 

> I still prefer the latter ones, but I wonder if -wide ones will be a happier 
> compromise? Those unhappy with xxxprivate, please speak up!
> 
> A.
> 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

public
filewide 
modulewide 
private

Don’t bother me because they seem to be part of the word. The way “nationwide” 
does, they are made up words but intent is clear.

OK violating my own statement of only having single words, but very short 
words. How about?

public 
inmodule
infile
private
 
I think this is good too.

> * public
> * moduleinternal
> * internal
> * private

people who insist on always specifying access will either live with it or make 
one exception. 

> On Mar 30, 2016, at 6:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I know that it’s been suggested a while back, but what is/was the reasoning 
>> for rejecting:
>> 
>>  • public
>>  • module (same as internal in Swift 2.2)
>>  • file (same as private in Swift 2.2)
>>  • private
> 
> I know; I was one of the people who suggested it. I believe I saw two reasons 
> for rejecting it:
> 
> 1. This might be read as declaring a module/file, or attaching it to a 
> module/file (a la `class func`), rather than scoping it.
> 2. `private` and `public` are adjectives; `module` and `file` are nouns.
> 
> I'm not entirely convinced by #1; #2 could be addressed by using, for 
> instance, `modulewide` and `filewide`. In any case, though, the discussion 
> seems to have moved elsewhere.
> 
> -- 
> 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] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

Associatedtype won’t be used nearly as often as these operators, I support the 
rational there but not in this case as it will be seen far more often. 

- Paul
> On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy  wrote:
> 
> I understand. The same is true about associatedtype. My iPhone just suggested 
> it as a one word completion! I think the same will happen with these names. 
> Chris Lattner already described the rationale in this thread, so I won't 
> repeat it. I also originally wanted short names, but I think that we ended  
> up with a good compromise (crystal clear, searchable keywords  that are 
> consistent with other keywords). 
> 
> On Wed, Mar 30, 2016 at 10:54 AM Paul Ossenbruggen  > wrote:
> I understand the desire to wrap this up as it has gone on for a long time.
> 
> I just don’t like the length and readability of the moduleprivate and 
> fileprivate names (and how auto correct is always “fixing” it for me when I 
> try to write about it). As I mentioned these will likely be used very often 
> in code and just don’t look very nice. These are potentially used on almost 
> every method, class, property and struct. I don’t think that we should use 
> something that is perhaps a little clearer in meaning but hard to read for 
> something that is used so frequently through the code. There are plenty of 
> places where you have to look something up the first time you encounter it in 
> any programming language and this explicitness is not a big enough win to 
> sacrifice readability. A single word keyword is a requirement for me. 
> 
> 
>  
>> On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution 
>> > wrote:
>> 
>> I am not sure if we will ever get another access level. If we do, great, but 
>> given how long this discussion has been already, I am not counting on it :-)
>> 
>> Most likely, if we get more, it will be possible to describe it with a 
>> simple word, or a combination of words or with some common abbreviations, so 
>> I am not worried about extensibility. I think that the names in the proposal 
>> are very consistent with Swift as it is today and will serve us well. They 
>> are also completely unambiguous and don't depend on the reading context, so 
>> if we come up with other ways to label access levels, it should still be 
>> possible to either use these names for backward compatibility or migrate 
>> them automatically to new names without any difference in semantics.
>> 
>> We also needed to pick something. I waited for about a week to get 
>> everybody's vote, and I think that I picked a compromise that we can all be 
>> at least ok with. (I also originally wanted short single word names). I 
>> think we should close the naming thread at this point.
>> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge > > wrote:
>> 
>> 
>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>> >> If Scala style access modifiers were adopted for Swift then a 
>> >> private(file) modifier would also be necessary to give the current 
>> >> private functionality.
>> >
>> > I could imagine having these options:
>> >
>> >public// visible to all everyone
>> >private(scope-name, scope-name, …)// visible to specified scopes 
>> > (plus current scope)
>> >private// visible only to current scope
>> >
>> 
>> Allowing multiple "scope-name"s is a lot of flexibility and power, but not 
>> sure it's useful/worthwhile.
>> 
>>  For the current discussion, I would think "scope-name" should be limited to 
>> an enclosing scope only.  So you can say "private(Outer)" from an Inner 
>> class or "private(#file)" from within a class, but not "private(ClassA)" 
>> from within ClassB.
>> 
>> (This would also solve the ambiguity of how to reference the main ClassA or 
>> a specific extension to ClassA... "private(ClassA)" can only refer to 
>> whichever scope of ClassA you are currently in.)
>> 
>> > scope-name could perhaps be:
>> >
>> > * A type name (or Self, which would mimic C++-style private, or perhaps 
>> > even C++-style protected depending on how we treat inheritance)
>> 
>> But, this is getting into type-based access which is beyond the scope of 
>> SE-0025 right?
>> 
>> > * A module name (or #module for the current module)
>> > * A file name string (or #file for the current file)
>> >
>> > And then the default would simply be `private(#module)`.
>> >
>> > Alternatively, the parameterized level could be given a different name, 
>> > like `internal` or `shared`. If that were the case, then `#module` might 
>> > simply be the default.
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > ___
>> > 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

The scala idea is interesting, has anyone used it extensively to understand how 
well it works in practice? Is it too fiddly? Do you spend too much time 
thinking about access levels. 

> On Mar 29, 2016, at 5:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> If Scala style access modifiers were adopted for Swift then a private(file) 
>> modifier would also be necessary to give the current private functionality.
> 
> I could imagine having these options:
> 
>   public  // visible to 
> all everyone
>   private(scope-name, scope-name, …)  // visible to specified scopes 
> (plus current scope)
>   private // visible only 
> to current scope
> 
> scope-name could perhaps be:
> 
> * A type name (or Self, which would mimic C++-style private, or perhaps even 
> C++-style protected depending on how we treat inheritance)
> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
> 
> And then the default would simply be `private(#module)`.
> 
> Alternatively, the parameterized level could be given a different name, like 
> `internal` or `shared`. If that were the case, then `#module` might simply be 
> the default.
> 
> -- 
> 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] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

I understand the desire to wrap this up as it has gone on for a long time.

I just don’t like the length and readability of the moduleprivate and 
fileprivate names (and how auto correct is always “fixing” it for me when I try 
to write about it). As I mentioned these will likely be used very often in code 
and just don’t look very nice. These are potentially used on almost every 
method, class, property and struct. I don’t think that we should use something 
that is perhaps a little clearer in meaning but hard to read for something that 
is used so frequently through the code. There are plenty of places where you 
have to look something up the first time you encounter it in any programming 
language and this explicitness is not a big enough win to sacrifice 
readability. A single word keyword is a requirement for me. 


 
> On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> I am not sure if we will ever get another access level. If we do, great, but 
> given how long this discussion has been already, I am not counting on it :-)
> 
> Most likely, if we get more, it will be possible to describe it with a simple 
> word, or a combination of words or with some common abbreviations, so I am 
> not worried about extensibility. I think that the names in the proposal are 
> very consistent with Swift as it is today and will serve us well. They are 
> also completely unambiguous and don't depend on the reading context, so if we 
> come up with other ways to label access levels, it should still be possible 
> to either use these names for backward compatibility or migrate them 
> automatically to new names without any difference in semantics.
> 
> We also needed to pick something. I waited for about a week to get 
> everybody's vote, and I think that I picked a compromise that we can all be 
> at least ok with. (I also originally wanted short single word names). I think 
> we should close the naming thread at this point.
> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge  > wrote:
> 
> 
> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
> >> If Scala style access modifiers were adopted for Swift then a 
> >> private(file) modifier would also be necessary to give the current private 
> >> functionality.
> >
> > I could imagine having these options:
> >
> >public// visible to all everyone
> >private(scope-name, scope-name, …)// visible to specified scopes 
> > (plus current scope)
> >private// visible only to current scope
> >
> 
> Allowing multiple "scope-name"s is a lot of flexibility and power, but not 
> sure it's useful/worthwhile.
> 
>  For the current discussion, I would think "scope-name" should be limited to 
> an enclosing scope only.  So you can say "private(Outer)" from an Inner class 
> or "private(#file)" from within a class, but not "private(ClassA)" from 
> within ClassB.
> 
> (This would also solve the ambiguity of how to reference the main ClassA or a 
> specific extension to ClassA... "private(ClassA)" can only refer to whichever 
> scope of ClassA you are currently in.)
> 
> > scope-name could perhaps be:
> >
> > * A type name (or Self, which would mimic C++-style private, or perhaps 
> > even C++-style protected depending on how we treat inheritance)
> 
> But, this is getting into type-based access which is beyond the scope of 
> SE-0025 right?
> 
> > * A module name (or #module for the current module)
> > * A file name string (or #file for the current file)
> >
> > And then the default would simply be `private(#module)`.
> >
> > Alternatively, the parameterized level could be given a different name, 
> > like `internal` or `shared`. If that were the case, then `#module` might 
> > simply be the default.
> >
> > --
> > 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

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

If someone sees public and external in different places while learning the 
language they would be curious to see what the difference is. The first time I 
saw internal in swift, I looked it up. It was not immediately apparent from the 
name what it meant from then on, there was no confusion. This similarly would 
apply to external. 

Since the C extern is a different word, I would not assume it is the same, but 
may be not that confusing, as it is used in a similar manner to C. You are 
exposing the item beyond this file. 

Since external is the default, it would not be seen as often. 

These specifiers should be single words because they are typed quite often. I 
think public is the single most word I typed on a library I created. Since they 
will be seen a lot they should be pleasing to the eye. 

I would be ok with "shared" for external  but I like the symmetry of 
internal-external and public-private. Does it then become shared-excluded? 
Shared-unshared? Still like external-internal better. 

- Paul 

Sent from my iPhone

> On Mar 29, 2016, at 9:31 AM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> I agree with Ilya that "external" is too easy to confuse with "public", 
> especially given the specifier "extern" in C. Additionally, we think we can 
> get away with renaming "private" because most current uses of "private" 
> (file-scoped) declarations are within the same (brace-bound) scope anyway; 
> "internal" could potentially cause a lot more churn. And as Andrey pointed 
> out, we'd be at odds with C#, the only other language that uses "internal" as 
> an access specifier today.
> 
> Jordan
> 
> 
>> On Mar 29, 2016, at 7:03 , Ilya Belenkiy via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> -1, "external" can be also understood as "exported" or public. I think that 
>> the names in the updated proposal are the clearest. Also, I think that at 
>> this point we need to stop trying to come up with more names. I don't think 
>> that we will ever reach a point where everybody is happy with the names. The 
>> ones that we have now seems to be a good compromise that is in line with 
>> other Swift keywords.
>> On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>>> 
>>>>> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> public (unchanged)
>>>>> external (module access)
>>>>> internal (file access)
>>>>> private (scoped access)
>>>> 
>>>> 
>>>> This seems logical and something I could live with, but how is it better 
>>>> than moduleprivate and fileprivate? Also, internal has contradictory prior 
>>>> art in C# and Swift 2 (not that it stops us).
>>>> 
>>>> And I see the length of moduleprivate and fileprivate as a feature, and 
>>>> external/internal lacks it.
>>> 
>>> 
>>> It is better than moduleprivate and fileprivate in that it is a single word 
>>> which is easier to to read and there is less typing. Less typing even with 
>>> autocomplete is a benefit. Once you know its meaning, that both are 
>>> relative to file access, you won’t have to look it up. Also, just noticed 
>>> this, when I type multiword keywords in an email program or chat program 
>>> autocorrect butts in. This is of practical value because much work is done 
>>> in chat and email programs. 
>>> 
>>> Simpler is better if it sufficiently conveys the meaning and it does in 
>>> this case. The expectation with most keywords are that they be single 
>>> words, especially ones that are used the most. 
>>> 
>>> There is a nice symmetry to internal/external and public/private.
>>> 
>>> If external/internal refer to the file, then we don’t need the multiword 
>>> descriptive versions.  Also, if we decide later that scoping to namespaces 
>>> is desired these same already reserved keywords give us more flexibility 
>>> than the more specific keywords would allow. Internal/external could refer 
>>> to the namespace scope rather than the file scope if it is inside a 
>>> namespace (this is beyond the scope of the proposal but trying to think 
>>> ahead). By not explicitly stating the scope you gain flexibility 
>>> 
>>> - Paul
>>> 
>>> ___
>>> 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] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

I like this, it has been suggested already, single words for easy reading (just 
looks nicer). follows precedent in other languages for existing words, new 
words for new concepts. Internal gets demoted from current swift but since that 
was a swift concept we have more control. 

public - outside module
external - external to file - default - need to look up first time they see it, 
but once learned, won’t forget.
internal - file internal - people need to look it up first time they see it, 
but once learned, won’t forget. 
private - private to class. 


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

Re: [swift-evolution] Promote "primitive" types to enums in extensions

[Paul Ossenbruggen via swift-evolution]

Why can’t you do this? No raw values required, except to initialize the enums.

struct Card {
enum Suit : Int { case Hearts, Spades, Diamonds, Clubs }
enum Rank : Int { case Ace, Two, Three, Four, Five, Six, Seven, Eight, 
Nine, Jack, Queen, King }

let suit : Suit
let rank : Rank

init?(suit: Int, rank: Int) {
guard let suit = Suit(rawValue: suit),
  let rank = Rank(rawValue: rank) else {
return nil
}
self.suit = suit
self.rank = rank
}
}

let firstCard = Card(suit: 0, rank: 3)
let secondCard = Card(suit: 3, rank: 2)
firstCard?.rank // returns Four
secondCard?.suit // returns Clubs



> On Mar 24, 2016, at 11:18 AM, Carlos Rodríguez Domínguez via swift-evolution 
>  wrote:
> 
> Well, I propose the “#” syntax to be consistent with other proposals that 
> intend to provide compilation-related code. In this case, the proposal is 
> just a way to provide an indication that a certain field within a struct or 
> class should be enforced to be a value of a certain enum, not just a plain 
> integer, by the compiler. Anyhow, I think many different sintaxis could be 
> elaborated. For example, another possible syntax could imply reusing the 
> typealias expression:
> 
> extension Card{
>   typealias suit:CardSuit = suit:Int
> }
> 
> However, I assume that using this syntax it should be possible to directly 
> assign to the suit field both an integer or a CardSuit.
>> b

>> On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez 
>> > wrote:
>> It is a common practice in C to assign to integer (int, int16, int64, etc.) 
>> typed variables “constant" values declared in enums. In swift, it is in fact 
>> possible to do that by using enums' “rawValue” property. When importing 
>> structs from C into swift, we even get some fields declared with an integer 
>> type, but expecting the assignment of a “constant” declared inside an enum. 
>> Of course, this is error prone, it is “old-style” programming and very 
>> confusing for newcomers. To solve this issue, my proposal is to be able to 
>> create extensions that promote certain fields within a class or struct to 
>> enums.
>> 
>> For instance, let’s take these sample C struct and enum:
>> 
>> struct Card {
>> int suit;
>> int rank;
>> };
>> 
>> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>> 
>> (Note: I understand that above code follows a bad programming practice, yet 
>> it is widely common)
>> 
>> It should be imported into swift as follows:
>> 
>> struct Card {
>> suit:Int
>> value:Int
>> }
>> 
>> enum CardSuit : Int {
>> case Hearts, Diamonds, Clubs, Spades
>> }
>> 
>> Now, I propose to be able to create an extension as follows:
>> 
>> extension Card {
>> #enumvalue(suit:CardSuit)
>> }
>> 
>> From this moment on, the suit field should only receive CardSuit values, 
>> thus not requiring the use of raw values for assignments.
>> 
>> These extensions should also be of great interest for people using CoreData, 
>> since it is not possible to declare enums in models. Therefore, to declare 
>> enums, it is necessary to declare integer values, and then use the “unsafe”, 
>> “unexpressive" approach explained before.
>> 
>> Note that the proposal intends to only support promotions from integer 
>> values to enum values, but, for example, it could also be extended to string 
>> values.
>> 
>> Finally, it could be appropriate to extend this proposal to redeclare func’s 
>> signatures, in order to promote certain parameters to enum values.
>> 
>> Best,
>> 
>> Carlos.
>> ___
>> 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] [Idea] Find alternatives to `switch self`

[Paul Ossenbruggen via swift-evolution]

Thanx Maximillian for writing this, saved me from doing it and well put! :-)

- Paul
> On Mar 23, 2016, at 5:46 AM, Maximilian Hünenberger via swift-evolution 
>  wrote:
> 
> Hi Brent,
> 
> First of all, I like your suggestions however there was already a proposal 
> about "Pattern matching partial functions" which could address this and many 
> other issues (See pull request #111; unfortunately the discussion doesn't 
> went on... Hopefully this time).
> 
> This proposal addresses the issue of switch statements which return something 
> in every "case". It uses special closures as unapplied switch statements and 
> uses a global "match" function:
> 
> func match(value: T, closure: T -> U) -> U {
>  return closure(value)
> }
> 
> The case you describe could now be rewritten to:
> 
> // no returns
> enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>return match(self) {
>case .Hearts: "♥️"
>case .Spades: "♠️"
>case .Diamonds: "♦️"
>case .Clubs: "♣️"
>}
>}
> 
>var isRed: Bool {
>return match(self) {
>case .Hearts, .Diamonds: true
>case .Spades, .Clubs: false
>}
>}
>}
> 
> // or even without case (which was highly controversial in the discussions)
> enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>return match(self) {
>cases .Hearts: "♥️", .Spades: "♠️", .Diamonds: "♦️", .Clubs: 
> "♣️"
>}
>}
> 
>var isRed: Bool {
>return match(self) {
>cases .Hearts, .Diamonds: true, .Spades, .Clubs: false
>}
>}
>}
> 
> What do you think about this?
> 
> Kind regards
> - Maximilian
> 
> Am 23.03.2016 um 11:13 schrieb Brent Royal-Gordon via swift-evolution 
> >:
> 
>> If you've written enums before, you've no doubt noticed the irritating 
>> phenomenon of `switch self` being absolutely everywhere. I first discovered 
>> this in some of my very first Swift code, code so old we were still using 
>> the `T[]` shorthand syntax:
>> 
>>enum Suit: Int {
>>case Hearts, Spades, Diamonds, Clubs
>> 
>>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
>> 
>>var description: String {
>>switch(self) {
>>case .Hearts:
>>return "♥️"
>>case .Spades:
>>return "♠️"
>>case .Diamonds:
>>return "♦️"
>>case .Clubs:
>>return "♣️"
>>}
>>}
>> 
>>var isRed: Bool {
>>switch(self) {
>>case .Hearts, .Diamonds:
>>return true
>>case .Spades, .Clubs:
>>return false
>>}
>>}
>>}
>> 
>> It would be nice if we could somehow eliminate that. I have two suggestions:
>> 
>> * Implicitly switch on `self` at the top level of a function or accessor (or 
>> at least an enum one with top-level `case` statements).
>> 
>>enum Suit: Int {
>>case Hearts, Spades, Diamonds, Clubs
>> 
>>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>> 
>>var description: String {
>>case .Hearts:
>>return "♥️"
>>case .Spades:
>>return "♠️"
>>case .Diamonds:
>>return "♦️"
>>case .Clubs:
>>return "♣️"
>>}
>> 
>>var isRed: Bool {
>>case .Hearts, .Diamonds:
>>return true
>>case .Spades, .Clubs:
>>return false
>>}
>>}
>> 
>> * Allow you to attach member definitions to particular cases. It would be an 
>> error if they didn't all define the same members, unless there was a 
>> top-level catchall.
>> 
>>enum Suit: Int {
>>var isRed: Bool { return false }
>> 
>>case Hearts {
>>let description: String { return "♥️" }
>>let isRed: Bool { return true }
>>}
>>case Spades {
>>let description: String { return  "♠️" }
>>}
>>case Diamonds {
>>let description: String { return  "♦️" }
>>let isRed: Bool { return true }
>>}
>>case Clubs {
>>let description: String { return  "♣️" }
>>}
>> 
>>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>>}
>> Any thoughts? This has, to be honest, bothered me since approximately the 
>> third day I used the language; I'd love to address it sooner or later.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> 

Re: [swift-evolution] Proposal to remove semicolons

[Paul Ossenbruggen via swift-evolution]

This seems like unexpected behavior and if the user intended it to return a 
value, it should be moved to the return line. The compiler is smart enough to 
warn about it and the warning goes away when you move the line up. If there is 
an issue where they need something that spans multiple lines putting it 
parenthesis would allow that.

@IBAction func makeRed() {
return
self.view.backgroundColor = UIColor.redColor()
}



> On Mar 17, 2016, at 9:12 AM, Chris Wood  wrote:
> 
> Sorry, that was a terrible example which doesn’t work (typing code into an 
> email at this point in the afternoon isn’t a good idea it seems!)
> 
> I made a simple example project to show the issue. Two methods in the view 
> controller, different behaviour depending on the trailing semicolon:
> 
> http://interealtime.com/misc/Semicolon.zip 
> 
> 
> This scenario would be ‘wrong’ in general code, but is pretty common during 
> debugging - and that trailing semicolon is actually necessary in this case (I 
> hit this for real yesterday).
> 
> Chris
> 
>> On Mar 17, 2016, at 3:44 PM, Chris Wood  wrote:
>> 
>> Paul
>> 
>> The semicolon is actually needed still to avoid accidental multi-line 
>> statements. E.g. these functions behave differently:
>> 
>> func doNothing1() {
>> break
>> print(“This text gets printed”)
>> }
>> func doNothing2() {
>> break;
>> print(“This text isn’t printed”)
>> }
>> 
>> Until odd cases like this can be avoided, I think semicolons are still 
>> (though very rarely) necessary.
>> 
>> Chris
>> 
>> 
>>> On Mar 17, 2016, at 3:25 PM, Paul Ossenbruggen  wrote:
>>> 
>>> +1 I think that let people do whatever they want if i makes them happy when 
>>> it makes the code less readable is not a good idea. I support the notion 
>>> that semicolon should not be allowed at end of line. It does nothing to 
>>> help readability of the code. If it does nothing, it should go. Swift code 
>>> should be easy to read, and in this case clarity wins. We have to break the 
>>> semicolon habit :-) 
>>> 
>>> Perhaps providing a warning fix-it which removes them from the end of all 
>>> lines in the file. I suspect most cases the only reason people put it there 
>>> is habit or they are converting old code from another language.
>>> 
>>> - Paul

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

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Paul Ossenbruggen via swift-evolution]

I guess I am not in the forloopian camp. I spend far too much time, converting 
for i = 0; i < 4; i++) into something more modern like iterating over 
containers. If it is in the language, people will use it, not having it there 
makes people think about better ways of doing things rather than relying on 
muscle memory. I know it is a barrier for some but other languages such as 
Python don’t support this construct and no one will deny that Python is heavily 
used in numerics. 

- Paul

> On Mar 19, 2016, at 1:28 AM, ted van gaalen via swift-evolution 
>  wrote:
> 
> Yes, thank you Dmitri, I think so too.
> Will come back to this later.
> TedvG
> 
> 
> 
> ted van gaalen
> 
> On 19 Mar 2016, at 08:46, Dmitri Gribenko  > wrote:
> 
>> Hi Ted,
>> 
>> Thank you for starting this thread.  I agree that removing the C-style
>> for loop has degraded the readability and clarity of some of numerics
>> code.
>> 
>> In the feedback to SE-0007 many people have said that they can convert
>> their code to for-in loops, but I think this actually means that in
>> code that is typically written in Swift today, loops primarily operate
>> on sequences and collections.  It means that numerics is a domain that
>> not many people work in.  But it is a very important domain
>> nevertheless, and clarity for numerics code matters at least as much
>> as it does everywhere else.
>> 
>> I think one way to approach this discussion would be to present
>> multiple concrete code samples that contain C-style for loops and are
>> awkward to write without them.  We can then try looking for patterns,
>> generalize and simplify, and discuss possible solutions.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko > >*/
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Paul Ossenbruggen via swift-evolution]

• What is your evaluation of the proposal?
+1 on proposal overall. I agree that @discardable is sufficient to describe 
what it does. If there is questions it is easy to search it on the web. Also 
the context of where the @discardable modifier is on the line will reduce 
ambiguity. Conciseness is important and I don’t think it significantly detracts 
from the clarity to leave off the “Return” part. 

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

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

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

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

Been following and contributing to discussion and read the proposal. 


> On Mar 16, 2016, at 5:57 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Mar 16, 2016, at 5:27 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> • What is your evaluation of the proposal?
>> 
>> I am in favor of the semantic, but I don't like `@discardableResult`; it's 
>> long and unwieldy. I would prefer that we either use a shorter word than 
>> "discardable", attach the keyword to the return type as discussed in "Future 
>> Directions", or both.
>> 
> 
> 1. The keyword will be used rarely. I don't mind if it's slightly hard to 
> type.
> 2. When used, it should be as clear as possible, both in understanding what 
> it does and visually standing out.
> 3. The most popular keyword requested was actually @allowUnusedResult 
> followed by @suppressUnusedResultWarning. 
>   Both of these are longer. I felt @discardableResult was more descriptive 
> than @allowUnusedResult. I wanted to avoid
>   the word "suppress" as it is appears on many frequently misspelled words 
> lists. 
> 
>   I believe discardable (the number one choice  by *far* for a type 
> annotation, with ignorable as its second)  perfectly describes
>   how the return value/result should be treated.  When included, the behavior 
> mimics:
> 
>let _ = resultReturningFunctionOfSomeType()
> 
>   which basically discards the result (an active decision) rather than 
> ignores it (a passive one).
> 
>> I also don't like that this proposal doesn't include an "Impact on existing 
>> code" section. We ought to decide whether the migrator will add 
>> `@discardableResult` to existing symbols or not.
> 
> This is a good point and Adrian and I will be happy to add this in. I do not 
> believe it should, although I'll let Adrian answer
> on his own.  The entire point of this exercise is to reduce likely error 
> points. Simply changing the behavior without fixits
> should help accomplish that in existing code. If you add @discardableResult, 
> we mask the advantage this behavior
> should address.
> 
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes. I should use `@warn_unused_result`, but never bother because it's just 
>> too much of a hassle. My code will be safer with this change.
> 
> And that's why I don't think the migrator should make any code changes.
> 
> -- E
> 
> ___
> 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 to remove semicolons

[Paul Ossenbruggen via swift-evolution]

+1 I think that let people do whatever they want if i makes them happy when it 
makes the code less readable is not a good idea. I support the notion that 
semicolon should not be allowed at end of line. It does nothing to help 
readability of the code. If it does nothing, it should go. Swift code should be 
easy to read, and in this case clarity wins. We have to break the semicolon 
habit :-) 

Perhaps providing a warning fix-it which removes them from the end of all lines 
in the file. I suspect most cases the only reason people put it there is habit 
or they are converting old code from another language.

- Paul

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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

To point 1: I agree it needs a new name, I came up with the “demux expression” 
but maybe there is a better name. 

To point 2: Taking a more complex example which uses _ adapted from the swift 
book. The original 

switch somePoint {
case (0, 0):
print("(0, 0) is at the origin")
case (_, 0):
print("(\(somePoint.0), 0) is on the x-axis")
case (0, _):
print("(0, \(somePoint.1)) is on the y-axis")
case (-2...2, -2...2):
print("(\(somePoint.0), \(somePoint.1)) is inside the box")
default:
print("(\(somePoint.0), \(somePoint.1)) is outside of the box")
}

with the proposed format so the underscore does kind of act like a default in 
the existing switch statement: 

let string = somePoint ?
(0, 0): "(0, 0) is at the origin"
(_, 0): "(\(somePoint.0), 0) is on the x-axis"
(0, _): "(0, \(somePoint.1)) is on the y-axis"
(-2...2, -2...2):   "(\(somePoint.0), \(somePoint.1)) is inside the box"
(_, _): "(\(somePoint.0), \(somePoint.1)) is outside of the box"

So, it kind of used like a default. Note, I am suggesting that this also work, 
if it seems too loose, this would help add structure in more complex cases. 

let string = somePoint ?
case (0, 0):"(0, 0) is at the origin"
case (_, 0):"(\(somePoint.0), 0) is on the x-axis"
case (0, _):"(0, \(somePoint.1)) is on the y-axis"
case (-2...2, -2...2):  "(\(somePoint.0), \(somePoint.1)) is inside the 
box"
default:"(\(somePoint.0), \(somePoint.1)) is outside of 
the box"

So you could still do as you suggest: 

let string = somePoint ?
(0, 0): "(0, 0) is at the origin"
(_, 0): "(\(somePoint.0), 0) is on the x-axis"
(0, _): "(0, \(somePoint.1)) is on the y-axis"
(-2...2, -2...2):   "(\(somePoint.0), \(somePoint.1)) is inside the box"
default:"(\(somePoint.0), \(somePoint.1)) is outside of the box"

Mathew says that he thinks that parenthesis should not be required, but I think 
it seems a little loose without them. It is similar to how control structures 
have { } around things and I am worried about creating ambiguity. 

let string = somePoint ?(
(0, 0): "(0, 0) is at the origin"
(_, 0): "(\(somePoint.0), 0) is on the x-axis"
(0, _): "(0, \(somePoint.1)) is on the y-axis"
(-2...2, -2...2):   "(\(somePoint.0), \(somePoint.1)) is inside the box"
(_, _): "(\(somePoint.0), \(somePoint.1)) is outside of the box"
}

I don’t think the “case” and “default" is as necessary with the parenthesis 
around it. 

Arg! I still want to put the control value inside though! It just kind of 
floats out there otherwise. 

let string = ?(somePoint,
(0, 0): "(0, 0) is at the origin"
(_, 0): "(\(somePoint.0), 0) is on the x-axis"
(0, _): "(0, \(somePoint.1)) is on the y-axis"
(-2...2, -2...2):   "(\(somePoint.0), \(somePoint.1)) is inside the box"
(_, _): "(\(somePoint.0), \(somePoint.1)) is outside of the box"
}

To point 3: That the ternary presents confusion by using the colon. I think 
that confusion drops away with the _ as the default. The rule would be that 
switch expressions would always be exhaustively specified or must use default. 
For the boolean and index forms the colon does not create confusion, they are 
used to return the case that does not match one of the choices. 

let fb = pickOne ? “A", "B", "C", "D", "E", "F", "G” : "Z"
let fe = truthy == truth ? “unlikely” : “likely”

or:

let fb = pickOne ? “A", "B", "C", "D", "E", "F", "G” default:"Z"
let fe = truthy == truth ? “unlikely” default: “likely”

or maybe:

let fb = pickOne ? “A", "B", "C", "D", "E", "F", "G” else:"Z"
let fe = truthy == truth ? “unlikely” else: “likely”

Not necessarily recommending that last one but trying it out. Since boolean 
“ifs" use “else" rather than default. 

> 
> On Jan 6, 2016, at 9:03 AM, Jo Albright  wrote:
> 
> Just a couple of thoughts swirling in my brain. 
> 
> 1. Ternary means : composed of three parts …. if we add case functionality, 
> it no longer is a ternary and should be renamed (ex : nil coalescing … was 
> used instead of calling it a ternary optional). Would love to hear thoughts 
> on what names it could have … if the proposal moves forward.
> 
> ---
> 
> I am leaning towards this pattern (someone else introduced), yet I don’t feel 
> it is perfect.
> 
> let val = color ?  .Red: 0xFF, .Green: 0x00FF00,  .Blue: 0xFF,   _: 
> 0xFF
> 
> 2. I have a problem with “_”. I don’t agree with it being the default value. 
> It is currently used to discard or ignore values … using it as a default will 
> add unnecessary confusion that does not align with Swift. Writing out the 
> word default instead of _ is only 6 more characters. Please correct me if I 
> am wrong on this note.
> 
> let 

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Made a mistake on first example underscore should not have been quoted:

let resultString = someCharacter ?( 
   "a", "e", "i", "o", “u”: "\(someCharacter) is a vowel"
  "b", "c", "d", "f", "g", "h", "j", "k", "l", “m”, "n", "p", "q", "r", "s", 
"t", "v", "w", "x", "y", "z”:
 "\(someCharacter) is a consonant"
  _: "\(someCharacter) is not a vowel or a consonant"
)
print(resultString)

> On Jan 6, 2016, at 2:22 PM, Paul Ossenbruggen  wrote:
> 
> Just to try out some other examples from the Swift book as you can see it 
> gets rid of a lot of boiler plate and duplicated code for almost all of the 
> examples. I think it is just as readable if not more readable and very Swift 
> like. It also leaves more room on the line so you can avoid multiline cases 
> more often. In the book the examples often use “var” when “let” would be 
> preferred. 
> 
> This:
> 
> switch someCharacter {
> case "a", "e", "i", "o", "u":
> print("\(someCharacter) is a vowel")
> case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m",
> "n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z":
> print("\(someCharacter) is a consonant")
> default:
> print("\(someCharacter) is not a vowel or a consonant")
> }
> 
> Becomes:
> 
> let resultString = someCharacter ?( 
>"a", "e", "i", "o", “u”: "\(someCharacter) is a vowel"
>   "b", "c", "d", "f", "g", "h", "j", "k", "l", “m”, "n", "p", "q", "r", "s", 
> "t", "v", "w", "x", "y", "z”:
>"\(someCharacter) is a consonant"
>   “_”: "\(someCharacter) is not a vowel or a consonant"
> )
> print(resultString)
> 
> This:
> 
> let approximateCount = 62
> let countedThings = "moons orbiting Saturn"
> var naturalCount: String
> switch approximateCount {
> case 0:
> naturalCount = "no"
> case 1..<5:
> naturalCount = "a few"
> case 5..<12:
> naturalCount = "several"
> case 12..<100:
> naturalCount = "dozens of"
> case 100..<1000:
> naturalCount = "hundreds of"
> default:
> naturalCount = "many"
> }
> 
> Becomes:
> 
> let approximateCount = 62
> let countedThings = "moons orbiting Saturn"
> let naturalCount = approximateCount ?(
>   0:  "no"
>   1..<5:  "a few"
>   5..<12: "several"
>   12..<100:   "dozens of"
>   100..<1000: "hundreds of"
>   _:  "many"
> )
> print("There are \(naturalCount) \(countedThings).")
> 
> This:
> 
> let anotherPoint = (2, 0)
> switch anotherPoint {
> case (let x, 0):
> print("on the x-axis with an x value of \(x)")
> case (0, let y):
> print("on the y-axis with a y value of \(y)")
> case let (x, y):
> print("somewhere else at (\(x), \(y))")
> }
> 
> Becomes:
> 
> let anotherPoint = (2, 0)
> let resultString = anotherPoint ?(
> (let x, 0):   "on the x-axis with an x value of \(x)"
> (0, let y):   "on the y-axis with a y value of \(y)"
> let (x, y):   "somewhere else at (\(x), \(y))"
> )
> print(resultString)
> 
> This:
> 
> let yetAnotherPoint = (1, -1)
> switch yetAnotherPoint {
> case let (x, y) where x == y:
> print("(\(x), \(y)) is on the line x == y")
> case let (x, y) where x == -y:
> print("(\(x), \(y)) is on the line x == -y")
> case let (x, y):
> print("(\(x), \(y)) is just some arbitrary point")
> }
> 
> Becomes:
> 
> let yetAnotherPoint = (1, -1)
> let resultString = yetAnotherPoint ?(
> let (x, y) where x == y:  "(\(x), \(y)) is on the line x == y"
> let (x, y) where x == -y: "(\(x), \(y)) is on the line x == -y"
> let (x, y): "(\(x), \(y)) is just some arbitrary 
> point"
> )
> print(resultString)
> 
> This:
> 
> let numberSymbol: Character = "三"  // Simplified Chinese for the number 3
> var possibleIntegerValue: Int?
> switch numberSymbol {
> case "1", "١", "一", "๑":
> possibleIntegerValue = 1
> case "2", "٢", "二", "๒":
> possibleIntegerValue = 2
> case "3", "٣", "三", "๓":
> possibleIntegerValue = 3
> case "4", "٤", "四", "๔":
> possibleIntegerValue = 4
> default:
> break
> }
> if let integerValue = possibleIntegerValue {
> print("The integer value of \(numberSymbol) is \(integerValue).")
> } else {
> print("An integer value could not be found for \(numberSymbol).")
> }
> // prints "The integer value of 三 is 3.”
> 
> Becomes:
> 
> let numberSymbol: Character = "三"  // Simplified Chinese for the number 3
> let possibleIntegerValue:Int? = numberSymbol ?(
> "1", "١", "一", "๑": 1
> "2", "٢", "二", "๒": 2
> "3", "٣", "三", "๓": 3
> "4", "٤", "四", "๔": 4
> _ : nil
> )
> if let integerValue = possibleIntegerValue {
> print("The integer value of \(numberSymbol) is \(integerValue).")
> } else {
> print("An integer value could not be found for \(numberSymbol).")
> }
> // prints "The integer value of 三 is 3.”
> 
> This last one does not automatically make it an optional, you need to 
> manually put the optional type in, just as ternary does. 
> 
> The falltrhough examples don’t make sense because you can’t have 

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

agreed that bar might not work

> On Jan 6, 2016, at 9:35 PM, Alex Popov <he...@alexpopov.ca> wrote:
> 
> You're right Charles, the confusion with the OR operator is something I 
> neglected to mention (despite noticing it) because of my own preference. 
> However, I would like some kind of explicit separator between cases. If we're 
> unwilling to reuse the `case` keyword, I hope commas will be enforced. 
> 
> +1 for the proposal overall though. I desperately wish for some kind of 
> expression-switch-statement when putting too much logic into an enum feels 
> heavy, but I need a value based on the case. 
> 
> Alex Popov Jr.
> Principal iOS developer | Shelfie
> www.shelfie.com <http://www.shelfie.com/> | @getshelfie
> 
> _
> From: Charles Constant <char...@charlesism.com 
> <mailto:char...@charlesism.com>>
> Sent: Wednesday, January 6, 2016 21:26
> Subject: Re: [swift-evolution] ternary operator ?: suggestion
> To: Alex Popov <he...@alexpopov.ca <mailto:he...@alexpopov.ca>>
> Cc: Swift Evolution <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>>, Paul Ossenbruggen <pos...@gmail.com 
> <mailto:pos...@gmail.com>>
> 
> 
> Alex, 
> 
> We know, from the traditional ternary, that a colon is going to satisfy the 
> requirements of a separator, even when we want to chain. 
> 
> Is this the case with bar "|"? To me, this doesn't bode well 
> 
> let a = b ? 
> 2 : 3 |
> 4 : 5 | 
> _ : -1   
>  
> Above, are we talking about a result of "3 [Bitwise OR] 4" or is the result 
> "3 [SEPARATOR] 4"? I could be wrong, but I suspect in practise, it would be 
> complicated to use, and probably not possible to chain. 
> 
> 
> 
> 
> On Wed, Jan 6, 2016 at 9:10 PM, Alex Popov <he...@alexpopov.ca 
> <mailto:he...@alexpopov.ca>> wrote: 
> I like the bar `|` variation, but I do think the control value should be out 
> front, otherwise the ? reads as an optional to my mind, whereas the former 
> comes across as the beginning of a ternary (which this is effectively an 
> extension of). 
> The bar variation feels Haskell-y in a satisfying way, and also has the added 
> benefit of clearly delimiting the effective "range" of the multiary.  
> 
> Alex Popov Jr. 
> Principal iOS developer | Shelfie 
> www.shelfie.com <http://www.shelfie.com/> | @getshelfie
> 
> 
> 
> 
> On Wed, Jan 6, 2016 at 8:35 PM -0800, "Paul Ossenbruggen via swift-evolution" 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: 
> 
> Hi Charles,
> 
> Chris, already said he did not like ? being used for ternary because it was 
> already used for optionals. I think because of historical precedent it may be 
> acceptable here.  I have tried combos earlier with ! and got no support, 
> admittedly not with the same usage as yours. 
> 
> Do you really find it confusing not having a separator there? It is 
> essentially a switch case without the word “case”. In my model the colon only 
> indicates the “else” or “default” case, the other cases are separated by 
> commas or whitespace. With my email taking the Swift Book examples and 
> converting it from statement to expression form, I did not find any of them 
> confusing, well maybe the first one, which found vowels and consonants, but 
> that did not look that great in statement form either. . 
> 
> if so maybe the | would be better as the separator because it would not 
> change the switch like syntax:
> 
> let  numberSymbol:  Character  =  " 三 "   // Simplified Chinese for the 
> number 3
> let possibleIntegerValue: Int? =  numberSymbol ?
>|  "1",  " ١ ",  " 一 ",  " ๑ ":  1
>|  "2",  " ٢ ",  " 二 ",  " ๒ ":  2
>|  "3",  " ٣ ",  " 三 ",  " ๓ ":  3
>|  "4",  " ٤ ",  " 四 ",  " ๔ ":  4
>|   _ :  nil
> 
> if   let  integerValue = possibleIntegerValue  {
>  print ("The integer value of  \( numberSymbol) is  \( integerValue)." )
> }  else {
>  print ("An integer value could not be found for  \( numberSymbol)." )
> }
> // prints "The integer value of  三 is 3.”
> 
> But I still don’t see it a necessary.  perhaps that would allow removal of 
> the parenthesis and I think this would get rejected as not looking very Swift 
> like. Also single line form which isn’t bad:
> 
>  let val = color ?  .Red:  0xFF |  .Green:  0x00FF00 |.Blue:  
> 0xFF  |  _:  0xFF
> 
> But

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Paul Ossenbruggen via swift-evolution]

> On Jan 2, 2016, at 10:38 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

This definitely makes the two concepts much more easy to understand. 
Overloading the meanings is confusing. Separating them helps a lot. 

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

Definitely.

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

Yes

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

Not applicable

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
Read the proposal and followed some of the discussion on the swift-evolution 
list. 


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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Heh, one other thought. Pretty sure this was rejected by the switch statement 
but if keeping it concise for expressions is a goal then _ might make sense for 
the default case especially with this form. :-) 

let fh = ?(color, .Red: 0xFF // only one expression can be the result here 
so case is unnecessary. 
  .Green: 0x00FF00
  .Blue: 0xFF
  _: 0xFF) // default is always last, unless all cases are 
handled. 

I agree with it being rejected for the statement form, but kinda makes sense 
here. 

> On Jan 5, 2016, at 10:50 PM, Paul Ossenbruggen  wrote:
> 
> The thing I don’t like is the repeated use of case. and default. This, I 
> think makes the expression longer than it needs to be. For expressions it is 
> not necessary because you only have one expression which returns one value, 
> where as in a statement you have multiple statements following it, so it is 
> necessary to separate the cases with the word “case”. I think trying to 
> reduce clutter is important. 
> 
> For example, statements have to deal with multiple statements per case. 
> 
> let color = Colors.Red
> // hello
> let res : Int
> switch color {
> case .Red:
>   res = 0xFF
>   print(res) // case is necessary here to separate statement lists. 
> case .Green: 
>   res =  0x00FF00
>   print(res)
> case .Blue: 
>   res = 0xFF
>   print(res)
> default:
> res = 0xFF
> }
> 
> This is why I went down the path of trying to group it with parenthesis and 
> optionally remove the word case. I know it may seem a little less like a 
> "switch" but I think having to write out “case" over and over is not great 
> when it does not serve the same purpose as it does in the statement form. So 
> in the compact form: 
> 
> let fh = ?(color, .Red: 0xFF // only one expression can be the result 
> here so case is unnecessary. 
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   : 0xFF) // default is always last, unless all cases are 
> handled. 
> 
> 
> This seems more light and more and just as understandable as Thorsten's 
> suggestion. (Note: I keep playing with the separators because the feedback 
> was, my latest suggestions were not Swift like). Also, it is possible to drop 
> the “case" in this structure and it can be read more like a function if 
> desired. My suggestion also supported this form but its only advantage is 
> that it looks more like a “switch", there may be value in that but I think 
> conciseness and less clutter should win:
> 
> let fh = ?(color, case .Red: 0xFF
>   case .Green: 0x00FF00
>   case .Blue: 0xFF
>   default: 0xFF)
> 
> Not sure though if people don’t like having alternatives forms though.
> 
> I think there is value in having a consistent way of doing index based as 
> well as boolean based expressions as I have suggested in my proposal. I know 
> that is a harder thing to push for but I think it is a win. I have 
> backpedaled on some of my weirder character choices here so it more like the 
> ternary. 
> 
> let fb = ?(pickOne, “A", "B", "C", "D", "E", "F", "G” : "Z")
> let fe = ?(truthy == truth, “unlikely” : “likely")
> 
> If you look at these suggestions above, I have only moved one ? added a 
> comma, and added parenthesis to the ternary. I think these latest suggestions 
> look more like Swift and more like the ternary than my last email.
> 
> If it is really preferred the control value could be moved outside the parens 
> but I think it makes it harder to find the beginning and end of the ternary 
> and it does not have the advantage of the function like feel to it:. 
> 
> let fe = truthy == truth ?(“unlikely” : “likely")
> 
> let fh = color ?( .Red: 0xFF
>   .Green: 0x00FF00
>   .Blue: 0xFF
>   : 0xFF) 
> 
> finally we could drop the parenthesis all together and the ternary is back in 
> original form, which results in Thorsten’s suggestion minus the cases,
> 
> let fe = truthy == truth ? “unlikely” : “likely"
> 
> let fh = color ? .Red: 0xFF
>  .Green: 0x00FF00
>  .Blue: 0xFF
>  : 0xFF 
> 
> I think the parenthesis and the control inside the construct really help and 
> this may be hard to parse without the grouping the parenthesis provides. I 
> don’t think we are that far apart though. 
> 
> - Paul 
> 

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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Any feedback on this? I am rethinking the idea of #( because of the # prior 
usage as a preprocessor directive, but like how it stands out and has a 
meaning.  If no feedback, does it make sense to update my proposal with these 
ideas? Or does this feel like the wrong direction. 


> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen  wrote:
> 
> Some more ideas, this moves away from the notion that we should make it look 
> really close to the ternary but keeps all the benefits of the ternary and 
> improves upon it. Since I have been suggesting a breaking change, it is a 
> good time to rethink it a bit. With this idea a horizontal line (double-dash) 
> separates the control value from the choices, the vertical line (bar) 
> indicates none of the above. 
> 
> Rather than use the ?( as I have suggested in the past, I think #( works 
> here, where you can think of it as a numerical index. The advantage of this 
> is, it stands out better and leaves ? for optionals only. This works well 
> with the list form. In the enum case the index is the enum key. I can see 
> that this however may be a problem because # is used for preprocessor like 
> directives. I am suggesting though just the #( sequence is treated 
> differently. Or the ?( is fine with me as well.
> 
> I have gone through a lot of options, some others I looked at are !( which 
> could be read as "match stick” paren, where the word “match” matches a case, 
> I am pretty sure that would not be considered any better than ?( because it 
> is used for optionals. Another is “witch hat paren” ^( which can be read as 
> “which”.  This might create a parse problem with "power of" though, which 
> maybe using ^[ (hat square bracket) could resolve that but not sure if that 
> would create other problems. Some other choices would be &(  and @( but did 
> not choose them because  they don’t have meaning to me but they do have the 
> advantage of standing out like the #(. 
> 
> let fa = #(truth -- 1 | 0) // boolean case. 
> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list form, 
> pick index, zero based. 
> let fc = #(color -- .Red: 0xFF, .Green: 0x00FF00, .Blue: 0xFF | 
> 0xFF) // enum form.
> let fd = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF 
>   | 0xFF) // enum multiline, default: can be used here if 
> preferred.
> let fe = #(color -- .Red:0xFF, 
>   .Green:  0x00FF00, 
>   .Blue:   0xFF) // if all cases handled, the last bar is 
> optional
> 
> This visually kind of represents what is going on. Horizontal-line directs 
> eye to one of the normal choices. Vertical-line says none found stop looking 
> and do the otherwise choice. Kind of like a train switch. 
> 
> The strong feedback was that a replacement has to be usable in places where a 
> ternary could be used. So it needs to work on a single line (and multiline) 
> and needs to be compact. By having a compact, “else" that is possible on a 
> single line. 
> 
> Comparisons to ternary and other approaches:
> • It is very concise like ternary and can fit in places that a ternary does.
> • The horizontal line serves to provide a place to align the choices to pick 
> from, not as necessary with ternary. 
> • The vertical line stops the eye and indicates this is the “else” or 
> “default” choice, the colon does that in ternary but the bar stands out more.
> • The parens group the expression, in a way that the ternary does not. With a 
> ternary it is not until you get to the question mark and the barely visible 
> colon that you realize it is a ternary. 
> • The #( indicates immediately that the expression has started unlike a 
> ternary. 
> • #( clearly show beginning and end of the construct so that it is 
> immediately identifiable unlike ternary.
> • Makes quick one line conversions easily achievable just as ternary can but 
> allowing more than just boolean.  
> • The “else” choice is always last and is compactly represented with vertical 
> bar like ternary but more visible. This also differs from the switch 
> statement form, in that it is much more compact than “default:"
> • The dash does not create a double colon for enum case as was mentioned as a 
> problem in previous designs.
> • All data types for the control are handled the same way, like ternary but 
> now supports more than boolean, it supports any enumerable tope.
> • The list form looks like a Array sort of, the enum form looks sort of like 
> a Dictionary, this should make it seem familiar.
> • The enum form also supports pattern matching. (see below for examples). 
> Which ternary does not.
> • The vast majority of switch statements, at least that I typically use, 
> could be done with this and be much more compact and concise. However if your 
> needs are more complex, then the switch statement is still available. 
> • You get the benefits of automatic type 

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Just tried going down this path a bit of creating a library. You can get pretty 
far for the boolean or integer types, but don’t see a way to do a switch like 
solution. Also, a big problem with this approach is there is no way to short 
circuit evaluate the expressions in the list of a variadic function. They will 
all be evaluated, at the call site. One other problem, so we don’t conflict 
with the “else” and “default”, keywords, I had to use “def” or “el” for “else". 

// Simple bool
func calcB()->String {
print(“B calculated")
return "B"
}

// Simple bool
func sel(condition : Bool, @autoclosure _ trueExpr:()->T, @autoclosure _ 
falseExpr:()->T) -> T {
return condition ? trueExpr() : falseExpr()
}

sel(true, "A", calcB())
sel(false, "A", calcB())

// alternative, used "def" for default to not conflict with "else" or “default. 
This version, may not be necessary.
func sel(condition : Bool, @autoclosure _ expr:()->T,  @autoclosure 
el:()->T) -> T {
return condition ? expr() : el()
}

sel(true, "A", el:calcB())
sel(false, "A", el:calcB())

// index approach, note the use of autoclosure does not work on array or array 
of functions. So it will evaluate all expressions at the call site. Unless 
there is some trick I don’t know. 
func sel(selector : Int,/* @autoclosure */ _ exprs: T..., def : T) -> T {
if  selector > exprs.count || selector < 0 {
return def
}
return exprs[selector]
}
sel(1, "A", "B", "C", def:"D")
sel(9, "A", "B", "C", def:"D")
sel(-1, "A", "B", "C", def:"D")



> On Jan 4, 2016, at 12:28 PM, Howard Lovatt <howard.lov...@gmail.com> wrote:
> 
> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
> prefer a library solution for now and remove ?: from the language and add a 
> which into the standard library and see how that goes and if there is need 
> for more.
> 
> Sorry,
> 
> Howard.
> 
>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>> usage as a preprocessor directive, but like how it stands out and has a 
>> meaning.  If no feedback, does it make sense to update my proposal with 
>> these ideas? Or does this feel like the wrong direction. 
>> 
>> 
>>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen <pos...@gmail.com 
>>> <mailto:pos...@gmail.com>> wrote:
>>> 
>>> Some more ideas, this moves away from the notion that we should make it 
>>> look really close to the ternary but keeps all the benefits of the ternary 
>>> and improves upon it. Since I have been suggesting a breaking change, it is 
>>> a good time to rethink it a bit. With this idea a horizontal line 
>>> (double-dash) separates the control value from the choices, the vertical 
>>> line (bar) indicates none of the above. 
>>> 
>>> Rather than use the ?( as I have suggested in the past, I think #( works 
>>> here, where you can think of it as a numerical index. The advantage of this 
>>> is, it stands out better and leaves ? for optionals only. This works well 
>>> with the list form. In the enum case the index is the enum key. I can see 
>>> that this however may be a problem because # is used for preprocessor like 
>>> directives. I am suggesting though just the #( sequence is treated 
>>> differently. Or the ?( is fine with me as well.
>>> 
>>> I have gone through a lot of options, some others I looked at are !( which 
>>> could be read as "match stick” paren, where the word “match” matches a 
>>> case, I am pretty sure that would not be considered any better than ?( 
>>> because it is used for optionals. Another is “witch hat paren” ^( which can 
>>> be read as “which”.  This might create a parse problem with "power of" 
>>> though, which maybe using ^[ (hat square bracket) could resolve that but 
>>> not sure if that would create other problems. Some other choices would be 
>>> &(  and @( but did not choose them because  they don’t have meaning to me 
>>> but they do have the advantage of standing out like the #(. 
>>> 
>>> let fa = #(truth -- 1 | 0) // boolean case. 
>>> let fb = #(pickOne -- "A", "B", "C", "D", "E", "F", "G" | "Z”) // list 
>>> form, pick index, zero based. 
&g

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

So without additional language support, I don’t see a library is workable but 
maybe it can. Maybe we can add variadic function lists? And new capabilities 
that are building blocks for building a switch expression.

> On Jan 4, 2016, at 3:53 PM, Paul Ossenbruggen <pos...@gmail.com> wrote:
> 
> Just tried going down this path a bit of creating a library. You can get 
> pretty far for the boolean or integer types, but don’t see a way to do a 
> switch like solution. Also, a big problem with this approach is there is no 
> way to short circuit evaluate the expressions in the list of a variadic 
> function. They will all be evaluated, at the call site. One other problem, so 
> we don’t conflict with the “else” and “default”, keywords, I had to use “def” 
> or “el” for “else". 
> 
> // Simple bool
> func calcB()->String {
> print(“B calculated")
> return "B"
> }
> 
> // Simple bool
> func sel(condition : Bool, @autoclosure _ trueExpr:()->T, @autoclosure _ 
> falseExpr:()->T) -> T {
> return condition ? trueExpr() : falseExpr()
> }
> 
> sel(true, "A", calcB())
> sel(false, "A", calcB())
> 
> // alternative, used "def" for default to not conflict with "else" or 
> “default. This version, may not be necessary.
> func sel(condition : Bool, @autoclosure _ expr:()->T,  @autoclosure 
> el:()->T) -> T {
> return condition ? expr() : el()
> }
> 
> sel(true, "A", el:calcB())
> sel(false, "A", el:calcB())
> 
> // index approach, note the use of autoclosure does not work on array or 
> array of functions. So it will evaluate all expressions at the call site. 
> Unless there is some trick I don’t know. 
> func sel(selector : Int,/* @autoclosure */ _ exprs: T..., def : T) -> T {
> if  selector > exprs.count || selector < 0 {
> return def
> }
> return exprs[selector]
> }
> sel(1, "A", "B", "C", def:"D")
> sel(9, "A", "B", "C", def:"D")
> sel(-1, "A", "B", "C", def:"D")
> 
> 
> 
>> On Jan 4, 2016, at 12:28 PM, Howard Lovatt <howard.lov...@gmail.com 
>> <mailto:howard.lov...@gmail.com>> wrote:
>> 
>> -1 for me. None of it looks or feels like Swift, more like Haskell. I would 
>> prefer a library solution for now and remove ?: from the language and add a 
>> which into the standard library and see how that goes and if there is need 
>> for more.
>> 
>> Sorry,
>> 
>> Howard.
>> 
>>> On 5 Jan 2016, at 7:24 AM, Paul Ossenbruggen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Any feedback on this? I am rethinking the idea of #( because of the # prior 
>>> usage as a preprocessor directive, but like how it stands out and has a 
>>> meaning.  If no feedback, does it make sense to update my proposal with 
>>> these ideas? Or does this feel like the wrong direction. 
>>> 
>>> 
>>>> On Dec 30, 2015, at 8:52 AM, Paul Ossenbruggen <pos...@gmail.com 
>>>> <mailto:pos...@gmail.com>> wrote:
>>>> 
>>>> Some more ideas, this moves away from the notion that we should make it 
>>>> look really close to the ternary but keeps all the benefits of the ternary 
>>>> and improves upon it. Since I have been suggesting a breaking change, it 
>>>> is a good time to rethink it a bit. With this idea a horizontal line 
>>>> (double-dash) separates the control value from the choices, the vertical 
>>>> line (bar) indicates none of the above. 
>>>> 
>>>> Rather than use the ?( as I have suggested in the past, I think #( works 
>>>> here, where you can think of it as a numerical index. The advantage of 
>>>> this is, it stands out better and leaves ? for optionals only. This works 
>>>> well with the list form. In the enum case the index is the enum key. I can 
>>>> see that this however may be a problem because # is used for preprocessor 
>>>> like directives. I am suggesting though just the #( sequence is treated 
>>>> differently. Or the ?( is fine with me as well.
>>>> 
>>>> I have gone through a lot of options, some others I looked at are !( which 
>>>> could be read as "match stick” paren, where the word “match” matches a 
>>>> case, I am pretty sure that would not be considered any better than ?( 
>>>> because it is

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

I can work on making the proposal shorter if that will help.  Any suggestions, 
for what could be made better. I am trying to be detailed but maybe that is 
making it too long. 

I am also not sure why this is not getting people excited. This seems like a 
clear win to me just being able to use  auto type inference when initializing 
it compared to switch statements is huge. I feel like I have tried to address 
most of the objections and what I am suggesting is quite a bit better than 
ternary, but with any solution there will be something that involves a trade 
off, these are problems with ternary as well. 

• terse but hard to understand.
• more descriptive but longer. 

These are conflicting problems and you can’t solve both but there is nothing so 
magical about the ternary that I can see. The problems I see with ternary:

• hard to see beginning and end **
• not immediately obvious what it does
• can’t be searched on the web **
• only supports boolean and can’t support more than two outcomes. ** 
• does not support switch like capabilities **

Good aspects of ternary:
• Terse **
• Fits in small places can be formatted multiline or single line. **
• guarantees the return type is compatible. **
• it is well known by C like language users
• it does not interrupt the control flow like an if statement does. So the code 
is linear. **
• you are guaranteed a result. **
• Automatically will infer type when binding a name. ** 
• reduces duplicated code. ** 
• quick conversions are possible. **  

All the items with ** stars next to them are addressed with the proposal others 
are no worse than ternary. 

And it adds some things:
• Adds switch expressions
• Adds using a zero based index to execute an expression. 
• Lets you easily see begin and end of the expression
• Different but better
• Supports more than two outcomes. 

Downsides:
• breaking change (I think there is value in a unified approach to doing 
expressions like this, we could leave ternary alone and adapt the rest of the 
proposal though, this has the downside that there are two ways of doing 
booleans though). 
• not as immediately as familiar as ternary (but similar enough that anyone who 
knows about ternary will quickly adapt). 

> On Jan 4, 2016, at 3:45 PM, Charles Constant <char...@charlesism.com> wrote:
> 
> Our ternary-like switch is now in the "commonly_proposed.md 
> <http://commonly_proposed.md/>" file, which doesn't bode very well. It 
> puzzles me that there isn't more enthusiasm. Are we the only ones who get 
> irritated taking up so much space with a "switch" when all we need to do is 
> transform between two sets of values?
> 
> I think we need to revamp the proposal somehow to make the idea clearer, 
> because it ought to be pretty compelling.
> 
> • Does anyone here have better "side by side" examples of code before/after? 
> 
> • Can anyone think of a way to revise the (English) language of the proposal 
> to make it shorter and sweeter? 
> 
> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
> busy"
> 
> 
> 
> 
> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Good feedback, I am all for making it feel more like swift. Any ideas would 
>> be welcome. I will also try to come up with some myself. 
> 
> My suggestion is to leave ternary alone and try to come up with a 
> ternary-like switch expression that is workable.  I think that is likely the 
> best change possible at this point.
> 
>> 
>> 
>>> On Jan 4, 2016, at 12:34 PM, Rod Brown <rodney.bro...@icloud.com 
>>> <mailto:rodney.bro...@icloud.com>> wrote:
>>> 
>>> For all the proposals I've seen on this topic, I have to say -1.
>>> 
>>> While I agree with the notions surrounding this operator, I've yet to see a 
>>> better alternative presented, and none that feel truly Swift.
>>> 
>>> If someone has a great proposal, though, I look forward to seeing it.
>>> 
>>> - Rod
>>> 
>>> On 5 Jan 2016, at 7:28 AM, Howard Lovatt via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> -1 for me. None of it looks or feels like Swift, more like Haskell. I 
>>>> would prefer a library solution for now and remove ?: from the language 
>>>> and add a which into the standard library and see how that goes and if 
>>>> there is need for more.
>>>> 

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

This is what is on the Commonly Rejected Changes section: 
Replace ?: Ternary Operator 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002609.html>:
 Definitely magical, but it serves a very important use-case for terse 
selection of different values. Proposals for alternatives have been intensely 
discussed, but none have been "better enough" for it to make sense to diverge 
from the precedent established by the C family of languages.

if/else and switch as expressions 
<https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html>: 
These are conceptually interesting things to support, but many of the problems 
solved by making these into expressions are already solved in Swift in other 
ways. Making them expressions introduces significant tradeoffs, and on balance, 
we haven't found a design that is clearly better than what we have so far.

Please detail what the trade offs are in making them expressions. What are the 
other ways that Swift currently supports this?

- Paul


> On Jan 4, 2016, at 4:42 PM, Paul Ossenbruggen <pos...@gmail.com> wrote:
> 
> I can work on making the proposal shorter if that will help.  Any 
> suggestions, for what could be made better. I am trying to be detailed but 
> maybe that is making it too long. 
> 
> I am also not sure why this is not getting people excited. This seems like a 
> clear win to me just being able to use  auto type inference when initializing 
> it compared to switch statements is huge. I feel like I have tried to address 
> most of the objections and what I am suggesting is quite a bit better than 
> ternary, but with any solution there will be something that involves a trade 
> off, these are problems with ternary as well. 
> 
> • terse but hard to understand.
> • more descriptive but longer. 
> 
> These are conflicting problems and you can’t solve both but there is nothing 
> so magical about the ternary that I can see. The problems I see with ternary:
> 
> • hard to see beginning and end **
> • not immediately obvious what it does
> • can’t be searched on the web **
> • only supports boolean and can’t support more than two outcomes. ** 
> • does not support switch like capabilities **
> 
> Good aspects of ternary:
> • Terse **
> • Fits in small places can be formatted multiline or single line. **
> • guarantees the return type is compatible. **
> • it is well known by C like language users
> • it does not interrupt the control flow like an if statement does. So the 
> code is linear. **
> • you are guaranteed a result. **
> • Automatically will infer type when binding a name. ** 
> • reduces duplicated code. ** 
> • quick conversions are possible. **  
> 
> All the items with ** stars next to them are addressed with the proposal 
> others are no worse than ternary. 
> 
> And it adds some things:
> • Adds switch expressions
> • Adds using a zero based index to execute an expression. 
> • Lets you easily see begin and end of the expression
> • Different but better
> • Supports more than two outcomes. 
> 
> Downsides:
> • breaking change (I think there is value in a unified approach to doing 
> expressions like this, we could leave ternary alone and adapt the rest of the 
> proposal though, this has the downside that there are two ways of doing 
> booleans though). 
> • not as immediately as familiar as ternary (but similar enough that anyone 
> who knows about ternary will quickly adapt). 
> 
>> On Jan 4, 2016, at 3:45 PM, Charles Constant <char...@charlesism.com 
>> <mailto:char...@charlesism.com>> wrote:
>> 
>> Our ternary-like switch is now in the "commonly_proposed.md 
>> <http://commonly_proposed.md/>" file, which doesn't bode very well. It 
>> puzzles me that there isn't more enthusiasm. Are we the only ones who get 
>> irritated taking up so much space with a "switch" when all we need to do is 
>> transform between two sets of values?
>> 
>> I think we need to revamp the proposal somehow to make the idea clearer, 
>> because it ought to be pretty compelling.
>> 
>> • Does anyone here have better "side by side" examples of code before/after? 
>> 
>> • Can anyone think of a way to revise the (English) language of the proposal 
>> to make it shorter and sweeter? 
>> 
>> Apologies for prescribing instead of doing. My only excuse is that I'm "too 
>> busy"
>> 
>> 
>> 
>> 
>> On Mon, Jan 4, 2016 at 3:03 PM, Matthew Johnson via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Jan 4, 2016, at 2:37 PM, Paul Ossenbruggen via swi

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Hi David,

I have been using ?( as kind of a more general meaning that there is a question 
here not that ? is just for optionals. I am fine with using some other 
character or word if it expresses the idea that the expression returns one of 
the results based upon the control parameter. ? is kind of established for the 
ternary though. Any word should be very short. In the alternatives considered I 
talk about using if(, switch(, select( would that be preferable? I am still 
hoping to keep it really short though. Other than using the words as shown, i 
am having a hard time coming up with something that would be better than ?.

- Paul



> On Dec 23, 2015, at 10:39 PM, David Waite via swift-evolution 
>  wrote:
> 
> My only issue (barring any longer term plan to move toward everything being 
> an expression) is that the question mark already has many uses in the 
> language. If we aren’t supporting the C-style ternary operator syntax, I 
> don’t know if there is a good reason anymore to use ‘?’ considering its heavy 
> use around optionals.
> 
> -DW
> 
>> On Dec 23, 2015, at 2:05 PM, Rainer Brockerhoff via swift-evolution 
>>  wrote:
>> 
>> On 22/12/15 16:50 , swift-evolution-requ...@swift.org wrote:
>>> Date: Tue, 22 Dec 2015 10:07:26 -0800
>>> From: Jordan Rose 
>>> To: Thorsten Seitz 
>>> Message-ID: <2d35f5bd-3ddf-43c3-a461-14fb65530...@apple.com>
>>> 
>>> I think this is a good point. We definitely want to keep the boolean
>>> ternary operator compact for the simple cases, and that may be at
>>> odds with a general switch expression (with multi-case pattern
>>> match).
>> 
>> +1 for a compact form.
>> 
>> I use the boolean ternary a lot, and I'd really dislike complicating it
>> with keywords or expanding it into a multiline construct with cases.
>> 
>> Nesting is of course its main problem.
>> 
>> 
>>> Date: Tue, 22 Dec 2015 10:53:50 -0800
>>> From: Paul Ossenbruggen 
>>> Message-ID: <7c5eca99-4527-4995-8503-215f294cc...@gmail.com>
>>> 
>>> • it is hard to tell when a ternary begins and ends, especially when nested.
>> 
>> At first I liked Paul's original proposal of
>>  let a = ?(x == y: a, b)
>> but I now think something intermediate like
>>  let a = x == y ?(a, b)
>> would look better; it does take care of nesting. For more clarity one
>> could always write
>>  let a = (x == y) ?(a, b)
>> 
>>> • It is not until you get to the question mark that you realize it is a 
>>> ternary.
>> 
>> I think that's actually a good thing. You (or the parser) have found a
>> boolean expression and when the ?( appears you understand the result is
>> fed into a selector. Were the ? and ( separate you could consider ? as a
>> binary operator accepting a boolean and a 2-tuple.
>> 
>> Today, using ? as an operator appears not to be allowed, but
>> public func ?? (left:Bool, right: (T, T)) -> T {
>>  if (left) {
>>  return right.0
>>  }
>>  return right.1
>> }
>> already works:
>>  let a = (x == y) ?? (a, b)
>> runs as expected. Downside, no @autoclosure on tuple items.
>> 
>> IOW, you shouldn't be too surprised finding a binary operator after an
>> expression :-)
>> 
>> -- 
>> Rainer Brockerhoff  
>> Belo Horizonte, Brazil
>> "In the affairs of others even fools are wise
>> In their own business even sages err."
>> http://brockerhoff.net/blog/
>> ___
>> 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] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Been thinking about the boolean case a bit more, and how to make it better than 
a ternary using my proposed syntax. So else could be put there to help show it 
is the opposite. The downside is this makes it mix keywords and operators so 
seems a bit jarring. 

With the new form parenthesis are built into it and are required:

x = ?(x == y : 49 else 3) 
alternatively the bang means do the opposite:

x = ?(x == y : 49 ! 3) // not sure this creates a parsing problem. 
or if the above causes a parsing problem:

x = ?(x == y : 49 | 3)  
Any thoughts?

> On Dec 23, 2015, at 7:02 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I know, but that won't support pattern matching.
> 
> Félix
> 
>> Le 23 déc. 2015 à 02:22:07, David Waite > > a écrit :
>> 
>> In the case where your input is hashable, you could just do:
>> 
>> let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color]
>> 
>> this would mean that color must be a Color and not an Optional 
>> (because of swift 2.x limitations)
>> 
>> -DW
>> 
>>> On Dec 22, 2015, at 8:04 AM, Félix Cloutier via swift-evolution 
>>> > wrote:
>>> 
>>> I like the gist of it too, though you seem to introduce both a new keyword 
>>> and a new syntax. (To be clear, I like the syntax but I'm ambivalent 
>>> towards reusing switch instead of which.)
>>> 
>>> My minor suggestions would to avoid braces for things that aren't scopes; 
>>> that either the comma or the the question mark is redundant in their 
>>> current position (you need a start delimiter or an end delimiter but you 
>>> don't need both); and that it needs a way to handle a default case if 
>>> enumeration isn't exhaustive (I'd do that by returning an optional).
>>> 
 let i = which color (.Red: 0xff, .Green: 0x00ff00, .Blue: 0xff) ?? 
 0x00
>>> 
>>> 
>>> Thinking out loud, once you remove the question marks it really looks like 
>>> a dictionary literal, so maybe it could even use square brackets to close 
>>> the gap.
>>> 
 let i = which color [.Red: 0xff, .Green: 0x00ff00, .Blue: 0xff] ?? 
 0x00
>>> 
>>> 
>>> I thought about subscripting a dictionary literal in place:
>>> 
 [Color.Red: 0xff, ...][color] ?? 0x00
>>> 
>>> 
>>> but that won't support elaborate pattern matching, and I think that this is 
>>> a deal breaker for the functional folks.
>>> 
>>> Félix
>>> 
 Le 22 déc. 2015 à 09:31:32, Charles Constant > a écrit :
 
 Just goofing on this a little. What if we called it a "which" statement, 
 instead of a "switch" statement? It's a bit cutesy, but not too verbose, 
 and it makes sense if you read it aloud.
 
 let i = which color {
? .Red: 0xFF, 
? .Green: 0x00FF00, 
? .Blue: 0x0FF
 }
 
 let i = which boo {
? true: 1, 
? false: 0, 
? nil: -1
 }
 
>>> 
>>> ___
>>> 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] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

I think trying to mix statements and expressions will definitely lead to a more 
complex solution I have tried going down that path. The second and third 
approaches in my email last night attempt to straddle the line between more 
cryptic ? syntax of the ternary and the if, switch, approach. 

I don’t have an aversion to the ternary just because it is in C. In fact, when 
I first started writing the proposal, it was intending to keep it exactly as 
is, but it became clear that there would be two different forms, and that what 
I was proposing would be better than ternary. I think my proposal addresses 
many of the shortcomings of the ternary and provides more capability. 

Just to list a few, but in my proposal I have a much more exhaustive list:

• it is hard to tell when a ternary begins and ends, especially when nested.
• It is not until you get to the question mark that you realize it is a ternary.
• it is hard to read something like this x = y == z ? “A”, “B” does the == get 
read first or second. 

With my proposal all these issues are addressed which makes it better than 
ternary. 

- Paul 




> On Dec 22, 2015, at 10:14 AM, Craig Cruden via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> IMHO, I think the issue is that (at least in my case) we may be trying to 
> create expression versions of “if” and “switch” (multi-line) and not are 
> trying to create them in such a way as to keep statements and expressions as 
> separate syntax / keywords…. which is leading to a more cryptic solution.  
> Not being a compiler guy, I have no idea what the complication is with 
> regards to why the syntax has to be different.
> 
> Or we are trying to create new syntax for a simple C ternary because 
> somewhere along the line some people have an aversion to syntax just because 
> C uses it.
> 
> Those two are combining in an unholy alliance  :o
> 
> Craig
> 
>> On 2015-12-23, at 1:07:26, Jordan Rose via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I think this is a good point. We definitely want to keep the boolean ternary 
>> operator compact for the simple cases, and that may be at odds with a 
>> general switch expression (with multi-case pattern match).
>> 
>> Jordan
>> 
>> 
>>> On Dec 22, 2015, at 10:03 , Thorsten Seitz via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Sorry, but I find all these very unreadable.
>>> 
>>> IMO trying to create one-line switch expressions is a non-goal as I would 
>>> always write switch expressions in multiple lines, one per case. Anything 
>>> else I personally consider unreadable.
>>> 
>>> -Thorsten 
>>> 
>>> Am 22.12.2015 um 09:11 schrieb Paul Ossenbruggen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>> 
>>>> All,
>>>> 
>>>> I have continued work on my proposal. I am trying to gauge whether people 
>>>> feel that this syntax which is currently in the proposal is better or 
>>>> worse than the last two variations.  The current proposal syntax:
>>>> 
>>>> let a = ?(x == y: a, b)
>>>> let b = ?(colorEnum : Red: 0xFF, .Green: 0x00FF00, .Blue: 0x0FF, 
>>>> default: 0xFF)
>>>> let c = ?(pickOne : “A”, “B”, “C:, default: “Z”)
>>>> 
>>>> The preceding is the unified ?( operator approach and is the closest to 
>>>> the existing ternary. but expands its capabilities to support more types 
>>>> of control than just bool. It is the most concise and adds no new 
>>>> keywords. It determines the kind of expression based upon the format 
>>>> inside the braces. The next version is the full keyword approach which has 
>>>> the same capabilities but separates each kind out:  
>>>> 
>>>> let a = if(x == y then "A" else "B")
>>>> let b = switch(colorEnum then .Red: 0xFF, .Green: 0x00FF00, .Blue: 
>>>> 0x0FF, default: 0xFF) 
>>>> let c = select(pickone then "A", "B", "C", default: "Z”)
>>>> 
>>>> or to avoid a new keyword and be slightly more concise. This one is the 
>>>> hybrid approach:
>>>> 
>>>> let a = if(x == y : "A" else "B")
>>>> let b = switch(colorEnum : .Red: 0xFF, .Green: 0x00FF00, .Blue: 
>>>> 0x0FF) 
>>>> let c = select(pickone : "A", "B", "C", defaul

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

I have definitely been trying to keep this in mind with these designs. Compact 
representations should be possible.


> On Dec 22, 2015, at 10:07 AM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> I think this is a good point. We definitely want to keep the boolean ternary 
> operator compact for the simple cases, and that may be at odds with a general 
> switch expression (with multi-case pattern match).
> 
> Jordan
> 
> 
>> On Dec 22, 2015, at 10:03 , Thorsten Seitz via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Sorry, but I find all these very unreadable.
>> 
>> IMO trying to create one-line switch expressions is a non-goal as I would 
>> always write switch expressions in multiple lines, one per case. Anything 
>> else I personally consider unreadable.
>> 
>> -Thorsten 
>> 
>> Am 22.12.2015 um 09:11 schrieb Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>> 
>>> All,
>>> 
>>> I have continued work on my proposal. I am trying to gauge whether people 
>>> feel that this syntax which is currently in the proposal is better or worse 
>>> than the last two variations.  The current proposal syntax:
>>> 
>>> let a = ?(x == y: a, b)
>>> let b = ?(colorEnum : Red: 0xFF, .Green: 0x00FF00, .Blue: 0x0FF, 
>>> default: 0xFF)
>>> let c = ?(pickOne : “A”, “B”, “C:, default: “Z”)
>>> 
>>> The preceding is the unified ?( operator approach and is the closest to the 
>>> existing ternary. but expands its capabilities to support more types of 
>>> control than just bool. It is the most concise and adds no new keywords. It 
>>> determines the kind of expression based upon the format inside the braces. 
>>> The next version is the full keyword approach which has the same 
>>> capabilities but separates each kind out:  
>>> 
>>> let a = if(x == y then "A" else "B")
>>> let b = switch(colorEnum then .Red: 0xFF, .Green: 0x00FF00, .Blue: 
>>> 0x0FF, default: 0xFF) 
>>> let c = select(pickone then "A", "B", "C", default: "Z”)
>>> 
>>> or to avoid a new keyword and be slightly more concise. This one is the 
>>> hybrid approach:
>>> 
>>> let a = if(x == y : "A" else "B")
>>> let b = switch(colorEnum : .Red: 0xFF, .Green: 0x00FF00, .Blue: 
>>> 0x0FF) 
>>> let c = select(pickone : "A", "B", "C", default: "Z")
>>> 
>>> Note that the use of parenthesis outside the entire expression in these is 
>>> to emphasize that these are expressions, can be read almost like a regular 
>>> function, they serve to group the entire expression, and they would be 
>>> required around the full expression only the leading keyword is outside. 
>>> This will disambiguate it from the statement form. Braces are for 
>>> statements and parenthesis for expressions. Putting the “then”and “else” 
>>> part inside the parens also avoids the problem of “then” with the following 
>>> format:
>>> 
>>> x = if cond then A else B
>>> 
>>> With this we would have support “then” in the “if" statement form and it is 
>>> hard to tell it from the statement form. By putting it in parenthesis, we 
>>> can put whatever we want in there. 
>>> 
>>>  The advantage of the second or third approach is the syntax would be 
>>> custom to each kind so additional checking could be performed to ensure it 
>>> is correct for the keyword provided. The keywords would be context 
>>> sensitive so may not interfere with other uses of it. 
>>> 
>>> These last two possibilities may address some of the issues that Jordan 
>>> Rose brought up…the first is the double colon, for the separator and for 
>>> the cases. The issue he mentioned second is that he did not feel my 
>>> proposal addressed any of the problems with the ternary, and third he wants 
>>> to keep the ? just for optionals. If the colon to separate the control, in 
>>> the last one is not good, I am open to suggestions for other separators, 
>>> but keep in mind, that goes even further from the ternary which may or may 
>>> not be a good thing.
>>> 
>>> I think I would be happy with any of these. If the consensus is that either 
>>> of the last two are preferable, I will rewrite the pro

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

This is interesting, the “which" out front helps to keep conditional from just 
“floating" as it does with the ternary and using the square brackets and a 
dictionary like sequence is pretty cool. I did think a bit along these lines 
too. You could have a Array like and Dictionary like form. The melding of the 
nil-coalescing operator is also a nice way to deal with the else part. Not sure 
“which” works with the array form but perhaps. 

i really would like to support pattern matching. I also have concerns about the 
different but not better comments I got.

- Paul


> On Dec 22, 2015, at 7:04 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I like the gist of it too, though you seem to introduce both a new keyword 
> and a new syntax. (To be clear, I like the syntax but I'm ambivalent towards 
> reusing switch instead of which.)
> 
> My minor suggestions would to avoid braces for things that aren't scopes; 
> that either the comma or the the question mark is redundant in their current 
> position (you need a start delimiter or an end delimiter but you don't need 
> both); and that it needs a way to handle a default case if enumeration isn't 
> exhaustive (I'd do that by returning an optional).
> 
>> let i = which color (.Red: 0xff, .Green: 0x00ff00, .Blue: 0xff) ?? 
>> 0x00
> 
> 
> Thinking out loud, once you remove the question marks it really looks like a 
> dictionary literal, so maybe it could even use square brackets to close the 
> gap.
> 
>> let i = which color [.Red: 0xff, .Green: 0x00ff00, .Blue: 0xff] ?? 
>> 0x00
> 
> 
> I thought about subscripting a dictionary literal in place:
> 
>> [Color.Red: 0xff, ...][color] ?? 0x00
> 
> 
> but that won't support elaborate pattern matching, and I think that this is a 
> deal breaker for the functional folks.
> 
> Félix
> 
>> Le 22 déc. 2015 à 09:31:32, Charles Constant  a 
>> écrit :
>> 
>> Just goofing on this a little. What if we called it a "which" statement, 
>> instead of a "switch" statement? It's a bit cutesy, but not too verbose, and 
>> it makes sense if you read it aloud.
>> 
>> let i = which color {
>>  ? .Red: 0xFF, 
>>  ? .Green: 0x00FF00, 
>>  ? .Blue: 0x0FF
>> }
>> 
>> let i = which boo {
>>  ? true: 1, 
>>  ? false: 0, 
>>  ? nil: -1
>> }
>> 
> 
> ___
> 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] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

All,

I have continued work on my proposal. I am trying to gauge whether people feel 
that this syntax which is currently in the proposal is better or worse than the 
last two variations.  The current proposal syntax:

let a = ?(x == y: a, b)
let b = ?(colorEnum : Red: 0xFF, .Green: 0x00FF00, .Blue: 0x0FF, 
default: 0xFF)
let c = ?(pickOne : “A”, “B”, “C:, default: “Z”)

The preceding is the unified ?( operator approach and is the closest to the 
existing ternary. but expands its capabilities to support more types of control 
than just bool. It is the most concise and adds no new keywords. It determines 
the kind of expression based upon the format inside the braces. The next 
version is the full keyword approach which has the same capabilities but 
separates each kind out:  

let a = if(x == y then "A" else "B")
let b = switch(colorEnum then .Red: 0xFF, .Green: 0x00FF00, .Blue: 
0x0FF, default: 0xFF) 
let c = select(pickone then "A", "B", "C", default: "Z”)

or to avoid a new keyword and be slightly more concise. This one is the hybrid 
approach:

let a = if(x == y : "A" else "B")
let b = switch(colorEnum : .Red: 0xFF, .Green: 0x00FF00, .Blue: 0x0FF) 
let c = select(pickone : "A", "B", "C", default: "Z")

Note that the use of parenthesis outside the entire expression in these is to 
emphasize that these are expressions, can be read almost like a regular 
function, they serve to group the entire expression, and they would be required 
around the full expression only the leading keyword is outside. This will 
disambiguate it from the statement form. Braces are for statements and 
parenthesis for expressions. Putting the “then”and “else” part inside the 
parens also avoids the problem of “then” with the following format:

x = if cond then A else B

With this we would have support “then” in the “if" statement form and it is 
hard to tell it from the statement form. By putting it in parenthesis, we can 
put whatever we want in there. 

 The advantage of the second or third approach is the syntax would be custom to 
each kind so additional checking could be performed to ensure it is correct for 
the keyword provided. The keywords would be context sensitive so may not 
interfere with other uses of it. 

These last two possibilities may address some of the issues that Jordan Rose 
brought up…the first is the double colon, for the separator and for the cases. 
The issue he mentioned second is that he did not feel my proposal addressed any 
of the problems with the ternary, and third he wants to keep the ? just for 
optionals. If the colon to separate the control, in the last one is not good, I 
am open to suggestions for other separators, but keep in mind, that goes even 
further from the ternary which may or may not be a good thing.

I think I would be happy with any of these. If the consensus is that either of 
the last two are preferable, I will rewrite the proposal with that in mind. 
Please let me know if you have any questions or have other suggestions. 

Thanks,
- Paul

For latest version of proposal and see Alternatives Considered section for more 
details on this: 
https://github.com/possen/swift-evolution/blob/master/proposals/0024.md

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

Re: [swift-evolution] << Operator to append to array

[Paul Ossenbruggen via swift-evolution]

You can do this already

left += [right]

> On Dec 21, 2015, at 9:22 AM, James Campbell via swift-evolution 
>  wrote:
> 
> I already have an implementation:
> 
> func <<(var left: Array, right:T)
> 
> {
> 
> left.append(right)
> 
> }
> 
> 
> 
> It makes
> 
> myArray.append(myArrayItem)
> 
> become:
> 
> myArray << myArrayItem
> 
> 
> 
> Which is shorter and a lot of languages such as Ruby already use this.
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698
>  ___
> 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] << Operator to append to array

[Paul Ossenbruggen via swift-evolution]

I should have said 

myArray += [myArrayItem]

> On Dec 21, 2015, at 9:28 AM, Paul Ossenbruggen  wrote:
> 
> You can do this already
> 
> left += [right]
> 
>> On Dec 21, 2015, at 9:22 AM, James Campbell via swift-evolution 
>> > wrote:
>> 
>> I already have an implementation:
>> 
>> func <<(var left: Array, right:T)
>> 
>> {
>> 
>> left.append(right)
>> 
>> }
>> 
>> 
>> 
>> It makes
>> 
>> myArray.append(myArrayItem)
>> 
>> become:
>> 
>> myArray << myArrayItem
>> 
>> 
>> 
>> Which is shorter and a lot of languages such as Ruby already use this.
>> 
>> 
>> -- 
>>  Wizard
>> ja...@supmenow.com 
>> +44 7523 279 698
>>  ___
>> 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] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Thanks, great feedback!

Good point about the floats, that is definitely a hole in my proposal! I will 
update it with that.

To the list form being confusing, I would definitely like to know if others 
agree that having the two forms is confusing. The list form would be zero 
based. I would definitely drop it from the proposal if it would lead to it 
being declined but I think it is nice because it is concise and serves a 
valuable purpose of choosing among many choices without having to write out 
each case. 

The alternate form,  in alternatives considered, a variant of Vestor Godfied’s 
suggestion, is:

if (x==y : true, false)
switch (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “) 
select (control : “A”, “B”, “C”, default:”D”) 

may be preferred if others agree that it is confusing to have the list form and 
the case form together. Since Swift leaves parenthesis available around if and 
switch statements, the parenthesis colon sequence could be used to distinguish 
the statement and expression form. One thing I really don’t like about it is, 
that Swift finally solved the problem people running the space up against the  
parenthesis, something that had bothered me for some time, this would make the 
practice ingrained if(control : true, false) would become the norm. I suppose 
in this case it would make sense though. 

Or if making it even more explicit we could combine the forms. 

if? (x==y : true, false)
switch? (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “) 
select? (control : “A”, “B”, “C”, default:”D”) 

I expect that that may be more controversial though. As it then steps into the 
optionals area. 

With both these options we lose some conciseness. So I still prefer the form in 
the proposal. 

- Paul

> On Dec 19, 2015, at 2:43 AM, Conrad Kutsch via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Hey, I really like the new proposal, gets a +1from me! Especially the case 
> part makes it good to use. I would just leave out the Integer part because it 
> can be confusing and misleading. Do you start counting at 1? Or at 0? MinInt? 
> It’s just super error-prone if you don’t write the number before it.
> 
> ?(charNum : 0: "A", 1: "B”, ...
> might be OK as it would get rid of the many case statements but then again, 
> is this only working for Int or also for float?
> 
> 
> 
>> On 19 Dec 2015, at 01:56, Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Thanks for your support! 
>> 
>> I think parenthesis are preferred because braces are for bracketing lists of 
>> statements. Statements may or may not return values. 
>> 
>> Having the conditional on the inside of the parens helps to show the begging 
>> of the demux operator rather than a floating conditional which is a common 
>> complaint with the ternary operator. 
>> 
>>> On Dec 18, 2015, at 3:46 PM, Charles Constant <char...@charlesism.com 
>>> <mailto:char...@charlesism.com>> wrote:
>>> 
>>> +1 
>>> 
>>> I'd be very happy with your new proposal too. I still prefer sticking the 
>>> value we're using as a key outside of the parens, but it's a minor quibble. 
>>> Also I can't figure out if parens or curly braces are more appropriate. 
>>> Does it make more sense for the expression to look like a tuple or a 
>>> closure? I'm not sure.
>>> 
>>> Anyhow, I'm good with your new proposal.
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

> On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> +1 to Jordan's points as well. 
> 
> Generally speaking, there is clearly a wide variety of things that cause 
> people to be interested in this particular proposal and I don't think we can 
> reconcile all of them. For example, I think that "collapsing an if statement 
> into one line" isn't a good enough reason to introduce the clutter and 
> potential for abuse of the original ternary syntax into a codebase, so I 
> generally float the idea to ban it from projects I'm involved in as soon as I 
> see it pop up in one. At the same time, there seem to be people who are 
> enamored with the concept, and maybe instead they talk in this thread because 
> they want a way to condense a switch statement into one line. And still 
> others think that there is no rush to think about getting rid of ternary, 
> unless we come up with something equally concise or with significant 
> advantages to warrant removing it (all valid points).
> 
> I'm not against Paul's idea, but if it matters at all (i.e. if you are 
> worried other people will think like me), if this syntax is released, I will 
> most likely float the idea of opting out of it immediately to my project 
> collaborators. 
> 
> While interesting for quick, proof of concept coding sessions, it already has 
> some of the readability and abusability disadvantages already present in 
> ternary, and it's still just in the proposal stage. 
> 
> I only hope that this doesn't preclude progress on turning fully-qualified 
> (and indented) statements into expressions.

Good feedback!

Personally, I kind of hope that that is not the direction of Swift. I think 
there is quite a bit of value in keeping expressions and statements as separate 
concepts. If you need to do a bunch of things to get the result of an 
expression then use the statement construct or move it into a method. 

Having statements that act as expressions encourages code that has side 
effects, which goes against one of the core concepts of functional programming. 
If I am working on a team, and someone wants to add some new feature and they 
see a big indented “if” with braces, they will just stick it in there and 
ignore that it is a functional approach. That new statement they add may add a 
bunch of side effects and add bugs to the code. If it is an expression that 
temptation will be less likely. They will see that this code is intended to 
work as an expression and won’t be able to just stick another statement with a 
bunch of side effects into it. 

My proposal is about making expressions into first class citizens in terms of 
control flow. Its main purpose is definitely not about doing things on one 
line, that is just a side benefit if it works for your particular situation. 
This proposal supports and encourages multiline formatting and I think actually 
makes things cleaner and clearer than the statement forms. 

But this feedback and Jordan’s is making me think that the Hybrid approach in 
Alternatives Considered may be more appealing to everyone. I was thinking 
conciseness might be preferable given some of the feedback I got from Chris and 
others, but after reading some other threads, clarity wins out over 
conciseness. This alternative may win for clarity. So I might go back and 
rethink that, but before I do that, I hope that more people could tell me if 
they like it better or do they like the ?( syntax better.

- Paul


> 
> On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> > On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > It's a nice, consistent proposal, but I don't feel like this solves any of 
> > the complaints about the existing ternary operator:
> >
> > - It's not obvious what it does when you first learn it.
> > - The '?' doesn't have anything to do with Optionals.
> >
> > It is a way to put 'switch' into an expression. I'm not a fan of the two 
> > different colons, but that's "just" syntax.
> 
> +1 to all that
> 
> > Jordan
> >
> >> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution 
> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >>
> >> All,
> >>
> >> I think, I finally might have the answer to improving ternary, with such a 
> >> bold statement come some pretty high expectations but I think, I might 
> >> actually have done it this time :-)
> >>
> >> I am calling it the Dem

Re: [swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen via swift-evolution]

Thank you for your feedback!

Just want to respond a little bit, I don’t believe it is any worse than the 
ternary in terms of it being non obvious as to what it does, and it adds a lot 
of power beyond the ternary, because now you can switch to more than two 
outcomes. 

In terms of readability, it does improve on the ternary because I often find it 
hard to determine where a ternary begins, in unfamiliar code, looking at:

x = x == y ? 49 : 3 

It is not until you get to the question mark that you realize it is a ternary 
and the x == y just is kind of floating there. The = and == just looks strange. 
Many do this to make it look better:

x = (x == y ? 49 : 3) 

With the new form:

x = ?(x == y : 49, 3) 

The x == y pops out more, similar to how adding the parenthesis helps, and you 
can immediately tell that this is part of a demux expression. This codifies the 
practice, of putting in parenthesis, in the same way that mandatory braces in 
control flow statements make the statements stand out. So I do believe it does 
address some of the problems with ternary. 

If that is not enough of a difference from ternary to make this proposal fly, 
then maybe the hybrid approach outlined in Alternatives Considered section 
would be preferred? One example: 

x = if(x == y : 49, 3) 

This looks more function like and has many of the benefits of my original 
proposal and perhaps better addresses some of the downside of the ? being non 
obvious as to what it does at the expense of conciseness. Although, as Austin 
Zheng says, ? is for query, not necessarily just to indicate optional. If we 
don’t go with that interpretation of ?, this direction, may help to keep the 
concept of ? for optionals. Ternary kind of steps into that and makes it less 
separated so this alternative may be a better direction. I don’t object to this 
approach, if that is the consensus.

- Paul 





> On Dec 19, 2015, at 7:55 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> It's a nice, consistent proposal, but I don't feel like this solves any of 
> the complaints about the existing ternary operator:
> 
> - It's not obvious what it does when you first learn it.
> - The '?' doesn't have anything to do with Optionals.
> 
> It is a way to put 'switch' into an expression. I'm not a fan of the two 
> different colons, but that's "just" syntax.
> 
> Jordan
> 
>> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> All,
>> 
>> I think, I finally might have the answer to improving ternary, with such a 
>> bold statement come some pretty high expectations but I think, I might 
>> actually have done it this time :-)
>> 
>> I am calling it the Demux Expression, it builds on the benefits of ternary 
>> and switch while improving on those. 
>> 
>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md
>> 
>> This is a first draft, thanks in advance for feedback!
>> 
>> - Paul
>> ___
>> 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