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

Reply via email to