Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Thorsten Seitz via swift-evolution]

+1



I do like the syntax suggested by Dennis. Making use of Swift's ability to 
differentiate between external and internal parameter names is a great idea!



-Thorsten




Am 06. Mai 2016 um 06:25 schrieb "T.J. Usiyan via swift-evolution" 
:


+1 
I have wanted this since the first beta. I hadn't proposed because I haven't 
come up with a nice syntax to do this in functions/methods. I don't 
particularly like
    func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))


and the closes that I have come is to simply reuse the closure syntax with


    func takesATuple(someInt: Int, tuple: (String, String)) {  (someInt, 
(valueA, valueB)) in


but that gets confusing in my opinion, specifically if you choose to have 
different names inside and outside.






On Thu, May 5, 2016 at 11:22 AM, Dennis Weissmann via swift-evolution 
 wrote:

Following a short discussion with positive feedback on 
[swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812) I’d like 
to discuss the following:


Tuples should be destructible into their components in parameter lists.


Consider the following code:


let a = [0,1,2,3,4,5,6,7,8,9]
let b = [0,1,2,3,4,5,6,7,8,9]


let c = zip(a,b).reduce(0) { acc, tuple in
  acc + tuple.0 + tuple.1
}


tuple is of type (Int, Int).


The problem is that the calculation is not very comprehensible due to .0 and 
.1. That’s when destructuring tuples directly in the parameter list comes into 
play:


let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
  acc + valueA + valueB
}


The above is what I propose should be accepted by the compiler (but currently 
isn’t).


Currently tuple destructuring is possible like this:


let c = zip(a,b).reduce(0) { (acc, tuple) in
  let (valueA, valueB) = tuple
  return acc + valueA + valueB
}


This is not about saving one line ;-). I just find it much more intuitive to 
destructure the tuple in the parameter list itself.


The same thing could be done for functions:


func takesATuple(someInt: Int, tuple: (String, String))


Here we also need to destructure the tuple inside the function, but the 
intuitive place (at least for me) to do this would be the parameter list.


In the following example I'm making use of Swift’s feature to name parameters 
different from their labels (for internal use inside the function, this is not 
visible to consumers of the API):


func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))


Here valueA and valueB would be directly usable within the function. The tuple 
as a whole would not be available anymore.




Now it’s your turn!


1. What do you think?
2. Is this worth being discussed now (i.e. is it implementable in the Swift 3 
timeframe) or should I delay it?


Cheers,


- Dennis

___
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] multi-line string literals.

[Cole Campbell via swift-evolution]

> assert( xml != ei"""
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> """ )

The idea of auto-stripping whitespaces seemed nice initially, until I realized 
it's not at all clear where the stripped whitespaces end and the included 
whitespaces begin. It's already problematic for you own code (because even 
knowing your own intent doesn't completely overcome the lack of perspective 
this syntax offers), but imagine if it's someone else's. Will you be able to 
figure out what spacing is meant to be a part of the string and which is not? 
Quickly? Easily? Maybe, maybe not. It still won't be readily apparent, because 
there's no point of reference. You're potentially reduced to counting 
whitespaces to figure it out. Brent's proposal elegantly fixes this problem. 
You have a clear point of reference, there's no issue of spaces vs tabs, no 
trying to figure out exactly where the "true" whitespaces are beginning. Like 
was mentioned, it would probably have to be relative to the leading whitespaces 
on the closing delimiter line, but then there's no way to tell visually if 
those are spaces or tabs, or how many there are, AND you have to sort of 
mentally trace an invisible line upwards to "see" how the lines above relate. 
This would drive me crazy. With leading quotes, it's obvious which lines don't 
have included leading whitespaces, and the ones that do have a smaller relative 
distance to what is the "left alignment margin" (so to speak) indicated by the 
quotes.

This feels like we would be making it easier to make mistakes and harder to 
determine actual spacing just to eliminate some extra quotes. I think the 
proposal is the best balance of simplicity and practicality we're going to 
achieve for *short* multi line strings, which is what this proposal is tying to 
address. We can still introduce the """ or heredoc syntaxes for longer blocks 
of text in the future.

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

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[David Hart via swift-evolution]

If we are discussing naming changes to reduce, here's my personal opinion:

* When I first encountered it, I understood exactly what it did because I knew 
that term of art. If it was named sequence, I would have been confused.
* If we are discussing name changes, I'd personally vote to change it to fold. 
It is the other term of art used for it, and it makes unfold work.

David

> On 05 May 2016, at 22:39, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 1:03 PM, Erica Sadun  wrote:
>> 
>>> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>>> 
>>> Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as 
>>> specified in revision 3 of the proposal.
>> 
>> I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` 
>> pairs that linguistically matched.Nonetheless I'm gratified these are 
>> hopping into the language. That said, I'm going to put on my painters cap to 
>> consider selecting some exterior latex for the feature I was most looking 
>> forward to in this proposal:
>> 
>> Core team writes:
>>> unfold(_:applying:) - This addition is *rejected* by the core team as 
>>> written, but deserves more discussion in the community, and potentially 
>>> could be the subject of a future proposal.  The core team felt that the 
>>> utility of this operation is high enough to be worth including in the 
>>> standard library, but could not find an acceptable name for it.  “unfold” 
>>> is problematic, despite its precedence in other language, because Swift 
>>> calls the corresponding operation “reduce” and not “fold”.  No one could 
>>> get excited about “unreduce”.   “iterate” was also considered, but a noun 
>>> is more appropriate than an verb in this case.  Given the lack of a good 
>>> name, the core team preferred to reject to let the community discuss it 
>>> more.
>> 
>> A few thoughts:
>> 
>> * I'm not sure why a noun is more appropriate than a verb. Reduce isn't a 
>> noun, prefix isn't a noun, drop isn't a noun. 
> 
> I’m not a naming guru, but my understanding is that ‘reduce’ was picked 
> because it was term of art (like map), which is what allowed the misuse of a 
> verb.
> 
> One idea that came out of the core team discussion was something like:
> 
>sequence(from: 0) { $0 += 42 }
> 
> Since it returns a sequence.
> 
> -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] [Accepted] SE-0066: Standardize function type argument syntax to require parentheses

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

Hello Swift community,

The review of SE-0066 “Standardize function type argument syntax to require 
parentheses” ran from April 25...May 2, 2016. The proposal is accepted for 
Swift 3.

There was a significant amount of feedback on the proposal, with a fairly 
common theme of “lukewarm acceptance.” A number of community members were sad 
to see this familiar syntactic shortcut go away, but acknowledge that it fits 
well with recent directions, e.g., the elimination of the implicit tuple splat 
behavior (SE-0029 
).
 The core team acknowledges that the ability to elide parentheses is not 
actively harmful to the language, but felt that it was better to have 
consistency around function types (always have parentheses) than provide a 
relatively small syntactic shortcut for higher-order functions. The core team 
did not feel that this proposal needed to include required parentheses within 
closures, which have their own fairly specific grammar.

- Doug, Review Manager

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

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> As far as mixed whitespace, I think the only sane thing to do would be to 
> only allow leading tabs *or* spaces.  Mixing tabs and spaces in the leading 
> whitespace would be a syntax error.  All lines in the string would need to 
> use tabs or all lines use spaces, you could not have one line with tabs and 
> another with spaces.  This would keep the compiler out of the business of 
> making any assumptions or guesses, would not be a problem often, and would be 
> very easy to fix if it ever happens accidentally.

The sane thing to do would be to require every line be prefixed with *exactly* 
the same sequence of characters as the closing delimiter line. Anything else 
(except perhaps a completely blank line, to permit whitespace trimming) would 
be a syntax error.

But take a moment to consider the downsides before you leap to adopt this 
solution.

1. You have introduced tab-space confusion into the equation.

2. You have introduced trailing-newline confusion into the equation.

3. The #escaped and #marginStripped keywords are now specific to multiline 
strings; #escaped in particular will be attractive there for tasks like 
regexes. You will have to invent a different syntax for it there.

4. This form of `"""` is not useful for not having to escape `"` in a 
single-line string; you now have to invent a separate mechanism for that.

5. You can't necessarily look at a line and tell whether it's code or string. 
And—especially with the #escaped-style constructs—the delimiters don't 
necessarily "pop" visually; they're too small and easy to miss compared to the 
text they contain. In extremis, you actually have to look at the entire file 
from top to bottom, counting the `"""`s to figure out whether you're in a 
string or not. Granted, you *usually* can tell from context, but it's a far cry 
from what continuation quotes offer.

6. You are now forcing *any* string literal of more than one line to include 
two extra lines devoted wholly to the quoting syntax. In my Swift-generating 
example, that would change shorter snippets like this:

code +=  "
 "static var messages: [HTTPStatus: String] = [
 ""

Into things like this:

code +=  """
 
 static var messages: [HTTPStatus: String] = [

 """

To my mind, the second syntax is actually *heavier*, despite not requiring 
every line be marked, because it takes two extra lines and additional 
punctuation.

7. You are also introducing visual ambiguity into the equation—in the above 
example, the left margin is now ambiguous to the eye (even if it's not 
ambiguous to the compiler). You could recover it by permitting non-whitespace 
prefix characters:

code +=  """
|
|static var messages: [HTTPStatus: String] = [
|
|"""

...but then we're back to annotating every line, *plus* we have the leading and 
trailing `"""` lines. Worst of both worlds.

8. In longer examples, you are dividing the expression in half in a way that 
makes it difficult to read. For instance, consider this code:

socket.send( 
""" #escaped #marginStripped 


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""".data(using: NSUTF8StringEncoding))

The effect—particularly with even larger literals than this—is not unlike 
pausing in the middle of reading an article to watch a movie. What were we 
talking about again?

This problem is neatly avoided by a heredoc syntax, which keeps the expression 
together and then collects the string below it:

socket.send(""".data(using: NSUTF8StringEncoding))


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

"""

(I'm assuming there's no need for #escaped or #marginStripped; they're both 
enabled by default.)

* * *

Let's actually talk about heredocs. Leaving aside indentation (which can be 
applied to either feature) and the traditional token choices (which can be 
changed), I think these are the pros of heredocs compared to Python 
triple-quotes:

H1: Doesn't break up expressions, as discussed above.
H2: Literal content formatting is completely unaffected by code formatting, 
including the first and last lines.

Here are the pros of Python triple-quotes compared to heredocs:

P1: Simpler to explain: "like a string literal, but really big".
P2: Lighter syntactic weight, enough to make`"""` usable as a single-line 
syntax.
P3: Less trailing-newline confusion.

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

[Dmitri Gribenko via swift-evolution]

On Thu, May 5, 2016 at 5:11 PM, Nate Cook  wrote:
> Thanks for the feedback, Dmitri &co, this all looks excellent! I'll work on 
> updating the proposal.
>
>> On May 5, 2016, at 6:13 PM, Dmitri Gribenko  wrote:
>>
>> On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution
>>  wrote:
>>> Hello Swift community,
>>>
>>> The review of "SE-0078: Implement a rotate algorithm, equivalent to 
>>> std::rotate() in C++" begins now and runs through May 9.
>>
>> Hi,
>>
>> I'm posting this feedback on behalf of Dave Abrahams, Max Moiseev and
>> myself.  We met and discussed the proposal in great detail.
>>
>> First of all, we want to thank Nate and Sergey for proposing this API,
>> which is an important and useful algorithm.  We are generally in favor
>> of the proposal, but we would like to request a few changes.
>>
>> Could you make 'func rotate' a requirement in the MutableCollection
>> protocol?  This allows selecting the best implementation for a given
>> concrete type, even when calling from generic code.
>>
>> Could you explain why do we need a special implementation of
>> 'reverse()' for RandomAccessCollection?  We couldn't think of a
>> performance reason for this.
>
> With a bidirectional collection, you have to compare the high and low index 
> at each iteration, stopping when low >= high (before indices were Comparable, 
> this required two equality comparisons per iteration). With a random-access 
> collection, you can optimize the loop to use a fixed number of iterations, 
> which should be more efficient.

Good point!  In that case, 'reverse()' should also be a protocol
requirement, to allow dispatch to the most efficient version.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[T.J. Usiyan via swift-evolution]

   - What is your evaluation of the proposal?

I don't like it but +1. The possible ambiguity is somewhat compelling. I
actually think that, if this is accepted, it should be applied to closures
as well.


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

I am not sure.

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

I am not sure

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

N/A

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

I read it when it first showed up and have thought about it since while
writing and reading swift.

On Thu, Apr 28, 2016 at 4:19 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md
>
> >   • What is your evaluation of the proposal?
>
> I think this change is overly fussy, but not the end of the world.
>
> I enjoy this convenience, but I can live without it. I hope that, when the
> dust settles from all our parameter changes, we can reintroduce it in some
> form.
>
> >   • Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> It seems insignificant to me, but I support small syntax clean-ups in
> general.
>
> >   • Does this proposal fit well with the feel and direction of Swift?
>
> Arguably it does, at least for the current parameter-handling retrenchment.
>
> >   • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> N/A.
>
> >   • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Participated in previous discussion.
>
> --
> 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] multi-line string literals.

[L. Mihalkovic via swift-evolution]

Inline

Regards
(From mobile)

> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>>> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
  wrote:
 
 
> On 5 May 2016, at 14:17, David Hart  wrote:
> 
> 
 
> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>  wrote:
> 
> it's not a secret that I'm not a big fan of the proposal. The third draft 
> doesn't change this and it's unlikely that any future draft will, because 
> for me, the problem are the continuation quotes, and for Brent it seems 
> like they are a must-have-feature (correct me if I'm wrong.)
 
 I agree with all you said. I’m fairly sure I would never vote for Brent’s 
 proposal simply because of the existence of continuation quotes, no matter 
 the amount of reasoning behind it. They are simply too unwieldy, 
 cumbersome and unfriendly to modification.
 
 I could see either your proposal, or your proposal without the HERE_DOCs 
 but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
 formal proposal?
>>> 
>>> 
>>> Adapting the original proposal if you’re not a fan of continuation quotes..
>>> 
>>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>>> indented.
>>> As suggested earlier in this thread the lexer can strip the margin on the 
>>> basis of
>>> the whitespace before the closing quote as per Perl6 (This could be a 
>>> modifier “I”
>>> but might as well be the default TBH.) Would this be the best of both 
>>> worlds?
>>> 
>>> assert( xml == i"""
>>> 
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> ""” )
>>> 
>>> Other modifiers can also be applied such as “no-escapes"
>>> 
>>> assert( xml != ei"""
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> """ )
>>> 
>>> I’d hope this would satisfy any need for <>> 
>>> Or you could support both continuation and indented python style:
>>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz
>>> 
>>> John
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> I’m of the opinion that either of these are reasonable solutions, and both 
>> offer different tradeoffs. I’m probably partial to the continuation quotes, 
>> because I don’t want to be guessing about what is going to end up being in 
>> my string and what won’t. 
>> 
>>> assert( xml != ei"""
>>> 
>>>
>>>\(author)
>>>XML Developer's Guide
>>>Computer
>>>44.95
>>>2000-10-01
>>>An in-depth look at creating applications 
>>> with XML.
>>>
>>> 
>>> ""” )
>> 
>> For example, is there a new line after ?
>> How would the indenting work if it were immediately followed by triple 
>> quotes: ”””
>> I would really like the first line to be lined up with the rest of the xml. 
>> Is that going to introduce a newline into the top of the string?
>> 
>> Could we just enforce that no characters on the lines of the triple quotes 
>> would be included in the string, very much like the heredoc syntax?
>> 
>> assert( xml != ei"”” The text I’m typing here would cause a compiler 
>> error.
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> same here   ""” )
>> 
>> Then it’s very clear what the whitespace stripping will do. But what about 
>> mixed tab vs whitespace? What is the behavior in that case?
> 
> 
> I’m jumping into this thread late and have only followed bits of it so I 
> apologize if I’m repeating anything.
> 
> I really like the idea of having leading space stripped automatically without 
> requiring the continuation quotes.  I have done my share of leading space 
> stripping in the past when working with heredocs.  It’s not that big a deal 
> bu

[swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md

Hello Swift Community,

The review of SE-0072 "Fully eliminate implicit bridging conversions from 
Swift” ran from April 26 ... May 2, 2016. The proposal is *accepted* for Swift 
3. 

The feedback on this proposal was positive - the benefits of simplifying the 
type system and eliminating surprising behavior from the compiler is 
universally appealing.  However, both the core team and the community wanted a 
better sense of what the impact of the proposal would be in practice on real 
code.  Joe Pamer did some analysis and found out that there isn’t a significant 
impact on the most concerning use case:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016644.html

Thank you to Joe Pamer for driving the proposal and the implementation work for 
this improvement!

-Chris
Review Manager


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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

If we use triple quotes (i.e. """) at the beginning of the multi line string 
literal and again at the end, it seems very unlikely that the heredoc notation 
would be needed. 

I would simplify and remove the heredoc alternative from the proposal. 

Also, for those of us who like the continuation quotes, I think the 
continuation quotes could be optional. For example this:

let html = """
". 
" \(title)
".A paragraph.
". 
"
"""

would be equivalent to:


let html = """
. 
 \(title)
.A paragraph.
. 

"""

What do you think?



> On May 5, 2016, at 2:13 PM, L Mihalkovic via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> Hi,
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
>> 
>> I just wanted to say that I have drafted a proposal that solves the issues 
>> that I have encountered. (It's here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
>>  )
>> - it allows pasting text as-is
>> - it allows creating string literals where leading space on each line is 
>> stripped (while keeping indentation differences intact)
>> - it allows creating string literals where leading space on each line is not 
>> stripped
>> - optionally it allows strings to be raw, without any string interpolation 
>> or escaping whatsoever
>> - in none of the literals you have to write "> empty=\"\">", you can just write "". This also 
>> lets you copy&paste text out of the program source and back into a HTML file.
>> 
>> It had the idea that maybe the motivation behind continuation quotes is to 
>> make using multiline strings harder to use; in order to discourage their use 
>> at all. Two points to consider:
>> - people who don't want to use MSL will not, even if you throw Python-like 
>> """multi-line strings""" at them.
>> - people who want to use them do it, even if there is no MSL available. I 
>> saw that in Objective-C, with multiple lines of HTML and CSS wrapped into a 
>> big multiline objc-string-literal and thrown at a WebView. I could send the 
>> literal to the console before sending it to the WebView and it was basically 
>> unreadable. I eventually refactored it to put the thing into a file (also 
>> because the HTML grew in space, and the inline-literal became impractical)
>> - my most important point: if someone uses multiple lines of HTML or CSS or 
>> XML directly within the code, I want it to look okay. I don't want an MSL 
>> feature that is so unwieldy that people voluntarily not use it; it would be 
>> better to have no MSL at all.
>> 
>> I don't think that multiline strings are a must-have feature for a language, 
>> because they are not used very often. (I included an example of a good use 
>> case in my proposal.) I acknowledge that in many programming cases it would 
>> be better to not put a huge pile of text directly into the source, but to 
>> load the text from a file at runtime. But even when these MSL are misused, I 
>> prefer to read a """python multiline string""" over a 
>> "concatenated\n"+"Java\n"+"String".
>> 
>> -Michael
> 
> 
> Hi Michael. hope this helps  
> https://gist.github.com/lmihalkovic/11f2b1b23b78bbb9cbf0292ffc480b3d
> 
> 
> ___
> 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] Making `.self` After `Type` Optional

[Joe Groff via swift-evolution]

To keep progress going on this, I collected my thoughts from March's discussion 
into a draft proposal:

https://github.com/apple/swift-evolution/pull/299

-Joe

> On Mar 9, 2016, at 11:23 AM, Tanner Nelson via swift-evolution 
>  wrote:
> 
> Hello Swift Evolution members,
> 
> I would like to propose making `.self` After a Type optional when referencing 
> Types in expressions.
> 
> Currently, to pass a Type to a function or method, it is sometimes required 
> to add `.self` after the Type. This behavior is inconsistent as it is only 
> required if the signature has more than one parameter. 
> 
> Here is a demonstration of the current inconsistency. 
> 
> ```swift
> func test(type: T.Type, two: String) {
>print(type)
> }
> 
> func test(type: T.Type) {
>print(type)
> }
> 
> test(Int.self)
> test(Int)
> 
> test(Int.self, two: "")
> test(Int, two: "") //Expected member name or constructor call after type name
>  ^~~
> ``` 
> 
> This has been confirmed as a bug, and the report can be seen here 
> .
> 
> After a Twitter conversation with Joe Groff on the Swift team 
> (https://twitter.com/jckarter/status/707287663586324481) it is determined 
> that this requirement is due to difficulty disambiguating generics `Foo` 
> vs infix less-than operations `Foo < T`.
> 
> I propose to allow Types to be used in expressions without needing to 
> explicitly reference `.self`. The motivation for this is as follows:
> 
> - Cleaner API
> - Consistent requirement is less confusing to developers
> - Disambiguation challenges should not result in more verbose code unless 
> absolutely necessary
> 
> Here are some preliminary ideas for how this could be implemented:
> 
> - Require spaces around less than expressions and no spaces around generics
> - Require spaces around infix operators and no spaces around generics
> - Remove less than overload for comparing a type
> - (Your idea here)
> 
> A draft of an evolution document that provides more background can be viewed 
> here . It has been 
> preempted by a need for discussion in this mailing list. 
> 
> I am looking forward to hearing your feedback on this proposal.
> 
> Thank you,
> Tanner Nelson
> http://github.com/tannernelson
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[T.J. Usiyan via swift-evolution]

+1
I have wanted this since the first beta. I hadn't proposed because I
haven't come up with a nice syntax to do this in functions/methods. I don't
particularly like
func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

and the closes that I have come is to simply reuse the closure syntax with

func takesATuple(someInt: Int, tuple: (String, String)) {
(someInt, (valueA,
valueB)) in

but that gets confusing in my opinion, specifically if you choose to have
different names inside and outside.



On Thu, May 5, 2016 at 11:22 AM, Dennis Weissmann via swift-evolution <
swift-evolution@swift.org> wrote:

> Following a short discussion with positive feedback on [swift-users](
> http://thread.gmane.org/gmane.comp.lang.swift.user/1812) I’d like to
> discuss the following:
>
> Tuples should be destructible into their components in parameter lists.
>
> Consider the following code:
>
> let a = [0,1,2,3,4,5,6,7,8,9]
> let b = [0,1,2,3,4,5,6,7,8,9]
>
> let c = zip(a,b).reduce(0) { acc, tuple in
>   acc + tuple.0 + tuple.1
> }
>
> tuple is of type (Int, Int).
>
> The problem is that the calculation is not very comprehensible due to .0
> and .1. That’s when destructuring tuples directly in the parameter list
> comes into play:
>
> let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
>   acc + valueA + valueB
> }
>
> The above is what I propose should be accepted by the compiler (but
> currently isn’t).
>
> Currently tuple destructuring is possible like this:
>
> let c = zip(a,b).reduce(0) { (acc, tuple) in
>   let (valueA, valueB) = tuple
>   return acc + valueA + valueB
> }
>
> This is not about saving one line ;-). I just find it much more intuitive
> to destructure the tuple in the parameter list itself.
>
> The same thing could be done for functions:
>
> func takesATuple(someInt: Int, tuple: (String, String))
>
> Here we also need to destructure the tuple inside the function, but the
> intuitive place (at least for me) to do this would be the parameter list.
>
> In the following example I'm making use of Swift’s feature to name
> parameters different from their labels (for internal use inside the
> function, this is not visible to consumers of the API):
>
> func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))
>
> Here valueA and valueB would be directly usable within the function. The
> tuple as a whole would not be available anymore.
>
>
> Now it’s your turn!
>
> 1. What do you think?
> 2. Is this worth being discussed now (i.e. is it implementable in the
> Swift 3 timeframe) or should I delay it?
>
> Cheers,
>
> - Dennis
>
> ___
> 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] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 10:02 PM, Dave Abrahams  wrote:
> 
> 
> on Thu May 05 2016, Matthew Johnson  > wrote:
> 
>>On May 5, 2016, at 4:59 PM, Dave Abrahams  wrote:
>> 
>>on Wed May 04 2016, Matthew Johnson  wrote:
>> 
>>On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Wed May 04 2016, Matthew Johnson  wrote:
>> 
>>On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Wed May 04 2016, Adrian Zubarev 
>>wrote:
>> 
>>Not sure what to think about the enum cases inside a
>>protocol (if AnyEnum would
>>even exist), it could be a nice addition to the language, but
>>this is an own
>>proposal I guess.
>> 
>>We should start by adding AnyValue protocol to which all value
>>types
>>conforms.
>> 
>>Having a way to constrain conformance to things with value semantics
>>is
>>something I've long wanted. *However*, the approach described is too
>>simplistic. It's possible to build classes whose instances have
>>value
>>semantics (just make them immutable) and it's possible to build
>>structs
>>whose instances have reference semantics (just put the struct's
>>storage
>>in a mutable class instance that it holds as a property, and don't
>>do
>>copy-on-write). 
>> 
>>In order for something like AnyValue to have meaning, we need to
>>impose
>>greater order. After thinking through many approaches over the
>>years, I
>>have arrived at the (admittedly rather drastic) opinion that the
>>language should effectively outlaw the creation of structs and enums
>>that don't have value semantics. (I have no problem with the idea
>>that
>>immutable classes that want to act as values should be wrapped in a
>>struct). The language could then do lots of things much more
>>intelligently, such as correctly generating implementations of
>>equality.
>> 
>>That is a drastic solution indeed! How would this impact things like
>>Array? While Array itself has value semantics, the aggregate
>>obviously does not as it contains references which usually be mutated
>>underneath us. 
>> 
>>Value semantics and mutation can only be measured with respect to
>>equality. The definition of == for all class types would be equivalent
>>to ===. Problem solved.
>> 
>>Similar considerations apply to simpler wrapper structs such as Weak.
>> 
>>Same answer.
>> 
>>Hmm. If those qualify as “value semantic” then what kind of structs 
>> and
>>enums
>>would not? A struct wrapping a mutable reference type certainly 
>> doesn’t
>>“feel”
>>value semantic to me and certainly doesn’t have the guarantees usually
>>associated with value semantics (won’t mutate behind your back, thread
>>safe,
>>etc).
>> 
>>Sure it does.
>> 
>>public struct Wrap : Equatable {
>>init(_ x: T) { self.x = x }
>>private x: T
>>}
>> 
>>func == (lhs: Wrap, rhs: Wrap) -> Bool {
>>return lhs.x === rhs.x
>>}
>> 
>>I defy you to find any scenario where Wrap doesn't have value
>>semantics, whether T is mutable or not.
>> 
>>Alternately, you can look at the Array implementation. Array is a
>>struct wrapping a mutable class. It has value semantics by virtue of
>>CoW.
>> 
>> This goes back to where you draw the line as to the “boundary of the value”.
>> Wrap and Array are “value semantic” in a shallow sense and are capable of 
>> deep
>> value semantics when T is deeply value semantic. 
> 
> No, I'm sorry; this “deep-vs-shallow” thing is a fallacy that comes from
> not understanding the boundaries of your value.  Or, put more
> solicitously: sure, you can look at the world that way, but it just
> makes everything prohibitively complicated, so why would you want to?
> 
> In my world, there's no such thing as a “deep copy” or a “shallow copy;”
> there's just “copy,” which logically creates an independent version of
> everything up to the boundaries of the value.  Likewise, there's no
> “deep value semantics” or “shallow value semantics.”  
> Equality defines
> value semantics, and the boundaries of an Array value always includes
> the values of its elements.  The *only* problem here is that we have no
> way to do equality comparison on some arrays because some types aren't
> Equatable.  IMO the costs of not having everything be equatable, in
> complexity-of-programming-model terms, are too high.

Thank you for clarifying the terminology for me.  This is helpful.  

I think I may have misunderstood what you meant by “boundary of the value”.  Do 
you mean that the boundary of an Array value stops at the reference identity 
for 

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Patrick Smith via swift-evolution]

Or new AnySequence constructors? So the sequence can be generated more than
once.

  

let a = AnySequence(from: 1){ $0 * 2 }.prefix(10)  
print(Array(a)) // [1, 2, 4, 8, 16, 32, 64, 128, 256, 512]  
  
let b = AnySequence(from: 10){ $0 == 0 ? nil : $0 - 1 }  
print(Array(b)) // [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]  

  

  

Code as implemented in Swift 2.2:

  

extension AnySequence {  
 init(from: Element, applying: (Element) -> Element) {  
   self.init({ () -> AnyGenerator in  
 var current: Element?  
 return AnyGenerator{  
   current = current.map(applying) ?? from  
   return current  
 }  
   })  
 }  
  
 init(from: Element, applying: (Element) -> Element?) {  
   self.init({ () -> AnyGenerator in  
 var current: Element?  
 return AnyGenerator{  
   current = current.map(applying) ?? from  
   return current  
 }  
   })  
 }  
}  

  

  
**Patrick Smith**  

On May 6 2016, at 7:27 am, Brent Royal-Gordon via swift-evolution  wrote:  

> > One idea that came out of the core team discussion was something like:  
>  
> sequence(from: 0) { $0 += 42 }  
>  
> Since it returns a sequence.

>

> It definitely occurred to me that this was kind of just a way to construct a
generic iterator. Maybe a new AnyIterator (I believe there is such a thing)
constructor?

>

> \--  
Brent Royal-Gordon  
Sent from my iPhone  
___  
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] multi-line string literals.

[Ricardo Parada via swift-evolution]

I think that is another one of the advantages of using the continuation quotes. 

Sent from my iPhone

> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
>   
> I think it's nice that I can look at any line—out of context, random 
> access—and see which parts are string literals.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Jordan Rose via swift-evolution]

> On May 5, 2016, at 16:32, Joe Pamer  wrote:
> 
> 
>> On May 2, 2016, at 9:09 AM, Jordan Rose > > wrote:
>> 
>> It’s not the keys that are the problem; it’s the values. String and Array 
>> are not AnyObjects. Today they get an implicit conversion because they are 
>> known-bridgeable.
> 
> Hey Jordan,
> 
> I share your concern, though I’ve spent my day combing through whatever large 
> codebases I could get my hands on, and I’ve encountered very few “plist 
> literals” where removing implicit bridging conversions would be a problem.
> 
> Specifically, quickly analyzing 710 swift code bases (a sampling of GitHub 
> projects, plus others I have access to), I encountered 1785 Dictionary values 
> with an AnyObject key. Of those, only 15 appear to make use of implicit 
> bridging conversions when initializing or assigning to the value.
> 
> Since the impact appears to be relatively limited, I think the consistency 
> we’ll gain from this change will make it worthwhile.

Good to know. If it’s relatively rare (both in how much it comes up and how 
much that code is written) then the few extra explicit coercions won’t be an 
undue burden. Thanks for looking into this, Joe!

Jordan

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

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

[Matthew Johnson via swift-evolution]

> * What is your evaluation of the proposal?

+1.  I like semantic guarantees provided by the compiler.

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

Not that I can think of.

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

I participated in the earlier threads, read the proposal thoroughly, and have 
followed the review closely.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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-0080: Failable Numeric Conversion Initializers

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 6:22 PM, Max Moiseev  wrote:
> 
> Hi Matthew,
> 
> In general, if you think there is something to be updated in the proposal, it 
> is worth creating a new revision (like in the floating point protocols 
> proposal, for example) and mentioning it in the thread.
> 
> I think it is a way to go in this particular case, since we are still in the 
> first half of the review period. Any further discussion would benefit from it.

t made the change and submitted a PR.

> 
> max
> 
> 
>> On May 5, 2016, at 4:02 PM, Matthew Johnson > > wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> Hi all,
>>> 
>>> This email is the result of a discussion between members of the standard 
>>> library team.
>>> 
>>> We suggest changing the initializers argument label to `exactly` to match 
>>> the one used in the floating point protocols proposal 
>>> .
>>>  Other than that the proposal seems to be a valuable addition to the 
>>> standard library.
>> 
>> Thanks Max.  I'm glad to hear that!  Should I update the proposal or will 
>> you just make that change as part of "accepted with modification"?
>> 
>>> 
>>> max
>>> 
 On May 3, 2016, at 8:57 PM, Chris Lattner >>> > wrote:
 
 Hello Swift community,
 
 The review of "SE-0080: Failable Numeric Conversion Initializers" begins 
 now and runs through May 9. The proposal is available here:
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
  
 
 
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at
 
https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 
 or, if you would like to keep your feedback private, directly to the 
 review manager.
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and contribute to the direction of Swift. 
 When writing your review, here are some questions you might want to answer 
 in your review:
 
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
 to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, 
 how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
 
 More information about the Swift evolution process is available at
 
https://github.com/apple/swift-evolution/blob/master/process.md 
 
 
 Thank you,
 
 -Chris Lattner
 Review Manager
 
 ___
 swift-evolution-announce mailing list
 swift-evolution-annou...@swift.org 
 
 https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
 
>>> 
>>> ___
>>> 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] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Thu May 05 2016, Matthew Johnson  wrote:

> On May 5, 2016, at 4:59 PM, Dave Abrahams  wrote:
>
> on Wed May 04 2016, Matthew Johnson  wrote:
>
> On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed May 04 2016, Matthew Johnson  wrote:
>
> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed May 04 2016, Adrian Zubarev 
> wrote:
>
> Not sure what to think about the enum cases inside a
> protocol (if AnyEnum would
> even exist), it could be a nice addition to the language, but
> this is an own
> proposal I guess.
>
> We should start by adding AnyValue protocol to which all value
> types
> conforms.
>
> Having a way to constrain conformance to things with value semantics
> is
> something I've long wanted. *However*, the approach described is too
> simplistic. It's possible to build classes whose instances have
> value
> semantics (just make them immutable) and it's possible to build
> structs
> whose instances have reference semantics (just put the struct's
> storage
> in a mutable class instance that it holds as a property, and don't
> do
> copy-on-write). 
>
> In order for something like AnyValue to have meaning, we need to
> impose
> greater order. After thinking through many approaches over the
> years, I
> have arrived at the (admittedly rather drastic) opinion that the
> language should effectively outlaw the creation of structs and enums
> that don't have value semantics. (I have no problem with the idea
> that
> immutable classes that want to act as values should be wrapped in a
> struct). The language could then do lots of things much more
> intelligently, such as correctly generating implementations of
> equality.
>
> That is a drastic solution indeed! How would this impact things like
> Array? While Array itself has value semantics, the aggregate
> obviously does not as it contains references which usually be mutated
> underneath us. 
>
> Value semantics and mutation can only be measured with respect to
> equality. The definition of == for all class types would be equivalent
> to ===. Problem solved.
>
> Similar considerations apply to simpler wrapper structs such as Weak.
>
> Same answer.
>
> Hmm. If those qualify as “value semantic” then what kind of structs 
> and
> enums
> would not? A struct wrapping a mutable reference type certainly 
> doesn’t
> “feel”
> value semantic to me and certainly doesn’t have the guarantees usually
> associated with value semantics (won’t mutate behind your back, thread
> safe,
> etc).
>
> Sure it does.
>
> public struct Wrap : Equatable {
> init(_ x: T) { self.x = x }
> private x: T
> }
>
> func == (lhs: Wrap, rhs: Wrap) -> Bool {
> return lhs.x === rhs.x
> }
>
> I defy you to find any scenario where Wrap doesn't have value
> semantics, whether T is mutable or not.
>
> Alternately, you can look at the Array implementation. Array is a
> struct wrapping a mutable class. It has value semantics by virtue of
> CoW.
>
> This goes back to where you draw the line as to the “boundary of the value”.
> Wrap and Array are “value semantic” in a shallow sense and are capable of deep
> value semantics when T is deeply value semantic. 

No, I'm sorry; this “deep-vs-shallow” thing is a fallacy that comes from
not understanding the boundaries of your value.  Or, put more
solicitously: sure, you can look at the world that way, but it just
makes everything prohibitively complicated, so why would you want to?

In my world, there's no such thing as a “deep copy” or a “shallow copy;”
there's just “copy,” which logically creates an independent version of
everything up to the boundaries of the value.  Likewise, there's no
“deep value semantics” or “shallow value semantics.”  Equality defines
value semantics, and the boundaries of an Array value always includes
the values of its elements.  The *only* problem here is that we have no
way to do equality comparison on some arrays because some types aren't
Equatable.  IMO the costs of not having everything be equatable, in
complexity-of-programming-model terms, are too high.

> Both have their place, but the maximum benefit of value semantics
> (purity) 

I don't know what definition of purity you're using.  The only one I
know of applies to functions and implies no side effects.  In that
world, there is no mutation and value semantics is equivalent to
reference semantics.

> is derived from deep value semantics. This is when there is no
> possibility of shared mutable state. This is

Re: [swift-evolution] Case conventions for mixed-case words (like

[Jordan Rose via swift-evolution]

> On May 5, 2016, at 15:54, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Thu, May 5, 2016 at 5:31 PM, Haravikk via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> NaN is really a problem only because of using it as an acronym rather than 
> just having .invalidNumber or .notANumber (little uglier) or something 
> similar instead. This comes back to the annoying consideration between 
> something being prior art, at the cost of potentially defining something 
> that’s better, or a better fit for the language. If NaN didn’t exist 
> elsewhere, would we even consider it at all if we were implementing float 
> point numbers for the first ever time in Swift? I’d prefer we defined 
> something more verbose as an alternative to avoid the acronym entirely.
> 
> When it comes to having iPad conformance the question is; should we ever 
> actually test for names at all? An iPad is a brand, it’s not really something 
> that a program should test for, as what’s important to a program are 
> capabilities. The same is true with testing for an OS, we don’t want to test 
> Windows, Mac etc., but rather to test what libraries are available. Same is 
> true with hardware; it doesn’t matter if a device is an iPad, what matters is 
> that it has a touch-screen rather than a keyboard, that it has a small screen 
> rather than a full monitor, that it’s mobile (and not plugged in) etc.
> Testing for names like that should be avoided at all costs when it comes to 
> variable and method names, and be relegated to string-based tests for when 
> you absolutely have to access that information. In other words programs 
> should be platform agnostic, and only need to know whether capabilities they 
> require or optionally support exist or not.
> For these I’d prefer that the guidelines warn against these in the strongest 
> possible terms, as they’re usually a bad idea IMO.
> 
> Whether using the word iPad is wise or not, the question still remains what 
> to do when encountering a term that looks like that. If I'm writing an app 
> that deals with chemical compounds, how should I name a type that deals with 
> pH? How about a computed property representing pH? Should either or both be 
> PH, pH, or ph? It certainly will not do to say "just name it powerOfHydrogen”.

Right, stating that you don’t like these particular examples or terms of art 
doesn’t change the need for a proper convention. There will be cases where a 
term of art is the right thing to use, and that term happens to be 
conventionally spelled with mixed case. The point of naming guidelines is to 
provide an answer when the situation does arise; right now they’re ambiguous.

Jordan

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

Re: [swift-evolution] multi-line string literals.

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 5 May 2016, at 14:17, David Hart >> > wrote:
>>> 
>>> 
 On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 it's not a secret that I'm not a big fan of the proposal. The third draft 
 doesn't change this and it's unlikely that any future draft will, because 
 for me, the problem are the continuation quotes, and for Brent it seems 
 like they are a must-have-feature (correct me if I'm wrong.)
>>> 
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>>> proposal simply because of the existence of continuation quotes, no matter 
>>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>>> and unfriendly to modification.
>>> 
>>> I could see either your proposal, or your proposal without the HERE_DOCs 
>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
>>> formal proposal?
>> 
>> 
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>> 
>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>> indented.
>> As suggested earlier in this thread the lexer can strip the margin on the 
>> basis of
>> the whitespace before the closing quote as per Perl6 (This could be a 
>> modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>> 
>> assert( xml == i"""
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
>> 
>> Other modifiers can also be applied such as “no-escapes"
>> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> """ )
>> 
>> I’d hope this would satisfy any need for <> 
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
>> 
>> 
>> John
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m of the opinion that either of these are reasonable solutions, and both 
> offer different tradeoffs. I’m probably partial to the continuation quotes, 
> because I don’t want to be guessing about what is going to end up being in my 
> string and what won’t.  
> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
> 
> For example, is there a new line after ?
> How would the indenting work if it were immediately followed by triple 
> quotes: ”””
> I would really like the first line to be lined up with the rest of the xml. 
> Is that going to introduce a newline into the top of the string?
> 
> Could we just enforce that no characters on the lines of the triple quotes 
> would be included in the string, very much like the heredoc syntax?
> 
> assert( xml != ei"”” The text I’m typing here would cause a compiler 
> error.
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> same here   ""” )
> 
> Then it’s very clear what the whitespace stripping will do. But what about 
> mixed tab vs whitespace? What is the behavior in that case?


I’m jumping into this thread late and have only followed bits of it so I 
apologize if I’m repeating anything.

I really like the idea of having leading space stripped automatically without 
requiring the continuation quotes.  I have done my share of leading space 
stripping in the past when working with heredocs.  It’s not that big a deal but 
it would be better to have the language take care of it for us.

I like the i

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 4:59 PM, Dave Abrahams  wrote:
> 
> 
> on Wed May 04 2016, Matthew Johnson  > wrote:
> 
>>On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Wed May 04 2016, Matthew Johnson  wrote:
>> 
>>On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution
>> wrote:
>> 
>>on Wed May 04 2016, Adrian Zubarev 
>>wrote:
>> 
>>Not sure what to think about the enum cases inside a
>>protocol (if AnyEnum would
>>even exist), it could be a nice addition to the language, but
>>this is an own
>>proposal I guess.
>> 
>>We should start by adding AnyValue protocol to which all value
>>types
>>conforms.
>> 
>>Having a way to constrain conformance to things with value 
>> semantics
>>is
>>something I've long wanted. *However*, the approach described is 
>> too
>>simplistic. It's possible to build classes whose instances have
>>value
>>semantics (just make them immutable) and it's possible to build
>>structs
>>whose instances have reference semantics (just put the struct's
>>storage
>>in a mutable class instance that it holds as a property, and don't
>>do
>>copy-on-write). 
>> 
>>In order for something like AnyValue to have meaning, we need to
>>impose
>>greater order. After thinking through many approaches over the
>>years, I
>>have arrived at the (admittedly rather drastic) opinion that the
>>language should effectively outlaw the creation of structs and 
>> enums
>>that don't have value semantics. (I have no problem with the idea
>>that
>>immutable classes that want to act as values should be wrapped in 
>> a
>>struct). The language could then do lots of things much more
>>intelligently, such as correctly generating implementations of
>>equality.
>> 
>>That is a drastic solution indeed! How would this impact things like
>>Array? While Array itself has value semantics, the aggregate
>>obviously does not as it contains references which usually be mutated
>>underneath us. 
>> 
>>Value semantics and mutation can only be measured with respect to
>>equality. The definition of == for all class types would be equivalent
>>to ===. Problem solved.
>> 
>>Similar considerations apply to simpler wrapper structs such as Weak.
>> 
>>Same answer.
>> 
>> Hmm. If those qualify as “value semantic” then what kind of structs and enums
>> would not? A struct wrapping a mutable reference type certainly doesn’t 
>> “feel”
>> value semantic to me and certainly doesn’t have the guarantees usually
>> associated with value semantics (won’t mutate behind your back, thread safe,
>> etc).
> 
> Sure it does.
> 
> public struct Wrap : Equatable {
>   init(_ x: T) { self.x = x }
>   private x: T
> }
> 
> func == (lhs: Wrap, rhs: Wrap) -> Bool {
>   return lhs.x === rhs.x
> }
> 
> I defy you to find any scenario where Wrap doesn't have value
> semantics, whether T is mutable or not.
> 
> Alternately, you can look at the Array implementation.  Array is a
> struct wrapping a mutable class.  It has value semantics by virtue of
> CoW.

This goes back to where you draw the line as to the “boundary of the value”.  
Wrap and Array are “value semantic” in a shallow sense and are capable of deep 
value semantics when T is deeply value semantic.  Both have their place, but 
the maximum benefit of value semantics (purity) is derived from deep value 
semantics.  This is when there is no possibility of shared mutable state.  This 
is an extremely important property.


let t = MyClass()
foo.acceptWrapped(Wrap(t))
t.mutate()

In this example, foo had better not depend on the wrapped instance not getting 
mutated.

> 
>>My expectation is a generic aggregate such as Array would have to
>>conditionally conform to AnyValue only when Element also conforms to
>>AnyValue.
>> 
>>I’m also wondering how such a rule would be implemented while still
>>allowing for CoW structs that *do* implement value semantics, but do
>>so while using references internally.
>> 
>>I am not talking about any kind of statically-enforceable rule, although
>>we could probably make warnings sophisticated enough to help with this.
>> 
>> You said the you have arrived at the opinion that the language should
>> “effectively outlaw” structs and enums that do not have value semantics. That
>> sounded like static enforcement to me. 
> 
> The language outlaws certain kinds of inout aliasing without providing static
> e

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, Erica Sadun  wrote:

> Having to figure out where a previously defaulted value should be inserted 
> when
> adding an explicit setting imposes an undue burden on the programmer, reduces
> flexibility during experimentation, and removes one of the neatest Swift
> features. For this reason, I vote no on the proposal. By rejecting this
> proposal, Swift retains a flexibility that defers to the programmer, placing 
> the
> programmer's needs before any benefits that may accrue to the compiler.
>
> I have followed the discussion. I believe it goes against the general Swift
> philosophy. And while the change being proposed is significant to be part of a
> formal language review process, I think adopting it would be the wrong thing 
> to
> do.
>
> -- Erica

FWIW, Erica echoes my instincts on the topic.

-- 
Dave

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[David Sweeris via swift-evolution]

> On May 5, 2016, at 6:55 PM, Dave Abrahams  wrote:
> 
> 
> on Thu May 05 2016, David Sweeris  wrote:
> 
>> I meant leave `struct` and `enum` the way they are, and introduce a
>> `different_struct` and `different_enum` (placeholder names, of course)
>> which enforced the “no reference-semantics” rules.
> 
> I would be pretty strongly opposed to that.  That's almost the opposite
> of what I'm proposing.
> 
>> I’m inclined to think we should adopt your “no reference-semantics”
>> rule, but I’m not entirely sure what the impact would be. Adding new
>> types side-steps the issue, at the cost of increasing the complexity
>> of the language/compiler. I’m unsure if that'd be a worth-while
>> trade-off.
> 
> The whole point of my proposal is to simplify the model.
Oh, ok… I think I got your ends and your means backwards in my head.

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

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 6:27 PM, Tyler Cloutier via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On 5 May 2016, at 14:17, David Hart >> > wrote:
>>> 
>>> 
 On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 it's not a secret that I'm not a big fan of the proposal. The third draft 
 doesn't change this and it's unlikely that any future draft will, because 
 for me, the problem are the continuation quotes, and for Brent it seems 
 like they are a must-have-feature (correct me if I'm wrong.)
>>> 
>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>>> proposal simply because of the existence of continuation quotes, no matter 
>>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>>> and unfriendly to modification.
>>> 
>>> I could see either your proposal, or your proposal without the HERE_DOCs 
>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a 
>>> formal proposal?
>> 
>> 
>> Adapting the original proposal if you’re not a fan of continuation quotes..
>> 
>> It’s possible to have a multiline “””python””” multi-line string but tidily 
>> indented.
>> As suggested earlier in this thread the lexer can strip the margin on the 
>> basis of
>> the whitespace before the closing quote as per Perl6 (This could be a 
>> modifier “I”
>> but might as well be the default TBH.) Would this be the best of both worlds?
>> 
>> assert( xml == i"""
>> 
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
>> 
>> Other modifiers can also be applied such as “no-escapes"
>> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> """ )
>> 
>> I’d hope this would satisfy any need for <> 
>> Or you could support both continuation and indented python style:
>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
>> 
>> 
>> John
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I’m of the opinion that either of these are reasonable solutions, and both 
> offer different tradeoffs. I’m probably partial to the continuation quotes, 
> because I don’t want to be guessing about what is going to end up being in my 
> string and what won’t.  
> 
>> assert( xml != ei"""
>> 
>>
>>\(author)
>>XML Developer's Guide
>>Computer
>>44.95
>>2000-10-01
>>An in-depth look at creating applications 
>> with XML.
>>
>> 
>> ""” )
> 
> For example, is there a new line after ?
> How would the indenting work if it were immediately followed by triple 
> quotes: ”””
> I would really like the first line to be lined up with the rest of the xml. 
> Is that going to introduce a newline into the top of the string?
> 
> Could we just enforce that no characters on the lines of the triple quotes 
> would be included in the string, very much like the heredoc syntax?
> 
> assert( xml != ei"”” The text I’m typing here would cause a compiler 
> error.
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> same here   ""” )
> 
> Then it’s very clear what the whitespace stripping will do. But what about 
> mixed tab vs whitespace? What is the behavior in that case?
> 
> Tyler
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Then you could even, if you were so daring, put the string modifiers in the 
string as compiler directives.

assert( xml != 
“”” #escaped #marginStripped 


   
   \(autho

Re: [swift-evolution] multi-line string literals.

[Tyler Cloutier via swift-evolution]

> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution 
>  wrote:
> 
> 
>> On 5 May 2016, at 14:17, David Hart > > wrote:
>> 
>> 
>>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>>> doesn't change this and it's unlikely that any future draft will, because 
>>> for me, the problem are the continuation quotes, and for Brent it seems 
>>> like they are a must-have-feature (correct me if I'm wrong.)
>> 
>> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
>> proposal simply because of the existence of continuation quotes, no matter 
>> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
>> and unfriendly to modification.
>> 
>> I could see either your proposal, or your proposal without the HERE_DOCs but 
>> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
>> proposal?
> 
> 
> Adapting the original proposal if you’re not a fan of continuation quotes..
> 
> It’s possible to have a multiline “””python””” multi-line string but tidily 
> indented.
> As suggested earlier in this thread the lexer can strip the margin on the 
> basis of
> the whitespace before the closing quote as per Perl6 (This could be a 
> modifier “I”
> but might as well be the default TBH.) Would this be the best of both worlds?
> 
> assert( xml == i"""
> 
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> ""” )
> 
> Other modifiers can also be applied such as “no-escapes"
> 
> assert( xml != ei"""
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> """ )
> 
> I’d hope this would satisfy any need for < 
> Or you could support both continuation and indented python style:
> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz 
> 
> 
> John
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I’m of the opinion that either of these are reasonable solutions, and both 
offer different tradeoffs. I’m probably partial to the continuation quotes, 
because I don’t want to be guessing about what is going to end up being in my 
string and what won’t.  

> assert( xml != ei"""
> 
>
>\(author)
>XML Developer's Guide
>Computer
>44.95
>2000-10-01
>An in-depth look at creating applications 
> with XML.
>
> 
> ""” )

For example, is there a new line after ?
How would the indenting work if it were immediately followed by triple quotes: 
”””
I would really like the first line to be lined up with the rest of the xml. Is 
that going to introduce a newline into the top of the string?

Could we just enforce that no characters on the lines of the triple quotes 
would be included in the string, very much like the heredoc syntax?

assert( xml != ei"”” The text I’m typing here would cause a compiler 
error.


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

same here   ""” )

Then it’s very clear what the whitespace stripping will do. But what about 
mixed tab vs whitespace? What is the behavior in that case?

Tyler

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

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

[Nate Cook via swift-evolution]

Thanks for the feedback, Dmitri &co, this all looks excellent! I'll work on 
updating the proposal.

> On May 5, 2016, at 6:13 PM, Dmitri Gribenko  wrote:
> 
> On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution
>  wrote:
>> Hello Swift community,
>> 
>> The review of "SE-0078: Implement a rotate algorithm, equivalent to 
>> std::rotate() in C++" begins now and runs through May 9.
> 
> Hi,
> 
> I'm posting this feedback on behalf of Dave Abrahams, Max Moiseev and
> myself.  We met and discussed the proposal in great detail.
> 
> First of all, we want to thank Nate and Sergey for proposing this API,
> which is an important and useful algorithm.  We are generally in favor
> of the proposal, but we would like to request a few changes.
> 
> Could you make 'func rotate' a requirement in the MutableCollection
> protocol?  This allows selecting the best implementation for a given
> concrete type, even when calling from generic code.
> 
> Could you explain why do we need a special implementation of
> 'reverse()' for RandomAccessCollection?  We couldn't think of a
> performance reason for this.

With a bidirectional collection, you have to compare the high and low index at 
each iteration, stopping when low >= high (before indices were Comparable, this 
required two equality comparisons per iteration). With a random-access 
collection, you can optimize the loop to use a fixed number of iterations, 
which should be more efficient.

> Could you add complexity clauses to all new documentation comments?
> 
> We have discussed the names for these functions at length.  We felt
> like the argument in 'rotate(firstFrom:)' does not convey the
> argument's role well.  Our suggestion is to use
> 'rotate(shiftingToStart:)' and 'rotated(shiftingToStart:)'.  These
> names emphasize that methods operate on the whole collection, shifting
> all elements.  The argument is the index of the element that is moved
> to the start index, and we tried to convey that by using the word
> 'start' instead of 'first'.  In the standard library, 'first' refers
> to the element itself, not the index.  Indices use 'startIndex' and
> 'endIndex'.
> 
> We have considered a lot of alternative names, including
> 'swapSubranges(boundedBy:)', 'rewind', 'splitAndSwap', 'swapHalves'
> and others, but they were not as good.  The problems are:
> 
> - 'swapSubranges' is mostly good, but 'subranges' does not imply that
> the two subranges cover the whole collection.  The user might
> reasonably expect to pass two subranges that will be swapped.
> 
> - 'Half' implies that two parts make a whole, but it also implies that
> two parts are of equal size, which is not the case for this API.
> 
> - 'splitAndSwap' implies that we are operating on the whole, but feels
> a very roundabout way to describe the operation.

Agreed on all of this. The rotate name is hard to beat!

> For a non-mutating rotation we suggest defining separate types,
> RotatedCollection, RotatedBidirectionalCollection, and
> RotatedRandomAccessCollection, instead of returning a
> FlattenCollection.  This has a few advantages.
> 
> - We can change the non-mutating 'rotated()' to just return the
> collection instead of returning tuples of the collection and the
> index.  The index of the former first element can be stored inside the
> RotatedCollection in a property.  This change allows easier chaining
> on '.rotated()', and goes in line with the return value of the
> mutating 'rotate()' being discardable.
> 
> - Using an array in the return type of 'rotated()'
> (FlattenCollection<[Self.SubSequence]>) would be less efficient than
> it could be (extra allocation), and also feels like exposing too many
> implementation details that we might want to change in future (for
> example, if we get a CollectionOfTwo type).
> 
> - In future, when we have conditional protocol conformances in the
> language, we would fold the three RotatedCollection types into one
> type that conditionally conforms to collection protocols based on the
> capabilities of the underlying collection.  We won't be able to do
> that if some overloads return a FlattenCollection.
> 
> For lazy 'rotated()', just like for non-mutating 'rotated()', we
> recommend returning only one value, a LazyCollection that wraps an
> appropriate RotatedCollection.  The RotatedCollection will store the
> index of the former first element in a property.
> 
> 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

Re: [swift-evolution] multi-line string literals.

[John Holdsworth via swift-evolution]

> On 5 May 2016, at 14:17, David Hart  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?


Adapting the original proposal if you’re not a fan of continuation quotes..

It’s possible to have a multiline “””python””” multi-line string but tidily 
indented.
As suggested earlier in this thread the lexer can strip the margin on the basis 
of
the whitespace before the closing quote as per Perl6 (This could be a modifier 
“I”
but might as well be the default TBH.) Would this be the best of both worlds?

assert( xml == i"""


   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""” )

Other modifiers can also be applied such as “no-escapes"

assert( xml != ei"""

   
   \(author)
   XML Developer's Guide
   Computer
   44.95
   2000-10-01
   An in-depth look at creating applications with 
XML.
   

""" )

I’d hope this would satisfy any need for 

John

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Thu May 05 2016, David Sweeris  wrote:

>> On May 5, 2016, at 5:01 PM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed May 04 2016, David Sweeris  wrote:
>> 
>
 On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution 
  wrote:
 
 In order for something like AnyValue to have meaning, we need to impose
 greater order.  After thinking through many approaches over the years, I
 have arrived at the (admittedly rather drastic) opinion that the
 language should effectively outlaw the creation of structs and enums
 that don't have value semantics.  (I have no problem with the idea that
 immutable classes that want to act as values should be wrapped in a
 struct).  The language could then do lots of things much more
 intelligently, such as correctly generating implementations of
 equality. 
>>> 
>>> You mean that a struct's properties would have to have value
>>> semantics, too? 
>> 
>> Either that, or you'd have to implement CoW, or you'd not use the
>> storage behind any properties that were references in a way that affects
>> value semantics.
>> 
>>> I think I'm okay with that, especially if it's done through new types
>>> of structs/enums.
>> 
>> New types of structs/enums?  What does that mean?
> I meant leave `struct` and `enum` the way they are, and introduce a
> `different_struct` and `different_enum` (placeholder names, of course)
> which enforced the “no reference-semantics” rules.

I would be pretty strongly opposed to that.  That's almost the opposite
of what I'm proposing.

> I’m inclined to think we should adopt your “no reference-semantics”
> rule, but I’m not entirely sure what the impact would be. Adding new
> types side-steps the issue, at the cost of increasing the complexity
> of the language/compiler. I’m unsure if that'd be a worth-while
> trade-off.

The whole point of my proposal is to simplify the model.

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

Re: [swift-evolution] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

[Joe Pamer via swift-evolution]

> On May 2, 2016, at 9:09 AM, Jordan Rose  wrote:
> 
> It’s not the keys that are the problem; it’s the values. String and Array are 
> not AnyObjects. Today they get an implicit conversion because they are 
> known-bridgeable.

Hey Jordan,

I share your concern, though I’ve spent my day combing through whatever large 
codebases I could get my hands on, and I’ve encountered very few “plist 
literals” where removing implicit bridging conversions would be a problem.

Specifically, quickly analyzing 710 swift code bases (a sampling of GitHub 
projects, plus others I have access to), I encountered 1785 Dictionary values 
with an AnyObject key. Of those, only 15 appear to make use of implicit 
bridging conversions when initializing or assigning to the value.

Since the impact appears to be relatively limited, I think the consistency 
we’ll gain from this change will make it worthwhile.

Thanks,
- Joe

> 
> Jordan
> 
>> On Apr 30, 2016, at 12:44, Jean-Daniel Dupas > > wrote:
>> 
>> Is this is a plist like construct, couldn’t it simply be declared as 
>> [NSString: AnyObject] ? As we are talking about removing implicit cast, 
>> forcing the user to use NSString explicitly for API that need a NSDictionary 
>> is probably not a problem ?
>> 
>> 
>> let userInfo: [NSString: AnyObject] = [
>>  kSomeStandardKey: self.name, // a String
>>  kAnotherKey: self.childNames // an Array of Strings
>> ]
>> NSNotificationCenter.default().postNotificationName(MyNotification, self, 
>> userInfo)
>> 
>> 
>>> Le 30 avr. 2016 à 02:32, Jordan Rose via swift-evolution 
>>> mailto:swift-evolution@swift.org>> a écrit :
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md]
>>>  
>>> 
>>> 
>>> I’m a little concerned about the affect this has on “plist literals”. 
>>> Specifically, I can no longer construct a dictionary like this:
>>> 
>>> let userInfo: [String: AnyObject] = [
>>> kSomeStandardKey: self.name, // a String
>>> kAnotherKey: self.childNames // an Array of Strings
>>> ]
>>> NSNotificationCenter.default().postNotificationName(MyNotification, self, 
>>> userInfo)
>>> 
>>> The fix isn’t that hard—just add “as NSString” or “as NSArray”—but it is a 
>>> bit of extra noise that we currently don’t have. If the type checker can 
>>> still offer that fix-it, then I’m not sure we’d actually get any compiler 
>>> simplification out of it…although I suppose it might make the happy path 
>>> faster.
>>> 
>>> The CFString issue Jacob brought up is also a little unfortunate, although 
>>> that’s about the direction that already requires an explicit coercion. But 
>>> this probably affects calling CF functions that take CFStrings, since IIRC 
>>> we don’t treat that the same as NSString at the moment, and CFArray will 
>>> never have generics.
>>> 
>>> Of course, I’ve been out of the Cocoa community for a while now, so I don’t 
>>> really have a sense of how often this comes up in practice, and how much 
>>> the explicit coercion costs (psychologically). So I’m with Brent: do we 
>>> have information on the changes needed for real-world projects?
>>> 
>>> Jordan
>>> 
>>> 
 On Apr 26, 2016, at 13:54, Chris Lattner via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hello Swift community,
 
 The review of "SE-0072: Fully eliminate implicit bridging conversions from 
 Swift" begins now and runs through May 2. The proposal is available here:
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md
  
 
 
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at:
 
https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 
 or, if you would like to keep your feedback private, directly to the 
 review manager.
 
 
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
 to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
 feature, how do you feel that this proposal compares to those?
* How much effor

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

[Max Moiseev via swift-evolution]

Hi Matthew,

In general, if you think there is something to be updated in the proposal, it 
is worth creating a new revision (like in the floating point protocols 
proposal, for example) and mentioning it in the thread.

I think it is a way to go in this particular case, since we are still in the 
first half of the review period. Any further discussion would benefit from it.

max


> On May 5, 2016, at 4:02 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi all,
>> 
>> This email is the result of a discussion between members of the standard 
>> library team.
>> 
>> We suggest changing the initializers argument label to `exactly` to match 
>> the one used in the floating point protocols proposal 
>> .
>>  Other than that the proposal seems to be a valuable addition to the 
>> standard library.
> 
> Thanks Max.  I'm glad to hear that!  Should I update the proposal or will you 
> just make that change as part of "accepted with modification"?
> 
>> 
>> max
>> 
>>> On May 3, 2016, at 8:57 PM, Chris Lattner >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0080: Failable Numeric Conversion Initializers" begins 
>>> now and runs through May 9. The proposal is available here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
>>>  
>>> 
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and contribute to the direction of Swift. 
>>> When writing your review, here are some questions you might want to answer 
>>> in your review:
>>> 
>>> * What is your evaluation of the proposal?
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> * Does this proposal fit well with the feel and direction of Swift?
>>> * If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org 
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>>> 
>> 
>> ___
>> 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] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

[Dmitri Gribenko via swift-evolution]

On Tue, May 3, 2016 at 8:57 PM, Chris Lattner via swift-evolution
 wrote:
> Hello Swift community,
>
> The review of "SE-0078: Implement a rotate algorithm, equivalent to 
> std::rotate() in C++" begins now and runs through May 9.

Hi,

I'm posting this feedback on behalf of Dave Abrahams, Max Moiseev and
myself.  We met and discussed the proposal in great detail.

First of all, we want to thank Nate and Sergey for proposing this API,
which is an important and useful algorithm.  We are generally in favor
of the proposal, but we would like to request a few changes.

Could you make 'func rotate' a requirement in the MutableCollection
protocol?  This allows selecting the best implementation for a given
concrete type, even when calling from generic code.

Could you explain why do we need a special implementation of
'reverse()' for RandomAccessCollection?  We couldn't think of a
performance reason for this.

Could you add complexity clauses to all new documentation comments?

We have discussed the names for these functions at length.  We felt
like the argument in 'rotate(firstFrom:)' does not convey the
argument's role well.  Our suggestion is to use
'rotate(shiftingToStart:)' and 'rotated(shiftingToStart:)'.  These
names emphasize that methods operate on the whole collection, shifting
all elements.  The argument is the index of the element that is moved
to the start index, and we tried to convey that by using the word
'start' instead of 'first'.  In the standard library, 'first' refers
to the element itself, not the index.  Indices use 'startIndex' and
'endIndex'.

We have considered a lot of alternative names, including
'swapSubranges(boundedBy:)', 'rewind', 'splitAndSwap', 'swapHalves'
and others, but they were not as good.  The problems are:

- 'swapSubranges' is mostly good, but 'subranges' does not imply that
the two subranges cover the whole collection.  The user might
reasonably expect to pass two subranges that will be swapped.

- 'Half' implies that two parts make a whole, but it also implies that
two parts are of equal size, which is not the case for this API.

- 'splitAndSwap' implies that we are operating on the whole, but feels
a very roundabout way to describe the operation.

For a non-mutating rotation we suggest defining separate types,
RotatedCollection, RotatedBidirectionalCollection, and
RotatedRandomAccessCollection, instead of returning a
FlattenCollection.  This has a few advantages.

- We can change the non-mutating 'rotated()' to just return the
collection instead of returning tuples of the collection and the
index.  The index of the former first element can be stored inside the
RotatedCollection in a property.  This change allows easier chaining
on '.rotated()', and goes in line with the return value of the
mutating 'rotate()' being discardable.

- Using an array in the return type of 'rotated()'
(FlattenCollection<[Self.SubSequence]>) would be less efficient than
it could be (extra allocation), and also feels like exposing too many
implementation details that we might want to change in future (for
example, if we get a CollectionOfTwo type).

- In future, when we have conditional protocol conformances in the
language, we would fold the three RotatedCollection types into one
type that conditionally conforms to collection protocols based on the
capabilities of the underlying collection.  We won't be able to do
that if some overloads return a FlattenCollection.

For lazy 'rotated()', just like for non-mutating 'rotated()', we
recommend returning only one value, a LazyCollection that wraps an
appropriate RotatedCollection.  The RotatedCollection will store the
index of the former first element in a property.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> This email is the result of a discussion between members of the standard 
> library team.
> 
> We suggest changing the initializers argument label to `exactly` to match the 
> one used in the floating point protocols proposal. Other than that the 
> proposal seems to be a valuable addition to the standard library.

Thanks Max.  I'm glad to hear that!  Should I update the proposal or will you 
just make that change as part of "accepted with modification"?

> 
> max
> 
>> On May 3, 2016, at 8:57 PM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now 
>> and runs through May 9. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> 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] Case conventions for mixed-case words (like

[Xiaodi Wu via swift-evolution]

On Thu, May 5, 2016 at 5:31 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> NaN is really a problem only because of using it as an acronym rather than
> just having .invalidNumber or .notANumber (little uglier) or something
> similar instead. This comes back to the annoying consideration between
> something being prior art, at the cost of potentially defining something
> that’s better, or a better fit for the language. If NaN didn’t exist
> elsewhere, would we even consider it at all if we were implementing float
> point numbers for the first ever time in Swift? I’d prefer we defined
> something more verbose as an alternative to avoid the acronym entirely.
>
> When it comes to having iPad conformance the question is; should we ever
> actually test for names at all? An iPad is a brand, it’s not really
> something that a program should test for, as what’s important to a program
> are capabilities. The same is true with testing for an OS, we don’t want to
> test Windows, Mac etc., but rather to test what libraries are available.
> Same is true with hardware; it doesn’t matter if a device is an iPad, what
> matters is that it has a touch-screen rather than a keyboard, that it has a
> small screen rather than a full monitor, that it’s mobile (and not plugged
> in) etc.
> Testing for names like that should be avoided at all costs when it comes
> to variable and method names, and be relegated to string-based tests for
> when you absolutely have to access that information. In other words
> programs should be platform agnostic, and only need to know whether
> capabilities they require or optionally support exist or not.
> For these I’d prefer that the guidelines warn against these in the
> strongest possible terms, as they’re usually a bad idea IMO.


Whether using the word iPad is wise or not, the question still remains what
to do when encountering a term that looks like that. If I'm writing an app
that deals with chemical compounds, how should I name a type that deals
with pH? How about a computed property representing pH? Should either or
both be PH, pH, or ph? It certainly will not do to say "just name it
powerOfHydrogen".
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[David Sweeris via swift-evolution]

> On May 5, 2016, at 5:01 PM, Dave Abrahams  wrote:
> 
> 
> on Wed May 04 2016, David Sweeris  wrote:
> 
>>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> In order for something like AnyValue to have meaning, we need to impose
>>> greater order.  After thinking through many approaches over the years, I
>>> have arrived at the (admittedly rather drastic) opinion that the
>>> language should effectively outlaw the creation of structs and enums
>>> that don't have value semantics.  (I have no problem with the idea that
>>> immutable classes that want to act as values should be wrapped in a
>>> struct).  The language could then do lots of things much more
>>> intelligently, such as correctly generating implementations of
>>> equality. 
>> 
>> You mean that a struct's properties would have to have value
>> semantics, too? 
> 
> Either that, or you'd have to implement CoW, or you'd not use the
> storage behind any properties that were references in a way that affects
> value semantics.
> 
>> I think I'm okay with that, especially if it's done through new types
>> of structs/enums.
> 
> New types of structs/enums?  What does that mean?
I meant leave `struct` and `enum` the way they are, and introduce a 
`different_struct` and `different_enum` (placeholder names, of course) which 
enforced the “no reference-semantics” rules.

I’m inclined to think we should adopt your “no reference-semantics” rule, but 
I’m not entirely sure what the impact would be. Adding new types side-steps the 
issue, at the cost of increasing the complexity of the language/compiler. I’m 
unsure if that'd be a worth-while trade-off.

- Dave Sweeris

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

[Max Moiseev via swift-evolution]

Hi all,

This email is sent on behalf of the standard library team.

Since the implicit conversion is available from `UnsafeMutablePointer` to 
`UnsafePointer`, the functions listed in the proposal do not have to be 
overloads, they can simply replace existing ones instead.
If/when the implicit conversion will be removed from the language, overloads 
accepting `UnsafeMutablePointer` would have to be introduced.

We also suggest extending the proposal to include other instances of the same 
pattern, if there are any elsewhere in the standard library.

thanks,
max



> On May 3, 2016, at 8:56 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0076: Add overrides taking an UnsafePointer source to 
> non-destructive copying methods on UnsafeMutablePointer" begins now and runs 
> through May 9. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] Case conventions for mixed-case words (like

[Haravikk via swift-evolution]

NaN is really a problem only because of using it as an acronym rather than just 
having .invalidNumber or .notANumber (little uglier) or something similar 
instead. This comes back to the annoying consideration between something being 
prior art, at the cost of potentially defining something that’s better, or a 
better fit for the language. If NaN didn’t exist elsewhere, would we even 
consider it at all if we were implementing float point numbers for the first 
ever time in Swift? I’d prefer we defined something more verbose as an 
alternative to avoid the acronym entirely.

When it comes to having iPad conformance the question is; should we ever 
actually test for names at all? An iPad is a brand, it’s not really something 
that a program should test for, as what’s important to a program are 
capabilities. The same is true with testing for an OS, we don’t want to test 
Windows, Mac etc., but rather to test what libraries are available. Same is 
true with hardware; it doesn’t matter if a device is an iPad, what matters is 
that it has a touch-screen rather than a keyboard, that it has a small screen 
rather than a full monitor, that it’s mobile (and not plugged in) etc.
Testing for names like that should be avoided at all costs when it comes to 
variable and method names, and be relegated to string-based tests for when you 
absolutely have to access that information. In other words programs should be 
platform agnostic, and only need to know whether capabilities they require or 
optionally support exist or not.
For these I’d prefer that the guidelines warn against these in the strongest 
possible terms, as they’re usually a bad idea IMO.

> On 5 May 2016, at 20:49, Justin Jia via swift-evolution 
>  wrote:
> 
> I think ipad and IPAD are better. Ipad and IPad look really bad. 
> e.g isIPAD / ipadUser / isNAN / nan
> 
> Or what about this: For lowerCamelCase, we use all lower letters (like ipad).
> For UpperCamelCase, we keep the original one (iPad). 
> e.g. isiPad / ipadUser isNaN / nan
> 
> Justin
> 
> ___
> 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-0080: Failable Numeric Conversion Initializers

[Max Moiseev via swift-evolution]

Hi all,

This email is the result of a discussion between members of the standard 
library team.

We suggest changing the initializers argument label to `exactly` to match the 
one used in the floating point protocols proposal 
.
 Other than that the proposal seems to be a valuable addition to the standard 
library.

max

> On May 3, 2016, at 8:57 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now 
> and runs through May 9. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, David Sweeris  wrote:

>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> In order for something like AnyValue to have meaning, we need to impose
>> greater order.  After thinking through many approaches over the years, I
>> have arrived at the (admittedly rather drastic) opinion that the
>> language should effectively outlaw the creation of structs and enums
>> that don't have value semantics.  (I have no problem with the idea that
>> immutable classes that want to act as values should be wrapped in a
>> struct).  The language could then do lots of things much more
>> intelligently, such as correctly generating implementations of
>> equality. 
>
> You mean that a struct's properties would have to have value
> semantics, too? 

Either that, or you'd have to implement CoW, or you'd not use the
storage behind any properties that were references in a way that affects
value semantics.

> I think I'm okay with that, especially if it's done through new types
> of structs/enums.

New types of structs/enums?  What does that mean?

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, Matthew Johnson  wrote:

> On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed May 04 2016, Matthew Johnson  wrote:
>
> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution
>  wrote:
>
> on Wed May 04 2016, Adrian Zubarev 
> wrote:
>
> Not sure what to think about the enum cases inside a
> protocol (if AnyEnum would
> even exist), it could be a nice addition to the language, but
> this is an own
> proposal I guess.
>
> We should start by adding AnyValue protocol to which all value
> types
> conforms.
>
> Having a way to constrain conformance to things with value 
> semantics
> is
> something I've long wanted. *However*, the approach described is 
> too
> simplistic. It's possible to build classes whose instances have
> value
> semantics (just make them immutable) and it's possible to build
> structs
> whose instances have reference semantics (just put the struct's
> storage
> in a mutable class instance that it holds as a property, and don't
> do
> copy-on-write). 
>
> In order for something like AnyValue to have meaning, we need to
> impose
> greater order. After thinking through many approaches over the
> years, I
> have arrived at the (admittedly rather drastic) opinion that the
> language should effectively outlaw the creation of structs and 
> enums
> that don't have value semantics. (I have no problem with the idea
> that
> immutable classes that want to act as values should be wrapped in 
> a
> struct). The language could then do lots of things much more
> intelligently, such as correctly generating implementations of
> equality.
>
> That is a drastic solution indeed! How would this impact things like
> Array? While Array itself has value semantics, the aggregate
> obviously does not as it contains references which usually be mutated
> underneath us. 
>
> Value semantics and mutation can only be measured with respect to
> equality. The definition of == for all class types would be equivalent
> to ===. Problem solved.
>
> Similar considerations apply to simpler wrapper structs such as Weak.
>
> Same answer.
>
> Hmm. If those qualify as “value semantic” then what kind of structs and enums
> would not? A struct wrapping a mutable reference type certainly doesn’t “feel”
> value semantic to me and certainly doesn’t have the guarantees usually
> associated with value semantics (won’t mutate behind your back, thread safe,
> etc).

Sure it does.

 public struct Wrap : Equatable {
   init(_ x: T) { self.x = x }
   private x: T
 }

 func == (lhs: Wrap, rhs: Wrap) -> Bool {
   return lhs.x === rhs.x
 }

I defy you to find any scenario where Wrap doesn't have value
semantics, whether T is mutable or not.

Alternately, you can look at the Array implementation.  Array is a
struct wrapping a mutable class.  It has value semantics by virtue of
CoW.

> My expectation is a generic aggregate such as Array would have to
> conditionally conform to AnyValue only when Element also conforms to
> AnyValue.
>
> I’m also wondering how such a rule would be implemented while still
> allowing for CoW structs that *do* implement value semantics, but do
> so while using references internally.
>
> I am not talking about any kind of statically-enforceable rule, although
> we could probably make warnings sophisticated enough to help with this.
>
> You said the you have arrived at the opinion that the language should
> “effectively outlaw” structs and enums that do not have value semantics. That
> sounded like static enforcement to me. 

The language outlaws certain kinds of inout aliasing without providing static
enforcement.  This is like that.

> Maybe you meant we should allow the compiler to assume value semantics
> for structs and enums despite the fact that it doesn’t statically
> enforce this?

That would be one *consequence* of effectively outlawing it.  The library
could make similar assumptions.

> If the compiler can be sophisticated enough to verify value semantics
> statically maybe it would be better to have that mechanism be
> triggered by conformance to AnyValue rather than for all structs and
> enums. Types that conform to AnyValue would receive the benefits of
> the compiler knowing they have value semantics, while other uses of
> structs and enums would remain valid. Best practice would be to
>  

Re: [swift-evolution] multi-line string literals.

[Sean Heber via swift-evolution]

I admit I have not been following this closely and have not read all proposals 
and counter proposals and concerns - but of course that isn’t going to stop me 
from tossing out my own suggestion!

My idea starts with this:

let code = #string // some code that we are generating
 + #string and some more code here
 + #string another line here
 + #string
 + #string including a blank line if we wanted
 + #string etc.

When used in this way, it simply generates a string literal from everything 
that follows “#string” up to and including the newline. To chain multiple lines 
together, it just uses string’s normal + operator. This would be the same as 
writing the following code:

let code = "// some code that we are generating\n"
 + "and some more code here\n"
 + "another line here\n"
 + "\n"
 + "including a blank line if we wanted\n"
 + "etc.\n"

I would then extend this to support some other useful approaches such as:

#string(THE_END)
blah blah blah   \\\   blah
  can  be anything \o/
whatever!!
THE_END

Or to use the entire contents of an external file:

#string(“file.txt")

l8r
Sean





> On May 5, 2016, at 3:51 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> It had the idea that maybe the motivation behind continuation quotes is to 
>> make using multiline strings harder to use; in order to discourage their use 
>> at all.
> 
> Absolutely not, and frankly I resent the implication.
> 
> I'm looking at a space where (in my opinion) all existing designs are ugly 
> and inelegant and trying to find something better. There are *reasons* Swift 
> 2 doesn't allow newlines in quote marks; I'm trying to address them, not 
> ignore them. There are nasty formatting problems; I'm trying to solve them, 
> not tolerate them. There are significant context-sensitivity issues; I'm 
> trying to fix them, not punt the problem to a syntax highlighter that is 
> absent or incorrect in half of our tools.
> 
> Here's a piece of code-generating code I once wrote, ported to this prototype:
> 
>   https://gist.github.com/brentdax/8a8ee1f6028230f68ed85b7f3ebc95bf
> 
> (The actual code generation starts on line 93.) 
> 
> And here's the same code in (beta-era) Swift 2:
> 
>   
> https://github.com/brentdax/WebResponder/blob/master/WebResponderCore/WebResponderCore/codes2swift.swift
> 
> I think the new version is an improvement over the old. I think I like it 
> better than I would with `"""` or heredocs forcing things against the left 
> margin. I think it's nice that I can look at any line—out of context, random 
> access—and see which parts are string literals. I think if I want to add a 
> doc comment to each of the constants it generates, I have to do a little 
> awkward code shuffling, but the result is worth it:
> 
>   for statusLine in statusLines {
>   code +=  "/// The HTTP \(statusLine.code) \(statusLine.message) 
> status, used with `HTTPResponseType.status`.
>"\(statusLine.constant)
>"
>""
>   }
> 
> Overall, I find this code a lot more pleasant to read than it was in Swift 2, 
> and somewhat more pleasant than it would be with `"""` or a heredoc. Maybe 
> you don't agree; maybe you'd rather import some other language's warts. I 
> understand—those warts come with convenience advantages, and you might prefer 
> that convenience to the other things.
> 
> But at least have the basic respect for opposing viewpoints not to impugn my 
> motives because you disagree with me or don't like what I suggest. That is 
> just not nice.
> 
> -- 
> 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] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Brent Royal-Gordon via swift-evolution]

> One idea that came out of the core team discussion was something like:
> 
>sequence(from: 0) { $0 += 42 }
> 
> Since it returns a sequence.

It definitely occurred to me that this was kind of just a way to construct a 
generic iterator. Maybe a new AnyIterator (I believe there is such a thing) 
constructor?

-- 
Brent Royal-Gordon
Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Pierre Grabolosa via swift-evolution]

Most humbly, I think "expand" could be an interesting name for this operation. 
It seems it hasn't come up, but I could be wrong.

Best regards,
Pierre

Sent from my iPhone

> On 05 May 2016, at 01:50, Chris Lattner  wrote:
> 
> unfold(_:applying:) - This addition is *rejected* by the core team as 
> written, but deserves more discussion in the community, and potentially could 
> be the subject of a future proposal.  The core team felt that the utility of 
> this operation is high enough to be worth including in the standard library, 
> but could not find an acceptable name for it.  “unfold” is problematic, 
> despite its precedence in other language, because Swift calls the 
> corresponding operation “reduce” and not “fold”.  No one could get excited 
> about “unreduce”.   “iterate” was also considered, but a noun is more 
> appropriate than an verb in this case.  Given the lack of a good name, the 
> core team preferred to reject to let the community discuss it more.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Brent Royal-Gordon via swift-evolution]

> It had the idea that maybe the motivation behind continuation quotes is to 
> make using multiline strings harder to use; in order to discourage their use 
> at all.

Absolutely not, and frankly I resent the implication.

I'm looking at a space where (in my opinion) all existing designs are ugly and 
inelegant and trying to find something better. There are *reasons* Swift 2 
doesn't allow newlines in quote marks; I'm trying to address them, not ignore 
them. There are nasty formatting problems; I'm trying to solve them, not 
tolerate them. There are significant context-sensitivity issues; I'm trying to 
fix them, not punt the problem to a syntax highlighter that is absent or 
incorrect in half of our tools.

Here's a piece of code-generating code I once wrote, ported to this prototype:

https://gist.github.com/brentdax/8a8ee1f6028230f68ed85b7f3ebc95bf

(The actual code generation starts on line 93.) 

And here's the same code in (beta-era) Swift 2:


https://github.com/brentdax/WebResponder/blob/master/WebResponderCore/WebResponderCore/codes2swift.swift

I think the new version is an improvement over the old. I think I like it 
better than I would with `"""` or heredocs forcing things against the left 
margin. I think it's nice that I can look at any line—out of context, random 
access—and see which parts are string literals. I think if I want to add a doc 
comment to each of the constants it generates, I have to do a little awkward 
code shuffling, but the result is worth it:

for statusLine in statusLines {
code +=  "/// The HTTP \(statusLine.code) \(statusLine.message) 
status, used with `HTTPResponseType.status`.
 "\(statusLine.constant)
 "
 ""
}

Overall, I find this code a lot more pleasant to read than it was in Swift 2, 
and somewhat more pleasant than it would be with `"""` or a heredoc. Maybe you 
don't agree; maybe you'd rather import some other language's warts. I 
understand—those warts come with convenience advantages, and you might prefer 
that convenience to the other things.

But at least have the basic respect for opposing viewpoints not to impugn my 
motives because you disagree with me or don't like what I suggest. That is just 
not nice.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On May 5, 2016, at 3:40 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On May 5, 2016, at 2:39 PM, Chris Lattner  wrote:
>>> 
>>> 
>>> On May 5, 2016, at 1:03 PM, Erica Sadun  wrote:
>>> 
 On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution 
  wrote:
 
 Proposal link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
 
 Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as 
 specified in revision 3 of the proposal.
>>> 
>>> I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` 
>>> pairs that linguistically matched.Nonetheless I'm gratified these are 
>>> hopping into the language. That said, I'm going to put on my painters cap 
>>> to consider selecting some exterior latex for the feature I was most 
>>> looking forward to in this proposal:
>>> 
>>> Core team writes:
 unfold(_:applying:) - This addition is *rejected* by the core team as 
 written, but deserves more discussion in the community, and potentially 
 could be the subject of a future proposal.  The core team felt that the 
 utility of this operation is high enough to be worth including in the 
 standard library, but could not find an acceptable name for it.  “unfold” 
 is problematic, despite its precedence in other language, because Swift 
 calls the corresponding operation “reduce” and not “fold”.  No one could 
 get excited about “unreduce”.   “iterate” was also considered, but a noun 
 is more appropriate than an verb in this case.  Given the lack of a good 
 name, the core team preferred to reject to let the community discuss it 
 more.
>>> 
>>> A few thoughts:
>>> 
>>> * I'm not sure why a noun is more appropriate than a verb. Reduce isn't a 
>>> noun, prefix isn't a noun, drop isn't a noun. 
>> 
>> I’m not a naming guru, but my understanding is that ‘reduce’ was picked 
>> because it was term of art (like map), which is what allowed the misuse of a 
>> verb.
>> 
>> One idea that came out of the core team discussion was something like:
>> 
>>sequence(from: 0) { $0 += 42 }
>> 
>> Since it returns a sequence.
>> 
>> -Chris
> 
> I'd +1 that

+1 from me as well

> 
> -- 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

I like the continuation quote. It makes the code stay pretty. It doesn't break 
the indentation of your code. If you take out the continuation quote then 
things look out of place, as if someone pasted text in the middle of your code 
by mistake. I don't like the heredoc notation either for the same reasons.

I envision being able to type the opening multi line quote, i.e. M" and then 
pasting multi line text from the clipboard. The editor would do a smart paste 
prepending the lines of text with the continuation character.  

Let's keep our code looking  pretty and focus on the main things:

1. Allow interpolation 
2. Remove the need to add the \n character for each line
3. Remove the need to escape the double quote and apostrophe
4. Keep it simple

I would be fine just with this:

let xml = M"
  "
  " 
  " \(author)
  " 
  "



> On May 5, 2016, at 9:17 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?
> ___
> 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] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Erica Sadun via swift-evolution]

> On May 5, 2016, at 2:39 PM, Chris Lattner  wrote:
> 
>> 
>> On May 5, 2016, at 1:03 PM, Erica Sadun > > wrote:
>> 
>> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>>>  
>>> 
>>> 
>>> Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as 
>>> specified in revision 3 of the proposal.
>> 
>> I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` 
>> pairs that linguistically matched.Nonetheless I'm gratified these are 
>> hopping into the language. That said, I'm going to put on my painters cap to 
>> consider selecting some exterior latex for the feature I was most looking 
>> forward to in this proposal:
>> 
>> Core team writes:
>>> unfold(_:applying:) - This addition is *rejected* by the core team as 
>>> written, but deserves more discussion in the community, and potentially 
>>> could be the subject of a future proposal.  The core team felt that the 
>>> utility of this operation is high enough to be worth including in the 
>>> standard library, but could not find an acceptable name for it.  “unfold” 
>>> is problematic, despite its precedence in other language, because Swift 
>>> calls the corresponding operation “reduce” and not “fold”.  No one could 
>>> get excited about “unreduce”.   “iterate” was also considered, but a noun 
>>> is more appropriate than an verb in this case.  Given the lack of a good 
>>> name, the core team preferred to reject to let the community discuss it 
>>> more.
>> 
>> A few thoughts:
>> 
>> * I'm not sure why a noun is more appropriate than a verb. Reduce isn't a 
>> noun, prefix isn't a noun, drop isn't a noun. 
> 
> I’m not a naming guru, but my understanding is that ‘reduce’ was picked 
> because it was term of art (like map), which is what allowed the misuse of a 
> verb.
> 
> One idea that came out of the core team discussion was something like:
> 
>sequence(from: 0) { $0 += 42 }
> 
> Since it returns a sequence.
> 
> -Chris

I'd +1 that.

-- E

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

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Chris Lattner via swift-evolution]

> On May 5, 2016, at 1:03 PM, Erica Sadun  wrote:
> 
> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>>  
>> 
>> 
>> Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as 
>> specified in revision 3 of the proposal.
> 
> I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` 
> pairs that linguistically matched.Nonetheless I'm gratified these are hopping 
> into the language. That said, I'm going to put on my painters cap to consider 
> selecting some exterior latex for the feature I was most looking forward to 
> in this proposal:
> 
> Core team writes:
>> unfold(_:applying:) - This addition is *rejected* by the core team as 
>> written, but deserves more discussion in the community, and potentially 
>> could be the subject of a future proposal.  The core team felt that the 
>> utility of this operation is high enough to be worth including in the 
>> standard library, but could not find an acceptable name for it.  “unfold” is 
>> problematic, despite its precedence in other language, because Swift calls 
>> the corresponding operation “reduce” and not “fold”.  No one could get 
>> excited about “unreduce”.   “iterate” was also considered, but a noun is 
>> more appropriate than an verb in this case.  Given the lack of a good name, 
>> the core team preferred to reject to let the community discuss it more.
> 
> A few thoughts:
> 
> * I'm not sure why a noun is more appropriate than a verb. Reduce isn't a 
> noun, prefix isn't a noun, drop isn't a noun. 

I’m not a naming guru, but my understanding is that ‘reduce’ was picked because 
it was term of art (like map), which is what allowed the misuse of a verb.

One idea that came out of the core team discussion was something like:

   sequence(from: 0) { $0 += 42 }

Since it returns a sequence.

-Chris

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

Re: [swift-evolution] Referencing zero-parameter functions

[Chris Lattner via swift-evolution]

> On May 5, 2016, at 10:38 AM, Joe Groff  wrote:
> 
> 
>> On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution 
>>>  wrote:
 Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
 returns its return value of type `Int` – not a reference to the function 
 of type `Void -> Int`. 
>>> 
>>> Right.
>>> 
>>> That said, what is wrong with just “foo”?
>> 
>> As pointed out in the original post, that can refer to both ‘foo()’ and 
>> ‘foo(bar:)’ today.
> 
> We could change that, so that to refer to `foo(bar:)` you must use the full 
> compound name.

Right.  that seems like the most logical solution to this problem, if it is 
really significant enough to fix.

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

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 2:51 PM, Dave Abrahams  wrote:
> 
> 
> on Thu May 05 2016, Matthew Johnson  > wrote:
> 
>> Sent from my iPad
>> 
>>> On May 5, 2016, at 10:59 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Wed May 04 2016, Matthew Johnson  wrote:
>>> 
> On May 4, 2016, at 4:16 PM, David Sweeris  wrote:
> 
> Having given it some more thought... Does "PureReference" make
> sense? What would it mean? At some point a reference has to, you
> know, actually refer to a concrete value. Otherwise it's just
> turtles all the way down.
 
 In my thinking PureReference (or ImmutableObject) has semantics
 indicating that the type is a value-semantic reference type.  I think
 this could be quite useful in some cases.
>>> 
>>> Like what? To a first approximation, the only thing I can see this being
>>> useful for is Objective-C interop.  Aside from being an element of an
>>> NSArray, there's nothing a an immutable class can do that a struct
>>> can't.
>> 
>> Objective-C / cocoa interop is important enough to matter IMO.
> 
> Sure.  I don't see why we should have an ImmutableObject protocol when
> we can just compose “Immutable” with “AnyObject.”

Yes, fair enough.  A typealias is easy enough to add if it is used frequently.  

I wouldn’t call it “Immutable” though as “PureValue" indicates what we care 
about (value semantics).  “ImmutableObject” is just a good name for a value 
semantic reference type as immutability is the only way to achieve value 
semantics with a reference type.

It would be great to see “PureValue” added to the standard library and applied 
to its types.  This would allow us to start drawing the distinction you make in 
your third category which is very important for many reasons, but is only 
latent today.

> 
>> 
>> 
>>> 
 
 
> 
> Sent from my iPhone
> 
>> On May 4, 2016, at 13:32, Matthew Johnson  wrote:
>> 
>> 
>>> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On May 4, 2016, at 11:12, Joe Groff via swift-evolution 
  wrote:
 
 I can see value in there being some kind of PureValue protocol,
 for types that represent fully self-contained values, but
 conforming to that protocol requires a bit more thought than just
 being a struct or enum, since there are structs that have
 reference semantics (such as UnsafePointer), and there are hybrid
 value types that contain references to data that isn't part of
 the value (an Array, for instance).
 
 -Joe
>>> 
>>> +1
>>> 
>>> I'd think that both "PureValue" and "PureReference" would be
>>> useful. Isn't it the mixed types that make for tricky mutation
>>> rules & serialization?
>> 
>> I also like Joe’s idea.  It fits with the direction in Swift of 
>> attaching semantics, not just syntax, to protocols.
>> 
>> I was thinking of something pretty similar to your PureReference
>> idea, but slightly different.  Pure / immutable references have
>> value semantics.  With that in mind I was thinking of an
>> ImmutableObject protocol which would inherit from both AnyObject
>> and PureValue.
>> 
>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> -- 
>>> Dave
> 
> -- 
> Dave

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

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

[Erica Sadun via swift-evolution]

On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution 
 wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
> 
> Sequence.prefix(while:) & Sequence.drop(while:) - These are *accepted* as 
> specified in revision 3 of the proposal.

I'm still a little sad we didn't go for `prefix`/`suffix` or `take`/`drop` 
pairs that linguistically matched.Nonetheless I'm gratified these are hopping 
into the language. That said, I'm going to put on my painters cap to consider 
selecting some exterior latex for the feature I was most looking forward to in 
this proposal:

Core team writes:
> unfold(_:applying:) - This addition is *rejected* by the core team as 
> written, but deserves more discussion in the community, and potentially could 
> be the subject of a future proposal.  The core team felt that the utility of 
> this operation is high enough to be worth including in the standard library, 
> but could not find an acceptable name for it.  “unfold” is problematic, 
> despite its precedence in other language, because Swift calls the 
> corresponding operation “reduce” and not “fold”.  No one could get excited 
> about “unreduce”.   “iterate” was also considered, but a noun is more 
> appropriate than an verb in this case.  Given the lack of a good name, the 
> core team preferred to reject to let the community discuss it more.

A few thoughts:

* I'm not sure why a noun is more appropriate than a verb. Reduce isn't a noun, 
prefix isn't a noun, drop isn't a noun. 
* Not a fan of unfold or unreduce, either.
* Why not `induce` as a counter to `reduce`? (induction/reduction if you want 
to noun it, which I don't)

Stepping back, the definition of `reduce` is:

Returns the result of repeatedly calling `combine` with an accumulated 
value 
initialized to `initial` and each element of `self`, in turn

public func reduce(initial: T, @noescape combine: (T, 
Self.Generator.Element) throws -> T) rethrows -> T

e.g. print("Hello".characters.reduce(" ", combine: {$0 + String($1) + " "}))

The definition of whatever *this* is, is more or less:

Returns the lazy sequence of repeatedly calling `generate` with an 
accumulated value
initialized to `initial`. The sequence terminates when the generation 
closure returns `nil`.

public func ???(initial: T, generate: (T) -> T?) -> Sequence

So why not `induce`? It's got a cute name relationship with `reduce`?

var seq = induce(10, generate: { $0 == 0 ? nil : $0 - 1 })
print(Array(seq)) // [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

seq = induce(1, generate:{ $0 * 2 }).prefix(while: { $0 < 1000 })
print(Array(seq)) // [2, 4, 8, 16, 32, 64, 128, 256, 512]

-- E


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

Re: [swift-evolution] Case conventions for mixed-case words (like

[Justin Jia via swift-evolution]

I think ipad and IPAD are better. Ipad and IPad look really bad. 
e.g isIPAD / ipadUser / isNAN / nan

Or what about this: For lowerCamelCase, we use all lower letters (like ipad).
For UpperCamelCase, we keep the original one (iPad). 
e.g. isiPad / ipadUser isNaN / nan

Justin

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

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Thu May 05 2016, Joe Groff  wrote:

>> On May 5, 2016, at 10:03 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Thu May 05 2016, Joe Groff  wrote:
>> 
>
 On May 5, 2016, at 8:56 AM, Dave Abrahams  wrote:
 
 
 on Wed May 04 2016, Joe Groff  wrote:
 
>>> 
>> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> Something about your first paragraph reminded me of a question I've
>> had for a while. Is there a reasoning behind not being able to
>> restrict a protocol to value types? One way that this might be
>> workable is if we could overload protocols for Value vs for
>> reference.
> 
> I'm not totally comfortable with this, because references are a kind
> of value. 
 
 We're using the word “value” in 3 different ways now.  If we don't sort
 them out, this is going to become impossible to resolve.  So let me
 propose some terms:
 
 1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
  value of type T is essentially what an UnsafePointer points at.
  In this sense, a variable of any type T “has a value.”  Even though
  it's not strictly correct (since the term really applies to
  expressions), I propose “rvalue” for this one.  
 
 2. The “value types vs reference types” sense, where every type falls
  into one of two crisp buckets based on how it's declared.  I propose
  we always say “reference type” or “value type” for this one.
 
 3. The “value semantics vs reference semantics” sense, where a type's
  category depends on how it is implemented,  and it's possible (though
  inadvisable) to fall outside either bucket.  This is the only
  interesting category when you're discussing protocols and
  constraints, and doesn't have any intrinsic relationship to sense
  #2.  I propose we always say “value semantics” or “reference
  semantics” for this one.
>>> 
>>> I claim that my sense is the same as #2. A reference has all the
>>> properties of a value-type value; it has the additional ability to be
>>> used as a handle to access independent program state. Int isn't any
>>> less of a value because it can be used to reference values in an
>>> array. 
>> 
>> It's less of a value in sense #2 because 
>> 
>>  x as Any as? AnyObject
>> 
>> is always nil for a value in sense #2.
>> 
>>> Rather than try to break the world down according to categories of
>>> types, I think it's more effective to look at the semantics of
>>> *operations*. So called "reference types" have value semantics
>>> operations too; 
>> 
>> Please define the term “value semantics operation.”  I wager there is no
>> such thing.
>
> A mutating operation with no other side effects than modifying the values of 
> its 'inout' parameters.
>
>> 
>>> reassigning a class reference, '+='-ing a pointer,
>> 
>> A pointer is a value type in every sense of the word.
>> 
>>> and adding or removing elements from an Array of references are all
>>> operations that mutate only the value being operated on, even though
>>> none of these types are strictly "value types".
>> 
>> Now you're really blending meanings, or at least being very fuzzy.  Your
>> Array of references has a sense #1 value that might not even be altered
>> when you change the elements in the array.  It is a sense #2 value by
>> language rules.  It almost has sense #3 value semantics but for our
>> inability to compare it with "==", because we don't implicitly get "=="
>> defined in terms of "===" for all classes.
>> 
>> Saying something has value semantics is meaningless without a way to
>> determine equivalence that respects the boundaries of the value.  The
>> *whole point* of value semantics is that initialization, assignment,
>> parameter passing, and returning all create *independent* instances, with
>> no observable shared state, and that can be read and mutated
>> concurrently in different threads.  To even test that, you need to nail
>> down what it means for a value to change, and for that, you need an
>> equality comparison.
>
> What I'm trying to say is that there are "boundaries of the value" for
> everything in our system. For class references, that boundary happens
> to only include the reference itself.

I would agree that there are *potential* “boundaries of the value” for
everything in our system.  Up to now, there has been no general
agreement that the default “boundaries of the value” for references stop
at the reference's own bits, and that mutable classes can't have an "=="
that reaches beyond those bits.  Until we reach such agreement, I don't
think there's any reasonable way to argue that any of the three
categories I listed are the same.  And I think we need those categories
in order to create that agreement.

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

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Thu May 05 2016, Matthew Johnson  wrote:

> Sent from my iPad
>
>> On May 5, 2016, at 10:59 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed May 04 2016, Matthew Johnson  wrote:
>> 
 On May 4, 2016, at 4:16 PM, David Sweeris  wrote:
 
 Having given it some more thought... Does "PureReference" make
 sense? What would it mean? At some point a reference has to, you
 know, actually refer to a concrete value. Otherwise it's just
 turtles all the way down.
>>> 
>>> In my thinking PureReference (or ImmutableObject) has semantics
>>> indicating that the type is a value-semantic reference type.  I think
>>> this could be quite useful in some cases.
>> 
>> Like what? To a first approximation, the only thing I can see this being
>> useful for is Objective-C interop.  Aside from being an element of an
>> NSArray, there's nothing a an immutable class can do that a struct
>> can't.
>
> Objective-C / cocoa interop is important enough to matter IMO.

Sure.  I don't see why we should have an ImmutableObject protocol when
we can just compose “Immutable” with “AnyObject.”

>
>
>> 
>>> 
>>> 
 
 Sent from my iPhone
 
> On May 4, 2016, at 13:32, Matthew Johnson  wrote:
> 
> 
>> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 4, 2016, at 11:12, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> I can see value in there being some kind of PureValue protocol,
>>> for types that represent fully self-contained values, but
>>> conforming to that protocol requires a bit more thought than just
>>> being a struct or enum, since there are structs that have
>>> reference semantics (such as UnsafePointer), and there are hybrid
>>> value types that contain references to data that isn't part of
>>> the value (an Array, for instance).
>>> 
>>> -Joe
>> 
>> +1
>> 
>> I'd think that both "PureValue" and "PureReference" would be
>> useful. Isn't it the mixed types that make for tricky mutation
>> rules & serialization?
> 
> I also like Joe’s idea.  It fits with the direction in Swift of attaching 
> semantics, not just syntax, to protocols.
> 
> I was thinking of something pretty similar to your PureReference
> idea, but slightly different.  Pure / immutable references have
> value semantics.  With that in mind I was thinking of an
> ImmutableObject protocol which would inherit from both AnyObject
> and PureValue.
> 
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> -- 
>> Dave

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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

I like the continuation quote. It makes the code stay pretty. It doesn't break 
the indentation of your code. If you take out the continuation quote then 
things look out of place, as if someone pasted text in the middle of your code 
by mistake. I don't like the heredoc notation either for the same reasons.

I envision being able to type the opening multi line quote, i.e. M" and then 
pasting multi line text from the clipboard. The editor would do a smart paste 
prepending the lines of text with the continuation character.  

Let's keep our code looking  pretty and focus on the main things:

1. Allow interpolation 
2. Remove the need to add the \n character for each line
3. Remove the need to escape the double quote and apostrophe
4. Keep it simple

I would be fine just with this:

let xml = M"
   "
   " 
   "   \(author)
   " 
   "



> On May 5, 2016, at 9:17 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> it's not a secret that I'm not a big fan of the proposal. The third draft 
>> doesn't change this and it's unlikely that any future draft will, because 
>> for me, the problem are the continuation quotes, and for Brent it seems like 
>> they are a must-have-feature (correct me if I'm wrong.)
> 
> I agree with all you said. I’m fairly sure I would never vote for Brent’s 
> proposal simply because of the existence of continuation quotes, no matter 
> the amount of reasoning behind it. They are simply too unwieldy, cumbersome 
> and unfriendly to modification.
> 
> I could see either your proposal, or your proposal without the HERE_DOCs but 
> using Tyler’s/Scala’s .stripMargin. Do you think you could start a formal 
> proposal?
> ___
> 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] [Pitch] Consistent bridging for NSErrors at the language boundary

[Charles Srstka via swift-evolution]

I formerly posted a less-fleshed-out version of this in the “Reducing bridging 
magic” thread, but I thought this might warrant its own pitch. What do you all 
think?

MOTIVATION:

Over the past couple of years, Swift has made great strides toward seamless 
interoperability with existing Objective-C APIs, and with SE-0005, SE-0033, 
SE-0057, SE-0062, SE-0064, and SE-0070, seems poised to become even better in 
that regard. However, there still exists one major pain point when going back 
and forth between Swift and Objective-C, and that lies in the area of error 
reporting. Passing errors between Objective-C and Swift APIs is currently quite 
awkward, for several reasons:

- The Swift-approved mechanism for reporting errors is a protocol named 
ErrorType (ErrorProtocol in the latest sources). However, Objective-C represent 
errors using a class named NSError. In addition to being a reference type, 
which feels quite unnatural for an error object by Swift’s conventions, NSError 
follows a completely paradigm from what most ErrorProtocol objects use to store 
errors, using a string-based domain and and integer code, along with a userInfo 
dictionary to store information to be presented to the user. While the domain 
and code are available as methods on ErrorProtocol, they are prefixed with 
underscores, and there is no direct equivalent to userInfo.

- Unlike other Objective-C classes like NSString and NSArray which are 
consistently bridged to value types when presenting Objective-C interfaces to 
Swift, the handling of NSError objects is inconsistent. Objective-C APIs which 
return an error by reference using an autoreleasing NSError ** pointer are 
converted to use the Swift try/catch mechanism, presenting the returned error 
as an ErrorProtocol (which is actually an NSError). Similarly, Swift APIs using 
try/catch are presented to Objective-C as autoreleasing NSError ** pointers, 
and the ErrorProtocol-conforming error is converted to an NSError when it is 
called by Objective-C. However, when passing around error objects in any way 
other than these, the errors are not bridged. An Objective-C API that takes an 
NSError, such as NSApp’s -presentError: method, still leaves NSError as the 
type in the interface presented to Swift, as do the many asynchronous APIs in 
Cocoa that return an NSError as one of the arguments to a completion handler. 
Swift APIs that accept ErrorProtocols, on the other hand, are not presented to 
Objective-C at all, necessitating any such APIs also be declared to take 
NSErrors.

- To convert ErrorProtocols to NSErrors, Swift provides a bridging mechanism, 
invoked via “as NSError”, which wraps the error in a private NSError subclass 
class called _SwiftNativeNSError. This subclass can be cast back to the 
original error type, thus returning the original wrapped error. When a Swift 
API that is marked “throws” is called from Objective-C and then throws an 
error, the same bridging mechanism is invoked. However, this bridging is not 
very useful, since Cocoa tends to use NSError’s userInfo dictionary to present 
error information to the user, and ErrorProtocol contains no equivalent to the 
userInfo dictionary. The result of this is that when a Swift API throws an 
error, and this error is passed to Cocoa, the user tends to get a generic error 
message instead of something actually useful.

- The above problem means that a Swift developer must be very careful never to 
use “as NSError”, and to be sure to construct an NSError when throwing an error 
in an API that may be called from Objective-C, rather than simply throwing the 
error directly, or else the error will not be properly presented. If the 
developer makes a mistake here, it will not be known until runtime. I have 
personally wasted quite a bit of time trying to hunt down points in a 
complicated program where an error was accidentally converted to NSError via 
the bridge rather than explicitly.

- The same problem also puts the Swift developer between a rock and a hard 
place, if they have other code that wants to check these errors. In a 
pure-Swift program, checking against a particular error can often be done 
simply via an equality check. If the error has been converted to NSError via 
the bridge, this also works, since the bridge will return the original Swift 
error when casted. However, if the API that threw the error has been 
conscientious about constructing an NSError to avoid the userInfo issue, the 
NSError will not be easily castable back to the original Swift error type. 
Instead, the developer will have to compare the NSError’s error domain and 
code. The code itself will have to have been assigned by the throwing API. As 
the domain is stringly-typed and the code will often be extraneous to the 
actual error definition, this is all very runtime-dependent and can easily 
become incorrect or out of sync, which will break the program’s error reporting.

- The UI for creating NSError objects is extremely verb

Re: [swift-evolution] Referencing zero-parameter functions

[Xiaodi Wu via swift-evolution]

Can I offer a more verbose alternative? How's `foo() -> _` for referring to
a zero-parameter function? It's clearly not a function call, and it says
you want to match regardless of what the return value is...

On Thu, May 5, 2016 at 1:06 PM, Alex Hoppen via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 05 May 2016, at 19:38, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>
> >>> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <
> swift-evolution@swift.org> wrote:
>  Say you have the function `foo() -> Int`. Then `foo()` calls `foo`
> and returns its return value of type `Int` – not a reference to the
> function of type `Void -> Int`.
> >>>
> >>> Right.
> >>>
> >>> That said, what is wrong with just “foo”?
> >>
> >> As pointed out in the original post, that can refer to both ‘foo()’ and
> ‘foo(bar:)’ today.
> >
> > We could change that, so that to refer to `foo(bar:)` you must use the
> full compound name.
> >
> > -Joe
>
> That would be my second favourite option if there is no support for
> `foo(_)`, which there doesn’t seem to be. If there is support for letting
> `foo` refer to the zero-parameter function, I will change the proposal.
>
> – Alex
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Reference equivalent to value-type 'enum'

[Joshua Kopin via swift-evolution]

+1 -- at the very least, this strikes me as an exciting and provocative 
new angle from which to look at the value / reference / subtype / 
pattern matching problem space that's been discussed on this list.


On 4 May 2016, at 15:25, Matthew Johnson via swift-evolution wrote:

On May 4, 2016, at 4:46 PM, Austin Zheng via swift-evolution 
 wrote:


Hello swift-evolution:

Based on recent conversations on the list, I'd like to float a trial 
balloon: an "enum class" kind which is analogous to classes in the 
same way existing enums are to structs. This is a data type which 
allows the user to define a number of cases, like enums, and can 
participate in pattern matching and exhaustivity analysis. Instances 
of an enum class are reference types, which enables (for example) 
graph nodes with a built-in concept of identity.


To be slightly more fanciful, perhaps such a kind could be treated as 
an 'almost-final' class, with each case being a nested type which is 
defined as a final subclass of the enum class. Cases could then 
define their own behavior:


enum class GraphNode {
  case Node(left: GraphNode, right: GraphNode) {
override func foo() { ... }
func nodeSpecificMethod() { ... }
  }

  case Leaf {
override func foo() { ... }
func leafSpecificMethod() { ... }
  }

  func foo() { ... }
}

let x : GraphNode = GraphNode.newEmptyTree()
let y : GraphNode = GraphNode.Node(l, r)
let z : GraphNode = GraphNode.Leaf()
let a : GraphNode.Leaf = GraphNode.Leaf()

Enum classes would not be subclassible, and extensions would not be 
able to define new cases (as is the case with normal enums at the 
present time).


My superficial analysis seems to suggest that this would solve two 
issues: providing a reference-semantics type with all the pattern 
matching functionality of current enums, and providing a construct 
for modeling case-class style ADTs where each case should be treated 
as a subtype (as has been occasionally proposed).


I would like feedback as to:
- Whether this is something that would be useful enough to justify 
additional language features
- Whether this is something that would be theoretically well-founded 
and elegant




This is definitely an idea worth exploring.  I am interested in 
hearing from folks who have experience with Scala case classes.  How 
have you found them useful in ways that Swift’s current enums do not 
address?




Thanks for your time, and have a great day!

Austin


___
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

[swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Following a short discussion with positive feedback on 
[swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812) I’d like 
to discuss the following:

Tuples should be destructible into their components in parameter lists.

Consider the following code:

let a = [0,1,2,3,4,5,6,7,8,9]
let b = [0,1,2,3,4,5,6,7,8,9]

let c = zip(a,b).reduce(0) { acc, tuple in
  acc + tuple.0 + tuple.1
}

tuple is of type (Int, Int).

The problem is that the calculation is not very comprehensible due to .0 and 
.1. That’s when destructuring tuples directly in the parameter list comes into 
play:

let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
  acc + valueA + valueB
}

The above is what I propose should be accepted by the compiler (but currently 
isn’t).

Currently tuple destructuring is possible like this:

let c = zip(a,b).reduce(0) { (acc, tuple) in
  let (valueA, valueB) = tuple
  return acc + valueA + valueB
}

This is not about saving one line ;-). I just find it much more intuitive to 
destructure the tuple in the parameter list itself.

The same thing could be done for functions:

func takesATuple(someInt: Int, tuple: (String, String))

Here we also need to destructure the tuple inside the function, but the 
intuitive place (at least for me) to do this would be the parameter list.

In the following example I'm making use of Swift’s feature to name parameters 
different from their labels (for internal use inside the function, this is not 
visible to consumers of the API):

func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

Here valueA and valueB would be directly usable within the function. The tuple 
as a whole would not be available anymore.


Now it’s your turn!

1. What do you think?
2. Is this worth being discussed now (i.e. is it implementable in the Swift 3 
timeframe) or should I delay it?

Cheers,

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

Re: [swift-evolution] multi-line string literals.

[L Mihalkovic via swift-evolution]

> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi,
> 
> it's not a secret that I'm not a big fan of the proposal. The third draft 
> doesn't change this and it's unlikely that any future draft will, because for 
> me, the problem are the continuation quotes, and for Brent it seems like they 
> are a must-have-feature (correct me if I'm wrong.)
> 
> I just wanted to say that I have drafted a proposal that solves the issues 
> that I have encountered. (It's here: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
>  )
> - it allows pasting text as-is
> - it allows creating string literals where leading space on each line is 
> stripped (while keeping indentation differences intact)
> - it allows creating string literals where leading space on each line is not 
> stripped
> - optionally it allows strings to be raw, without any string interpolation or 
> escaping whatsoever
> - in none of the literals you have to write "", 
> you can just write "". This also lets you 
> copy&paste text out of the program source and back into a HTML file.
> 
> It had the idea that maybe the motivation behind continuation quotes is to 
> make using multiline strings harder to use; in order to discourage their use 
> at all. Two points to consider:
> - people who don't want to use MSL will not, even if you throw Python-like 
> """multi-line strings""" at them.
> - people who want to use them do it, even if there is no MSL available. I saw 
> that in Objective-C, with multiple lines of HTML and CSS wrapped into a big 
> multiline objc-string-literal and thrown at a WebView. I could send the 
> literal to the console before sending it to the WebView and it was basically 
> unreadable. I eventually refactored it to put the thing into a file (also 
> because the HTML grew in space, and the inline-literal became impractical)
> - my most important point: if someone uses multiple lines of HTML or CSS or 
> XML directly within the code, I want it to look okay. I don't want an MSL 
> feature that is so unwieldy that people voluntarily not use it; it would be 
> better to have no MSL at all.
> 
> I don't think that multiline strings are a must-have feature for a language, 
> because they are not used very often. (I included an example of a good use 
> case in my proposal.) I acknowledge that in many programming cases it would 
> be better to not put a huge pile of text directly into the source, but to 
> load the text from a file at runtime. But even when these MSL are misused, I 
> prefer to read a """python multiline string""" over a 
> "concatenated\n"+"Java\n"+"String".
> 
> -Michael


Hi Michael. hope this helps  
https://gist.github.com/lmihalkovic/11f2b1b23b78bbb9cbf0292ffc480b3d


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

Re: [swift-evolution] Referencing zero-parameter functions

[Alex Hoppen via swift-evolution]

> On 05 May 2016, at 19:38, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution 
>>>  wrote:
 Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
 returns its return value of type `Int` – not a reference to the function 
 of type `Void -> Int`. 
>>> 
>>> Right.
>>> 
>>> That said, what is wrong with just “foo”?
>> 
>> As pointed out in the original post, that can refer to both ‘foo()’ and 
>> ‘foo(bar:)’ today.
> 
> We could change that, so that to refer to `foo(bar:)` you must use the full 
> compound name.
> 
> -Joe

That would be my second favourite option if there is no support for `foo(_)`, 
which there doesn’t seem to be. If there is support for letting `foo` refer to 
the zero-parameter function, I will change the proposal.

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

Re: [swift-evolution] multi-line string literals.

[Doug McKenna via swift-evolution]

It was not obvious reading this proposal whether comment lines or empty lines 
could be inserted in the middle of the multi-line string (MLS).

For instance, would the following be syntactically legal or not:

let cat = "

  /* Add as many book specs here as you want */

  " 
  " \(author)
  " 

  // More to come

  ""


As someone who has had to write C source code that outputs boilerplate and 
customized code in another language, I think it should be legal to comment on 
the structure of a multi-line string at the most direct and appropriate spot 
within that string, without ill effect, as illustrated above.

What this means is that the failure to end a line with a " when that line 
begins with " means looking ahead not just to the next input line, but to the 
next non-blank (after stripping any comments and/or trailing whitespace) line 
that begins with a " (legal continuation of MLS), or anything else (illegal 
continuation of MLS).


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

Re: [swift-evolution] Referencing zero-parameter functions

[Joe Groff via swift-evolution]

> On May 5, 2016, at 10:16 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution 
>>  wrote:
>>> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
>>> returns its return value of type `Int` – not a reference to the function of 
>>> type `Void -> Int`. 
>> 
>> Right.
>> 
>> That said, what is wrong with just “foo”?
> 
> As pointed out in the original post, that can refer to both ‘foo()’ and 
> ‘foo(bar:)’ today.

We could change that, so that to refer to `foo(bar:)` you must use the full 
compound name.

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

Re: [swift-evolution] Referencing zero-parameter functions

[Jordan Rose via swift-evolution]

> On May 5, 2016, at 10:03, Chris Lattner via swift-evolution 
>  wrote:
> 
> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution 
>  wrote:
>> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
>> returns its return value of type `Int` – not a reference to the function of 
>> type `Void -> Int`. 
> 
> Right.
> 
> That said, what is wrong with just “foo”?

As pointed out in the original post, that can refer to both ‘foo()’ and 
‘foo(bar:)’ today.

Jordan

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

Re: [swift-evolution] Referencing zero-parameter functions

[Kurt Werle via swift-evolution]

On Thu, May 5, 2016 at 10:03 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and
> returns its return value of type `Int` – not a reference to the function of
> type `Void -> Int`.
>
> Right.
>
> That said, what is wrong with just “foo”?
>

Yeah, that'd work.  The problems:
* Name collisions with variables (not a big deal, I think)
* "foo" looks substantially different than "bar(baz:)", but they mean the
same thing

I prefer something like #foo(), #bar(baz:).  Clearly that particular choice
can't work.

Kurt
-- 
k...@circlew.org
http://www.CircleW.org/kurt/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Joe Groff via swift-evolution]

> On May 5, 2016, at 10:03 AM, Dave Abrahams  wrote:
> 
> 
> on Thu May 05 2016, Joe Groff  wrote:
> 
>>> On May 5, 2016, at 8:56 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Wed May 04 2016, Joe Groff  wrote:
>>> 
>> 
> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> Something about your first paragraph reminded me of a question I've
> had for a while. Is there a reasoning behind not being able to
> restrict a protocol to value types? One way that this might be
> workable is if we could overload protocols for Value vs for
> reference.
 
 I'm not totally comfortable with this, because references are a kind
 of value. 
>>> 
>>> We're using the word “value” in 3 different ways now.  If we don't sort
>>> them out, this is going to become impossible to resolve.  So let me
>>> propose some terms:
>>> 
>>> 1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
>>>  value of type T is essentially what an UnsafePointer points at.
>>>  In this sense, a variable of any type T “has a value.”  Even though
>>>  it's not strictly correct (since the term really applies to
>>>  expressions), I propose “rvalue” for this one.  
>>> 
>>> 2. The “value types vs reference types” sense, where every type falls
>>>  into one of two crisp buckets based on how it's declared.  I propose
>>>  we always say “reference type” or “value type” for this one.
>>> 
>>> 3. The “value semantics vs reference semantics” sense, where a type's
>>>  category depends on how it is implemented,  and it's possible (though
>>>  inadvisable) to fall outside either bucket.  This is the only
>>>  interesting category when you're discussing protocols and
>>>  constraints, and doesn't have any intrinsic relationship to sense
>>>  #2.  I propose we always say “value semantics” or “reference
>>>  semantics” for this one.
>> 
>> I claim that my sense is the same as #2. A reference has all the
>> properties of a value-type value; it has the additional ability to be
>> used as a handle to access independent program state. Int isn't any
>> less of a value because it can be used to reference values in an
>> array. 
> 
> It's less of a value in sense #2 because 
> 
>  x as Any as? AnyObject
> 
> is always nil for a value in sense #2.
> 
>> Rather than try to break the world down according to categories of
>> types, I think it's more effective to look at the semantics of
>> *operations*. So called "reference types" have value semantics
>> operations too; 
> 
> Please define the term “value semantics operation.”  I wager there is no
> such thing.

A mutating operation with no other side effects than modifying the values of 
its 'inout' parameters.

> 
>> reassigning a class reference, '+='-ing a pointer,
> 
> A pointer is a value type in every sense of the word.
> 
>> and adding or removing elements from an Array of references are all
>> operations that mutate only the value being operated on, even though
>> none of these types are strictly "value types".
> 
> Now you're really blending meanings, or at least being very fuzzy.  Your
> Array of references has a sense #1 value that might not even be altered
> when you change the elements in the array.  It is a sense #2 value by
> language rules.  It almost has sense #3 value semantics but for our
> inability to compare it with "==", because we don't implicitly get "=="
> defined in terms of "===" for all classes.
> 
> Saying something has value semantics is meaningless without a way to
> determine equivalence that respects the boundaries of the value.  The
> *whole point* of value semantics is that initialization, assignment,
> parameter passing, and returning all create *independent* instances, with
> no observable shared state, and that can be read and mutated
> concurrently in different threads.  To even test that, you need to nail
> down what it means for a value to change, and for that, you need an
> equality comparison.

What I'm trying to say is that there are "boundaries of the value" for 
everything in our system. For class references, that boundary happens to only 
include the reference itself.

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

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Jordan Rose via swift-evolution]

Terminology-wise, most of these are not acronyms 
 (or initialisms 
), but you’re right that that’s 
a third option consistent with the existing guidelines.

Jordan

> On May 5, 2016, at 08:56, Basem Emara  wrote:
> 
> Yes I digress and agree with you consistency is absolute key. Another thought 
> came to mind:
> 
> Option 3 3: Uppercase all acronyms including those with mixed casing. This is 
> both consistent and clear. Isolating acronyms is important because they loose 
> their meaning and bleed into word boundaries, so making even mixed acronyms 
> all uppercase clearly identifies them. In context, that might be 
> “supportsIPAD”, “LATEXRenderer”, “isNEXTPlatform”, and “signalingNAN”, 
> alongside “IPADIcon”, “LATEXSource”, “NEXTLogo”, and “NANValue”.)
> 
>> On May 5, 2016, at 11:41 AM, Jordan Rose > > wrote:
>> 
>> [resending to include list]
>> 
>> Hm. I’m not sure why these words would be special, though—if we were going 
>> to use underscores, shouldn’t we consistently go for “snake_case” or 
>> something?
>> 
>> (A leading underscore is also often used to denote something private in a 
>> lot of conventions, including the standard library.)
>> 
>> Jordan
>> 
>> 
>>> On May 5, 2016, at 08:38, Basem Emara >> > wrote:
>>> 
>>> Indeed the scenario has always been tricky for conventions. In both option 
>>> 1 and 2, it looses the meaning, so I propose option 3 (which still sux too 
>>> ha):
>>> 
>>> Option 3: Surround with underscores to isolate the acronym with mixed 
>>> casing. It clearly retains the original meaning since acronys already 
>>> create ambigiouty. An added degree of ambiguity could lose it’s meaning 
>>> complete. This way with underscores, it is clear what it is referring to. 
>>> In context, that might be “supports_iPad”, “_LaTeX_Renderer”, 
>>> “is_NeXT_Platform”, and “signaling_NaN”, alongside “_iPad_Icon”, 
>>> “_LaTeX_Source”, “_NeXT_Logo”, and “_NaN_Value”.)
>>> 
 On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hi, everyone. Today in the API Design Guidelines 
  we have this 
 section on case:
 
> Follow case conventions. Names of types and protocols are UpperCamelCase. 
> Everything else is lowerCamelCase.
> 
> Acronyms and initialisms that commonly appear as all upper case in 
> American English should be uniformly up- or down-cased according to case 
> conventions:
> 
> var utf8Bytes: [UTF8.CodeUnit]
> var isRepresentableAsASCII = true
> var userSMTPServer: SecureSMTPServer
> 
> Other acronyms should be treated as ordinary words:
> 
> var radarDetector: RadarScanner
> var enjoysScubaDiving = true
 
 However, this doesn't directly address words that are conventionally 
 written with mixed case. Usually these are names, such as "iPad", "LaTeX", 
 or “NeXT”, but sometimes they’re just acronyms or initialisms with very 
 strong conventions, like “NaN”. (Yes, the FloatingPoint proposal is what 
 prompted this whole thing.)
 
 There are a few options for what we could do with these words to make them 
 consistent with our existing rules for words that are all-uppercase, 
 all-lowercase, or capitalized (first letter uppercase, remaining letters 
 lowercase). It’s pretty clear from the “utf8Bytes” example above that use 
 at the start of a “lowerCamelCase” identifier means uniformly downcasing 
 all of the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear 
 exactly what operation is being applied to subsequent words in an 
 identifier:
 
 Option 1: Upcase the first letter, leave all the other letters alone. This 
 is consistent with all of the examples shown in the API design guidelines, 
 and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might 
 be “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
 alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)
 
 Option 2: If any letters are lowercase, upcase the first letter and 
 downcase all other letters. This is also consistent with all of the 
 examples shown in the API design guidelines, and produces “Ipad”, “Latex”, 
 “Next”, and “Nan”. (In context, that’s “supportsIpad”, “LatexRenderer”, 
 “isNextPlatform”, and “signalingNan”, alongside “ipadIcon”, “latexSource”, 
 “nextLogo”, and “nanValue”.)
 
 I prefer option 1 because I think it’s easier to recognize the original 
 form of the word; DaveA notes that under option 2 it’s easier to find the 
 word boundaries.
 
 (“NeXT” is an especially tricky case because without case it’s not 
 distinguishable from the normal word “next”. This

Re: [swift-evolution] Referencing zero-parameter functions

[Jordan Rose via swift-evolution]

I agree with Xiaodi about the syntax. We should not use ‘_’ here for the same 
reason that we do use it for label-less parameters: it makes every argument 
always marked by at least two characters. That makes it easier to read and 
harder to typo.

I do see that there’s a problem between ‘foo()’ (a reference to a function with 
no arguments) and ‘foo()’ (the result of calling a function with no arguments).

I’m personally not so inclined to worry about the “reference to a function” 
syntax; I’ve ultimately fallen into the camp that prefers a wrapper closure in 
most cases. The selector case is a little different. If we ban general 
expressions there, then I think there’s no problem with it being mistaken for 
an actual call, because nothing in #selector would act like a call anyway. If 
we don’t, it’d still be unambiguous…but I agree that it could be confusing.

Jordan


> On May 5, 2016, at 09:34, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I disagree. Not having a parameter label implies presence of a parameter. It 
> is not natural at all to use the same symbol to denote absence of a 
> parameter. `foo(_)` is a single typo away from `foo(_:)`.
> 
> IMO, after arbitrary expressions are removed from #selector, it is 
> straightforwardly a bug that `foo()` cannot be used to denote a function with 
> no parameters.
> On Thu, May 5, 2016 at 10:59 Alex Hoppen via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
> returns its return value of type `Int` – not a reference to the function of 
> type `Void -> Int`.
> 
> As to `_`: Like I stated in the proposal the underscore is already used in 
> functions to state that there is no parameter name. So I think it’s a natural 
> extension to also use it for saying that there are no arguments at all.
> 
> – Alex
> 
> > On 05 May 2016, at 17:21, David Sweeris  > > wrote:
> >
> > What’s wrong with `foo()` again? To me, a `_` in the parameter list means 
> > that something is there, but the label doesn’t matter.
> >
> > - Dave Sweeris
> ___
> 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] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Thu May 05 2016, Joe Groff  wrote:

>> On May 5, 2016, at 8:56 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed May 04 2016, Joe Groff  wrote:
>> 
>
 On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
  wrote:
 
 Something about your first paragraph reminded me of a question I've
 had for a while. Is there a reasoning behind not being able to
 restrict a protocol to value types? One way that this might be
 workable is if we could overload protocols for Value vs for
 reference.
>>> 
>>> I'm not totally comfortable with this, because references are a kind
>>> of value. 
>> 
>> We're using the word “value” in 3 different ways now.  If we don't sort
>> them out, this is going to become impossible to resolve.  So let me
>> propose some terms:
>> 
>> 1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
>>   value of type T is essentially what an UnsafePointer points at.
>>   In this sense, a variable of any type T “has a value.”  Even though
>>   it's not strictly correct (since the term really applies to
>>   expressions), I propose “rvalue” for this one.  
>> 
>> 2. The “value types vs reference types” sense, where every type falls
>>   into one of two crisp buckets based on how it's declared.  I propose
>>   we always say “reference type” or “value type” for this one.
>> 
>> 3. The “value semantics vs reference semantics” sense, where a type's
>>   category depends on how it is implemented,  and it's possible (though
>>   inadvisable) to fall outside either bucket.  This is the only
>>   interesting category when you're discussing protocols and
>>   constraints, and doesn't have any intrinsic relationship to sense
>>   #2.  I propose we always say “value semantics” or “reference
>>   semantics” for this one.
>
> I claim that my sense is the same as #2. A reference has all the
> properties of a value-type value; it has the additional ability to be
> used as a handle to access independent program state. Int isn't any
> less of a value because it can be used to reference values in an
> array. 

It's less of a value in sense #2 because 

  x as Any as? AnyObject

is always nil for a value in sense #2.

> Rather than try to break the world down according to categories of
> types, I think it's more effective to look at the semantics of
> *operations*. So called "reference types" have value semantics
> operations too; 

Please define the term “value semantics operation.”  I wager there is no
such thing.

> reassigning a class reference, '+='-ing a pointer,

A pointer is a value type in every sense of the word.

> and adding or removing elements from an Array of references are all
> operations that mutate only the value being operated on, even though
> none of these types are strictly "value types".

Now you're really blending meanings, or at least being very fuzzy.  Your
Array of references has a sense #1 value that might not even be altered
when you change the elements in the array.  It is a sense #2 value by
language rules.  It almost has sense #3 value semantics but for our
inability to compare it with "==", because we don't implicitly get "=="
defined in terms of "===" for all classes.

Saying something has value semantics is meaningless without a way to
determine equivalence that respects the boundaries of the value.  The
*whole point* of value semantics is that initialization, assignment,
parameter passing, and returning all create *independent* instances, with
no observable shared state, and that can be read and mutated
concurrently in different threads.  To even test that, you need to nail
down what it means for a value to change, and for that, you need an
equality comparison.

> -Joe
>
>>> I can see value in there being some kind of PureValue protocol, for
>>> types that represent fully self-contained values, but conforming to
>>> that protocol requires a bit more thought than just being a struct or
>>> enum, since there are structs that have reference semantics (such as
>>> UnsafePointer), and there are hybrid value types that contain
>>> references to data that isn't part of the value (an Array, for
>>> instance).
>>> 
>>> -Joe
>>> 
 TJ
 
 On Tue, May 3, 2016 at 11:02 PM, Jordan Rose  wrote:
 Dave and I have pondered this before, and considered that one possible 
 (drastic) solution is to ban classes from implementing protocols with 
 mutating members, on the grounds that it’s very hard to write an algorithm 
 that’s correct for both.
 
 func removing(_ element: Element) -> Self {
  var result = self // not necessarily a copy…
  result.remove(element)
  return result // not necessarily an independent value
 }
 
 func zapBadElements>>> C.Generator.Element == Int>(_ nums: inout C) {
  // requires inout on ‘nums’  even when it’s a class
  for i in nums.indices {
if nums[i] < 0 {
  nums.removeAtIndex(i)
}
  }
  // …because of this.
  if nums.lazy.

Re: [swift-evolution] Referencing zero-parameter functions

[Chris Lattner via swift-evolution]

On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution 
 wrote:
> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and 
> returns its return value of type `Int` – not a reference to the function of 
> type `Void -> Int`. 

Right.

That said, what is wrong with just “foo”?

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

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

[Eric Miller via swift-evolution]

Nor I. This syntax is excellent, thanks Krzysztof.

On Thu, May 5, 2016 at 9:56 AM, David Sweeris  wrote:

> Oh, cool! I didn’t realize this syntax existed.
>
> On May 5, 2016, at 10:52 AM, Krzysztof Siejkowski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It doesn’t compile because you’re switching on the Optional and trying to
> pattern match it to Coin.
>
> It compiles right when you pattern match it to Optional:
>
> switch result {
> case .heads?: print("heads")
> case .tails?: print("tails")
> case nil: print("not yet flipped")
> }
>
> Best,
> Krzysztof
>
> On 5 May 2016 at 17:42:24, Eric Miller via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Wondering if you guys think this is a reasonable idea.
>
> I was switching on an optional enum today, and naturally gravitated
> towards including nil as a case:
>
> enum Coin {
>   case heads
>   case tails
> }
> var result: Coin?
>
> switch result {
> case heads: print("heads")
> case tails: print("tails")
> case nil: print("not yet flipped") // exhaustive
> }
>
> Doesn't compile, and of course I can if-let or guard to unwrap instead,
> but I like the compactness of this.
> ___
> 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] [Oversight] Reference types allow mutating methods through generics

[Matthew Johnson via swift-evolution]

> On May 5, 2016, at 11:06 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 5, 2016, at 8:56 AM, Dave Abrahams  wrote:
>> 
>> 
>> on Wed May 04 2016, Joe Groff  wrote:
>> 
 On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
  wrote:
 
 Something about your first paragraph reminded me of a question I've
 had for a while. Is there a reasoning behind not being able to
 restrict a protocol to value types? One way that this might be
 workable is if we could overload protocols for Value vs for
 reference.
>>> 
>>> I'm not totally comfortable with this, because references are a kind
>>> of value. 
>> 
>> We're using the word “value” in 3 different ways now.  If we don't sort
>> them out, this is going to become impossible to resolve.  So let me
>> propose some terms:
>> 
>> 1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
>>  value of type T is essentially what an UnsafePointer points at.
>>  In this sense, a variable of any type T “has a value.”  Even though
>>  it's not strictly correct (since the term really applies to
>>  expressions), I propose “rvalue” for this one.  
>> 
>> 2. The “value types vs reference types” sense, where every type falls
>>  into one of two crisp buckets based on how it's declared.  I propose
>>  we always say “reference type” or “value type” for this one.
>> 
>> 3. The “value semantics vs reference semantics” sense, where a type's
>>  category depends on how it is implemented,  and it's possible (though
>>  inadvisable) to fall outside either bucket.  This is the only
>>  interesting category when you're discussing protocols and
>>  constraints, and doesn't have any intrinsic relationship to sense
>>  #2.  I propose we always say “value semantics” or “reference
>>  semantics” for this one.
> 
> I claim that my sense is the same as #2. A reference has all the properties 
> of a value-type value; it has the additional ability to be used as a handle 
> to access independent program state. Int isn't any less of a value because it 
> can be used to reference values in an array. Rather than try to break the 
> world down according to categories of types, I think it's more effective to 
> look at the semantics of *operations*. So called "reference types" have value 
> semantics operations too; reassigning a class reference, '+='-ing a pointer, 
> and adding or removing elements from an Array of references are all 
> operations that mutate only the value being operated on, even though none of 
> these types are strictly "value types”.

The distinction between “reference as a value” and “value the reference points 
to” is a pretty important one.  All of the operations you discuss are really 
operations on the “reference as a value”. 

I think the reason we talk about *types* rather than *operations* having value 
semantics is because that tells us that *all* operations on any instance are 
going to have value semantics.  This means that *nobody else* is going to 
mutate the variable in question behind our back.  If the type has “reference 
semantic operations” we don’t have that guarantee today.  The fact that the 
type may also have some "value semantic operations" seems relatively 
unimportant.

One possible avenue for improvement in the language where this distinction 
could be useful is by allowing us to specify which operations have "value 
semantics" on reference types and allow us to designate specific *references* 
as being value semantic.  `let` wouldn’t work as that only means that the 
reference itself is immutable, not the value it refers to.  We would need some 
additional syntax to specify that the value the reference points to cannot be 
mutated.  Such a reference could only be assigned to when the compiler can 
prove it will refer to a value that has *no* existing mutable references.  This 
would allow us to capture the benefits of value semantics for specific 
*instances* of a reference type.

-Matthew


> 
> -Joe
> 
>>> I can see value in there being some kind of PureValue protocol, for
>>> types that represent fully self-contained values, but conforming to
>>> that protocol requires a bit more thought than just being a struct or
>>> enum, since there are structs that have reference semantics (such as
>>> UnsafePointer), and there are hybrid value types that contain
>>> references to data that isn't part of the value (an Array, for
>>> instance).
>>> 
>>> -Joe
>>> 
 TJ
 
 On Tue, May 3, 2016 at 11:02 PM, Jordan Rose  wrote:
 Dave and I have pondered this before, and considered that one possible 
 (drastic) solution is to ban classes from implementing protocols with 
 mutating members, on the grounds that it’s very hard to write an algorithm 
 that’s correct for both.
 
 func removing(_ element: Element) -> Self {
 var result = self // not necessarily a copy…
 result.remove(element)
 return result // not necessarily an independent value
 }
 

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[David Sweeris via swift-evolution]

> On May 5, 2016, at 10:59 AM, Dave Abrahams  wrote:
> 
> 
> on Wed May 04 2016, Matthew Johnson  wrote:
> 
>>> On May 4, 2016, at 4:16 PM, David Sweeris  wrote:
>>> 
>>> Having given it some more thought... Does "PureReference" make
>>> sense? What would it mean? At some point a reference has to, you
>>> know, actually refer to a concrete value. Otherwise it's just
>>> turtles all the way down.
>> 
>> In my thinking PureReference (or ImmutableObject) has semantics
>> indicating that the type is a value-semantic reference type.  I think
>> this could be quite useful in some cases.
> 
> Like what? To a first approximation, the only thing I can see this being
> useful for is Objective-C interop.  Aside from being an element of an
> NSArray, there's nothing a an immutable class can do that a struct
> can’t.
Generic “manager” singletons? Like maybe if you wanted to use something other 
than NSFileManager? I’m hazy enough on exactly what the singleton pattern means 
that I’m not sure it matters.

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

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

[Gwendal Roué via swift-evolution]

> Le 5 mai 2016 à 18:16, Dmitri Gribenko  a écrit :
> 
> On Thu, May 5, 2016 at 3:27 AM, Gwendal Roué  wrote:
 I quite expect being able to throw out of a @noescape(once) block. Maybe 
 the sentence "it must not be executed on any path that throws" should be 
 removed from the proposal, should it have the implications you describe.
 
 Here is below what I expect this proposal to allow. So you see one 
 problematic case?
>>> 
>>> Hi Gwendal,
>>> 
>>> What about the following case?
>>> 
>>> // Function which rethrows closure errors:
>>> func f1(closure: @noescape(once) () throws -> ()) rethrows {
>>> try closure()
>>> }
>>> 
>>> let x: AnyObject
>>> f1 {
>>> if someCondition() { x = MyClass() }
>>> if someOtherCondition() { throw MyError.Error() }
>>> x = MyOtherClass()
>>> }
>>> 
>>> How do you handle memory management for 'x' on the path that throws?
>>> If the rule is that upon returning from f1 via a throw the variable
>>> 'x' should not be initialized, then the closure passed to f1 has to
>>> guarantee the deinitialization.  But f1 accepts an arbitrary closure.
>> 
>> Hello Dmitri,
>> 
>> To reason about @noescape(once) functions, the easiest way is to replace 
>> them with `do`:
>> 
>>let x: AnyObject
>>do {
>>if someCondition() { x = MyClass() }
>>if someOtherCondition() { throw MyError.error }
>>x = MyOtherClass()
>>}
>> 
>> This code does not compile because x can't be initialized to MyOtherClass().
>> 
>> But I don't think this is your point. Your point was "how can the compiler 
>> handle memory management ?".
>> 
>> I can't answer this question, because I'm not competent enough. But if it 
>> can handle the do { … } case, can't it also handle the f { … } case?
> 
> The difference is that the do{} case is type checked and codegen'ed
> together with the rest of the function.  The f{} case has two
> functions that are type checked and codegen'ed more or less
> separately (the function that contains the call to f, and the closure
> itself).  Moreover, with do{} the placement of the code block is
> fixed.  With f{}, you can save a closure in a variable and then call
> f(myClosure).  How would that affect the rules?  How would you
> implement the desired analysis?
> 
> Dmitri

I just have two messages by Chris Lattner who did not seem to foresee any big 
trouble. Of course this does not mean there aren't any, even maybe some pretty 
difficult one. The second message addresses more precisely your memory handling 
concerns:

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008231.html
- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008598.html

Gwendal Roué

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

Re: [swift-evolution] Referencing zero-parameter functions

[Xiaodi Wu via swift-evolution]

I disagree. Not having a parameter label implies presence of a parameter.
It is not natural at all to use the same symbol to denote absence of a
parameter. `foo(_)` is a single typo away from `foo(_:)`.

IMO, after arbitrary expressions are removed from #selector, it is
straightforwardly a bug that `foo()` cannot be used to denote a function
with no parameters.
On Thu, May 5, 2016 at 10:59 Alex Hoppen via swift-evolution <
swift-evolution@swift.org> wrote:

> Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and
> returns its return value of type `Int` – not a reference to the function of
> type `Void -> Int`.
>
> As to `_`: Like I stated in the proposal the underscore is already used in
> functions to state that there is no parameter name. So I think it’s a
> natural extension to also use it for saying that there are no arguments at
> all.
>
> – Alex
>
> > On 05 May 2016, at 17:21, David Sweeris  wrote:
> >
> > What’s wrong with `foo()` again? To me, a `_` in the parameter list
> means that something is there, but the label doesn’t matter.
> >
> > - Dave Sweeris
> ___
> 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] [Review] SE-0073: Marking closures as executing exactly once

[Dmitri Gribenko via swift-evolution]

On Thu, May 5, 2016 at 3:27 AM, Gwendal Roué  wrote:
>>> I quite expect being able to throw out of a @noescape(once) block. Maybe 
>>> the sentence "it must not be executed on any path that throws" should be 
>>> removed from the proposal, should it have the implications you describe.
>>>
>>> Here is below what I expect this proposal to allow. So you see one 
>>> problematic case?
>>
>> Hi Gwendal,
>>
>> What about the following case?
>>
>> // Function which rethrows closure errors:
>> func f1(closure: @noescape(once) () throws -> ()) rethrows {
>>  try closure()
>> }
>>
>> let x: AnyObject
>> f1 {
>>  if someCondition() { x = MyClass() }
>>  if someOtherCondition() { throw MyError.Error() }
>>  x = MyOtherClass()
>> }
>>
>> How do you handle memory management for 'x' on the path that throws?
>> If the rule is that upon returning from f1 via a throw the variable
>> 'x' should not be initialized, then the closure passed to f1 has to
>> guarantee the deinitialization.  But f1 accepts an arbitrary closure.
>
> Hello Dmitri,
>
> To reason about @noescape(once) functions, the easiest way is to replace them 
> with `do`:
>
> let x: AnyObject
> do {
> if someCondition() { x = MyClass() }
> if someOtherCondition() { throw MyError.error }
> x = MyOtherClass()
> }
>
> This code does not compile because x can't be initialized to MyOtherClass().
>
> But I don't think this is your point. Your point was "how can the compiler 
> handle memory management ?".
>
> I can't answer this question, because I'm not competent enough. But if it can 
> handle the do { … } case, can't it also handle the f { … } case?

The difference is that the do{} case is type checked and codegen'ed
together with the rest of the function.  The f{} case has two
functions that are type checked and codegen'ed more or less
separately (the function that contains the call to f, and the closure
itself).  Moreover, with do{} the placement of the code block is
fixed.  With f{}, you can save a closure in a variable and then call
f(myClosure).  How would that affect the rules?  How would you
implement the desired analysis?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 5, 2016, at 10:59 AM, Dave Abrahams  wrote:
> 
> 
> on Wed May 04 2016, Matthew Johnson  wrote:
> 
>>> On May 4, 2016, at 4:16 PM, David Sweeris  wrote:
>>> 
>>> Having given it some more thought... Does "PureReference" make
>>> sense? What would it mean? At some point a reference has to, you
>>> know, actually refer to a concrete value. Otherwise it's just
>>> turtles all the way down.
>> 
>> In my thinking PureReference (or ImmutableObject) has semantics
>> indicating that the type is a value-semantic reference type.  I think
>> this could be quite useful in some cases.
> 
> Like what? To a first approximation, the only thing I can see this being
> useful for is Objective-C interop.  Aside from being an element of an
> NSArray, there's nothing a an immutable class can do that a struct
> can't.

Objective-C / cocoa interop is important enough to matter IMO.

> 
>> 
>> 
>>> 
>>> Sent from my iPhone
>>> 
 On May 4, 2016, at 13:32, Matthew Johnson  wrote:
 
 
> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On May 4, 2016, at 11:12, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> I can see value in there being some kind of PureValue protocol,
>> for types that represent fully self-contained values, but
>> conforming to that protocol requires a bit more thought than just
>> being a struct or enum, since there are structs that have
>> reference semantics (such as UnsafePointer), and there are hybrid
>> value types that contain references to data that isn't part of
>> the value (an Array, for instance).
>> 
>> -Joe
> 
> +1
> 
> I'd think that both "PureValue" and "PureReference" would be
> useful. Isn't it the mixed types that make for tricky mutation
> rules & serialization?
 
 I also like Joe’s idea.  It fits with the direction in Swift of attaching 
 semantics, not just syntax, to protocols.
 
 I was thinking of something pretty similar to your PureReference
 idea, but slightly different.  Pure / immutable references have
 value semantics.  With that in mind I was thinking of an
 ImmutableObject protocol which would inherit from both AnyObject
 and PureValue.
 
 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> Dave

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

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, Matthew Johnson  wrote:

>> On May 4, 2016, at 4:16 PM, David Sweeris  wrote:
>> 
>> Having given it some more thought... Does "PureReference" make
>> sense? What would it mean? At some point a reference has to, you
>> know, actually refer to a concrete value. Otherwise it's just
>> turtles all the way down.
>
> In my thinking PureReference (or ImmutableObject) has semantics
> indicating that the type is a value-semantic reference type.  I think
> this could be quite useful in some cases.

Like what? To a first approximation, the only thing I can see this being
useful for is Objective-C interop.  Aside from being an element of an
NSArray, there's nothing a an immutable class can do that a struct
can't.

>
>
>> 
>> Sent from my iPhone
>> 
>>> On May 4, 2016, at 13:32, Matthew Johnson  wrote:
>>> 
>>> 
 On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution 
  wrote:
 
 
> On May 4, 2016, at 11:12, Joe Groff via swift-evolution 
>  wrote:
> 
> I can see value in there being some kind of PureValue protocol,
> for types that represent fully self-contained values, but
> conforming to that protocol requires a bit more thought than just
> being a struct or enum, since there are structs that have
> reference semantics (such as UnsafePointer), and there are hybrid
> value types that contain references to data that isn't part of
> the value (an Array, for instance).
> 
> -Joe
 
 +1
 
 I'd think that both "PureValue" and "PureReference" would be
 useful. Isn't it the mixed types that make for tricky mutation
 rules & serialization?
>>> 
>>> I also like Joe’s idea.  It fits with the direction in Swift of attaching 
>>> semantics, not just syntax, to protocols.
>>> 
>>> I was thinking of something pretty similar to your PureReference
>>> idea, but slightly different.  Pure / immutable references have
>>> value semantics.  With that in mind I was thinking of an
>>> ImmutableObject protocol which would inherit from both AnyObject
>>> and PureValue.
>>> 
>>> 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 

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

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

[Joe Groff via swift-evolution]

> On May 5, 2016, at 8:56 AM, Dave Abrahams  wrote:
> 
> 
> on Wed May 04 2016, Joe Groff  wrote:
> 
>>> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
>>>  wrote:
>>> 
>>> Something about your first paragraph reminded me of a question I've
>>> had for a while. Is there a reasoning behind not being able to
>>> restrict a protocol to value types? One way that this might be
>>> workable is if we could overload protocols for Value vs for
>>> reference.
>> 
>> I'm not totally comfortable with this, because references are a kind
>> of value. 
> 
> We're using the word “value” in 3 different ways now.  If we don't sort
> them out, this is going to become impossible to resolve.  So let me
> propose some terms:
> 
> 1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
>   value of type T is essentially what an UnsafePointer points at.
>   In this sense, a variable of any type T “has a value.”  Even though
>   it's not strictly correct (since the term really applies to
>   expressions), I propose “rvalue” for this one.  
> 
> 2. The “value types vs reference types” sense, where every type falls
>   into one of two crisp buckets based on how it's declared.  I propose
>   we always say “reference type” or “value type” for this one.
> 
> 3. The “value semantics vs reference semantics” sense, where a type's
>   category depends on how it is implemented,  and it's possible (though
>   inadvisable) to fall outside either bucket.  This is the only
>   interesting category when you're discussing protocols and
>   constraints, and doesn't have any intrinsic relationship to sense
>   #2.  I propose we always say “value semantics” or “reference
>   semantics” for this one.

I claim that my sense is the same as #2. A reference has all the properties of 
a value-type value; it has the additional ability to be used as a handle to 
access independent program state. Int isn't any less of a value because it can 
be used to reference values in an array. Rather than try to break the world 
down according to categories of types, I think it's more effective to look at 
the semantics of *operations*. So called "reference types" have value semantics 
operations too; reassigning a class reference, '+='-ing a pointer, and adding 
or removing elements from an Array of references are all operations that mutate 
only the value being operated on, even though none of these types are strictly 
"value types".

-Joe

>> I can see value in there being some kind of PureValue protocol, for
>> types that represent fully self-contained values, but conforming to
>> that protocol requires a bit more thought than just being a struct or
>> enum, since there are structs that have reference semantics (such as
>> UnsafePointer), and there are hybrid value types that contain
>> references to data that isn't part of the value (an Array, for
>> instance).
>> 
>> -Joe
>> 
>>> TJ
>>> 
>>> On Tue, May 3, 2016 at 11:02 PM, Jordan Rose  wrote:
>>> Dave and I have pondered this before, and considered that one possible 
>>> (drastic) solution is to ban classes from implementing protocols with 
>>> mutating members, on the grounds that it’s very hard to write an algorithm 
>>> that’s correct for both.
>>> 
>>> func removing(_ element: Element) -> Self {
>>>  var result = self // not necessarily a copy…
>>>  result.remove(element)
>>>  return result // not necessarily an independent value
>>> }
>>> 
>>> func zapBadElements>> == Int>(_ nums: inout C) {
>>>  // requires inout on ‘nums’  even when it’s a class
>>>  for i in nums.indices {
>>>if nums[i] < 0 {
>>>  nums.removeAtIndex(i)
>>>}
>>>  }
>>>  // …because of this.
>>>  if nums.lazy.filter { $0 == 0 }.count > 5 {
>>>nums = C()
>>>  }
>>> }
>>> 
>>> var refCollection: SharedArrayOfSomeKind = …
>>> // either the variable ‘refCollection’ or the instance of 
>>> ‘SharedArrayOfSomeKind’ might be mutated…or both!
>>> zapBadElements(&refCollection)
>>> 
>>> There are of course ways to safely use a protocol with mutating 
>>> requirements with classes, namely if you only use them for mutation (i.e. 
>>> they’re only called from ‘mutating’ members or on ‘inout’ parameters) and 
>>> never rely on value copying (no assignment, no returning). Most simple 
>>> wrappers around mutating members would fall into this category.
>>> 
>>> We didn’t really develop the idea very far yet because there’s been more 
>>> pressing things to worry about. I’m bringing it up here because it’s an 
>>> important idea that shouldn’t get lost.
>>> 
>>> ---
>>> 
>>> In lieu of this, I and a few others brought up the “incorrect” behavior of 
>>> reassigning ‘self’ in a protocol extension when the model type is a class, 
>>> and got shot down. I don’t have those discussions on hand at the moment, 
>>> but I remember we deliberately decided to leave protocol extensions the way 
>>> they were, allowing them to reassign class references. I think it’s because 
>>> it means things like zapBadElements are mor

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 5, 2016, at 10:41 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [resending to include list]
> 
> Hm. I’m not sure why these words would be special, though—if we were going to 
> use underscores, shouldn’t we consistently go for “snake_case” or something?
> 

+1.  Mixing the two is just ugly IMO. I prefer snake case to camel case in 
general but it seems way too late to make that change in Swift now even if we 
wanted to and it would complicate import of Objective-C.  


> (A leading underscore is also often used to denote something private in a lot 
> of conventions, including the standard library.)
> 
> Jordan
> 
> 
>> On May 5, 2016, at 08:38, Basem Emara  wrote:
>> 
>> Indeed the scenario has always been tricky for conventions. In both option 1 
>> and 2, it looses the meaning, so I propose option 3 (which still sux too ha):
>> 
>> Option 3: Surround with underscores to isolate the acronym with mixed 
>> casing. It clearly retains the original meaning since acronys already create 
>> ambigiouty. An added degree of ambiguity could lose it’s meaning complete. 
>> This way with underscores, it is clear what it is referring to. In context, 
>> that might be “supports_iPad”, “_LaTeX_Renderer”, “is_NeXT_Platform”, and 
>> “signaling_NaN”, alongside “_iPad_Icon”, “_LaTeX_Source”, “_NeXT_Logo”, and 
>> “_NaN_Value”.)
>> 
>>> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> Hi, everyone. Today in the API Design Guidelines we have this section on 
>>> case:
>>> 
 Follow case conventions. Names of types and protocols are UpperCamelCase. 
 Everything else is lowerCamelCase.
 
 Acronyms and initialisms that commonly appear as all upper case in 
 American English should be uniformly up- or down-cased according to case 
 conventions:
 
 var utf8Bytes: [UTF8.CodeUnit]
 var isRepresentableAsASCII = true
 var userSMTPServer: SecureSMTPServer
 
 Other acronyms should be treated as ordinary words:
 
 var radarDetector: RadarScanner
 var enjoysScubaDiving = true
>>> 
>>> However, this doesn't directly address words that are conventionally 
>>> written with mixed case. Usually these are names, such as "iPad", "LaTeX", 
>>> or “NeXT”, but sometimes they’re just acronyms or initialisms with very 
>>> strong conventions, like “NaN”. (Yes, the FloatingPoint proposal is what 
>>> prompted this whole thing.)
>>> 
>>> There are a few options for what we could do with these words to make them 
>>> consistent with our existing rules for words that are all-uppercase, 
>>> all-lowercase, or capitalized (first letter uppercase, remaining letters 
>>> lowercase). It’s pretty clear from the “utf8Bytes” example above that use 
>>> at the start of a “lowerCamelCase” identifier means uniformly downcasing 
>>> all of the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear 
>>> exactly what operation is being applied to subsequent words in an 
>>> identifier:
>>> 
>>> Option 1: Upcase the first letter, leave all the other letters alone. This 
>>> is consistent with all of the examples shown in the API design guidelines, 
>>> and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might be 
>>> “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
>>> alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)
>>> 
>>> Option 2: If any letters are lowercase, upcase the first letter and 
>>> downcase all other letters. This is also consistent with all of the 
>>> examples shown in the API design guidelines, and produces “Ipad”, “Latex”, 
>>> “Next”, and “Nan”. (In context, that’s “supportsIpad”, “LatexRenderer”, 
>>> “isNextPlatform”, and “signalingNan”, alongside “ipadIcon”, “latexSource”, 
>>> “nextLogo”, and “nanValue”.)
>>> 
>>> I prefer option 1 because I think it’s easier to recognize the original 
>>> form of the word; DaveA notes that under option 2 it’s easier to find the 
>>> word boundaries.
>>> 
>>> (“NeXT” is an especially tricky case because without case it’s not 
>>> distinguishable from the normal word “next”. This situation is rare but not 
>>> nonexistent. Then again, “Apple” is not distinguishable from the normal 
>>> word “apple” either, and we seem to do fine there.)
>>> 
>>> Thoughts?
>>> Jordan
>>> 
>>> P.S. The rules also don’t special-case all-lowercase initialisms, like 
>>> “mph” (for “miles per hour”). Under either option above, we’d get “Mph”. If 
>>> we want some other behavior, 
>>> ___
>>> 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

Re: [swift-evolution] Referencing zero-parameter functions

[Alex Hoppen via swift-evolution]

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns 
its return value of type `Int` – not a reference to the function of type `Void 
-> Int`. 

As to `_`: Like I stated in the proposal the underscore is already used in 
functions to state that there is no parameter name. So I think it’s a natural 
extension to also use it for saying that there are no arguments at all.

– Alex

> On 05 May 2016, at 17:21, David Sweeris  wrote:
> 
> What’s wrong with `foo()` again? To me, a `_` in the parameter list means 
> that something is there, but the label doesn’t matter.
> 
> - Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Basem Emara via swift-evolution]

Yes I digress and agree with you consistency is absolute key. Another thought 
came to mind:

Option 3 3: Uppercase all acronyms including those with mixed casing. This is 
both consistent and clear. Isolating acronyms is important because they loose 
their meaning and bleed into word boundaries, so making even mixed acronyms all 
uppercase clearly identifies them. In context, that might be “supportsIPAD”, 
“LATEXRenderer”, “isNEXTPlatform”, and “signalingNAN”, alongside “IPADIcon”, 
“LATEXSource”, “NEXTLogo”, and “NANValue”.)

> On May 5, 2016, at 11:41 AM, Jordan Rose  wrote:
> 
> [resending to include list]
> 
> Hm. I’m not sure why these words would be special, though—if we were going to 
> use underscores, shouldn’t we consistently go for “snake_case” or something?
> 
> (A leading underscore is also often used to denote something private in a lot 
> of conventions, including the standard library.)
> 
> Jordan
> 
> 
>> On May 5, 2016, at 08:38, Basem Emara > > wrote:
>> 
>> Indeed the scenario has always been tricky for conventions. In both option 1 
>> and 2, it looses the meaning, so I propose option 3 (which still sux too ha):
>> 
>> Option 3: Surround with underscores to isolate the acronym with mixed 
>> casing. It clearly retains the original meaning since acronys already create 
>> ambigiouty. An added degree of ambiguity could lose it’s meaning complete. 
>> This way with underscores, it is clear what it is referring to. In context, 
>> that might be “supports_iPad”, “_LaTeX_Renderer”, “is_NeXT_Platform”, and 
>> “signaling_NaN”, alongside “_iPad_Icon”, “_LaTeX_Source”, “_NeXT_Logo”, and 
>> “_NaN_Value”.)
>> 
>>> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi, everyone. Today in the API Design Guidelines 
>>>  we have this 
>>> section on case:
>>> 
 Follow case conventions. Names of types and protocols are UpperCamelCase. 
 Everything else is lowerCamelCase.
 
 Acronyms and initialisms that commonly appear as all upper case in 
 American English should be uniformly up- or down-cased according to case 
 conventions:
 
 var utf8Bytes: [UTF8.CodeUnit]
 var isRepresentableAsASCII = true
 var userSMTPServer: SecureSMTPServer
 
 Other acronyms should be treated as ordinary words:
 
 var radarDetector: RadarScanner
 var enjoysScubaDiving = true
>>> 
>>> However, this doesn't directly address words that are conventionally 
>>> written with mixed case. Usually these are names, such as "iPad", "LaTeX", 
>>> or “NeXT”, but sometimes they’re just acronyms or initialisms with very 
>>> strong conventions, like “NaN”. (Yes, the FloatingPoint proposal is what 
>>> prompted this whole thing.)
>>> 
>>> There are a few options for what we could do with these words to make them 
>>> consistent with our existing rules for words that are all-uppercase, 
>>> all-lowercase, or capitalized (first letter uppercase, remaining letters 
>>> lowercase). It’s pretty clear from the “utf8Bytes” example above that use 
>>> at the start of a “lowerCamelCase” identifier means uniformly downcasing 
>>> all of the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear 
>>> exactly what operation is being applied to subsequent words in an 
>>> identifier:
>>> 
>>> Option 1: Upcase the first letter, leave all the other letters alone. This 
>>> is consistent with all of the examples shown in the API design guidelines, 
>>> and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might be 
>>> “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
>>> alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)
>>> 
>>> Option 2: If any letters are lowercase, upcase the first letter and 
>>> downcase all other letters. This is also consistent with all of the 
>>> examples shown in the API design guidelines, and produces “Ipad”, “Latex”, 
>>> “Next”, and “Nan”. (In context, that’s “supportsIpad”, “LatexRenderer”, 
>>> “isNextPlatform”, and “signalingNan”, alongside “ipadIcon”, “latexSource”, 
>>> “nextLogo”, and “nanValue”.)
>>> 
>>> I prefer option 1 because I think it’s easier to recognize the original 
>>> form of the word; DaveA notes that under option 2 it’s easier to find the 
>>> word boundaries.
>>> 
>>> (“NeXT” is an especially tricky case because without case it’s not 
>>> distinguishable from the normal word “next”. This situation is rare but not 
>>> nonexistent. Then again, “Apple” is not distinguishable from the normal 
>>> word “apple” either, and we seem to do fine there.)
>>> 
>>> Thoughts?
>>> Jordan
>>> 
>>> P.S. The rules also don’t special-case all-lowercase initialisms, like 
>>> “mph” (for “miles per hour”). Under either option above, we’d get “Mph”. If 
>>> we want some other behavior, 
>>> ___
>>> swift-evoluti

[swift-evolution] Switch on an optional enum -- `case: nil`?

[Eric Miller via swift-evolution]

Wondering if you guys think this is a reasonable idea.

I was switching on an optional enum today, and naturally gravitated towards
including nil as a case:

enum Coin {
  case heads
  case tails
}
var result: Coin?

switch result {
case heads: print("heads")
case tails: print("tails")
case nil: print("not yet flipped") // exhaustive
}

Doesn't compile, and of course I can if-let or guard to unwrap instead, but
I like the compactness of this.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Jordan Rose via swift-evolution]

[resending to include list]

Hm. I’m not sure why these words would be special, though—if we were going to 
use underscores, shouldn’t we consistently go for “snake_case” or something?

(A leading underscore is also often used to denote something private in a lot 
of conventions, including the standard library.)

Jordan


> On May 5, 2016, at 08:38, Basem Emara  > wrote:
> 
> Indeed the scenario has always been tricky for conventions. In both option 1 
> and 2, it looses the meaning, so I propose option 3 (which still sux too ha):
> 
> Option 3: Surround with underscores to isolate the acronym with mixed casing. 
> It clearly retains the original meaning since acronys already create 
> ambigiouty. An added degree of ambiguity could lose it’s meaning complete. 
> This way with underscores, it is clear what it is referring to. In context, 
> that might be “supports_iPad”, “_LaTeX_Renderer”, “is_NeXT_Platform”, and 
> “signaling_NaN”, alongside “_iPad_Icon”, “_LaTeX_Source”, “_NeXT_Logo”, and 
> “_NaN_Value”.)
> 
>> On May 5, 2016, at 11:26 AM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi, everyone. Today in the API Design Guidelines 
>>  we have this 
>> section on case:
>> 
>>> Follow case conventions. Names of types and protocols are UpperCamelCase. 
>>> Everything else is lowerCamelCase.
>>> 
>>> Acronyms and initialisms that commonly appear as all upper case in American 
>>> English should be uniformly up- or down-cased according to case conventions:
>>> 
>>> var utf8Bytes: [UTF8.CodeUnit]
>>> var isRepresentableAsASCII = true
>>> var userSMTPServer: SecureSMTPServer
>>> 
>>> Other acronyms should be treated as ordinary words:
>>> 
>>> var radarDetector: RadarScanner
>>> var enjoysScubaDiving = true
>> 
>> However, this doesn't directly address words that are conventionally written 
>> with mixed case. Usually these are names, such as "iPad", "LaTeX", or 
>> “NeXT”, but sometimes they’re just acronyms or initialisms with very strong 
>> conventions, like “NaN”. (Yes, the FloatingPoint proposal is what prompted 
>> this whole thing.)
>> 
>> There are a few options for what we could do with these words to make them 
>> consistent with our existing rules for words that are all-uppercase, 
>> all-lowercase, or capitalized (first letter uppercase, remaining letters 
>> lowercase). It’s pretty clear from the “utf8Bytes” example above that use at 
>> the start of a “lowerCamelCase” identifier means uniformly downcasing all of 
>> the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear exactly 
>> what operation is being applied to subsequent words in an identifier:
>> 
>> Option 1: Upcase the first letter, leave all the other letters alone. This 
>> is consistent with all of the examples shown in the API design guidelines, 
>> and produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might be 
>> “supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
>> alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)
>> 
>> Option 2: If any letters are lowercase, upcase the first letter and downcase 
>> all other letters. This is also consistent with all of the examples shown in 
>> the API design guidelines, and produces “Ipad”, “Latex”, “Next”, and “Nan”. 
>> (In context, that’s “supportsIpad”, “LatexRenderer”, “isNextPlatform”, and 
>> “signalingNan”, alongside “ipadIcon”, “latexSource”, “nextLogo”, and 
>> “nanValue”.)
>> 
>> I prefer option 1 because I think it’s easier to recognize the original form 
>> of the word; DaveA notes that under option 2 it’s easier to find the word 
>> boundaries.
>> 
>> (“NeXT” is an especially tricky case because without case it’s not 
>> distinguishable from the normal word “next”. This situation is rare but not 
>> nonexistent. Then again, “Apple” is not distinguishable from the normal word 
>> “apple” either, and we seem to do fine there.)
>> 
>> Thoughts?
>> Jordan
>> 
>> P.S. The rules also don’t special-case all-lowercase initialisms, like “mph” 
>> (for “miles per hour”). Under either option above, we’d get “Mph”. If we 
>> want some other behavior, 
>> ___
>> 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] Switch on an optional enum -- `case: nil`?

[David Sweeris via swift-evolution]

Oh, cool! I didn’t realize this syntax existed.

On May 5, 2016, at 10:52 AM, Krzysztof Siejkowski via swift-evolution 
 wrote:
> 
> It doesn’t compile because you’re switching on the Optional and trying to 
> pattern match it to Coin.
> 
> It compiles right when you pattern match it to Optional:
> 
> switch result {
> case .heads?: print("heads")
> case .tails?: print("tails")
> case nil: print("not yet flipped")
> }
> 
> Best,
> Krzysztof
> 
> On 5 May 2016 at 17:42:24, Eric Miller via swift-evolution 
> (swift-evolution@swift.org ) wrote:
> 
>> Wondering if you guys think this is a reasonable idea.
>> 
>> I was switching on an optional enum today, and naturally gravitated towards 
>> including nil as a case:
>> 
>> enum Coin {
>>   case heads
>>   case tails
>> }
>> var result: Coin?
>> 
>> switch result {
>> case heads: print("heads")
>> case tails: print("tails")
>> case nil: print("not yet flipped") // exhaustive
>> }
>> 
>> Doesn't compile, and of course I can if-let or guard to unwrap instead, but 
>> I like the compactness of this.
>> ___
>> 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] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, Joe Groff  wrote:

>> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> Something about your first paragraph reminded me of a question I've
>> had for a while. Is there a reasoning behind not being able to
>> restrict a protocol to value types? One way that this might be
>> workable is if we could overload protocols for Value vs for
>> reference.
>
> I'm not totally comfortable with this, because references are a kind
> of value. 

We're using the word “value” in 3 different ways now.  If we don't sort
them out, this is going to become impossible to resolve.  So let me
propose some terms:

1. Joe's sense, i.e. the compiler-implementation-level sense, in which a
   value of type T is essentially what an UnsafePointer points at.
   In this sense, a variable of any type T “has a value.”  Even though
   it's not strictly correct (since the term really applies to
   expressions), I propose “rvalue” for this one.  

2. The “value types vs reference types” sense, where every type falls
   into one of two crisp buckets based on how it's declared.  I propose
   we always say “reference type” or “value type” for this one.

3. The “value semantics vs reference semantics” sense, where a type's
   category depends on how it is implemented,  and it's possible (though
   inadvisable) to fall outside either bucket.  This is the only
   interesting category when you're discussing protocols and
   constraints, and doesn't have any intrinsic relationship to sense
   #2.  I propose we always say “value semantics” or “reference
   semantics” for this one.

> I can see value in there being some kind of PureValue protocol, for
> types that represent fully self-contained values, but conforming to
> that protocol requires a bit more thought than just being a struct or
> enum, since there are structs that have reference semantics (such as
> UnsafePointer), and there are hybrid value types that contain
> references to data that isn't part of the value (an Array, for
> instance).
>
> -Joe
>
>> TJ
>> 
>> On Tue, May 3, 2016 at 11:02 PM, Jordan Rose  wrote:
>> Dave and I have pondered this before, and considered that one possible 
>> (drastic) solution is to ban classes from implementing protocols with 
>> mutating members, on the grounds that it’s very hard to write an algorithm 
>> that’s correct for both.
>> 
>> func removing(_ element: Element) -> Self {
>>   var result = self // not necessarily a copy…
>>   result.remove(element)
>>   return result // not necessarily an independent value
>> }
>> 
>> func zapBadElements> == Int>(_ nums: inout C) {
>>   // requires inout on ‘nums’  even when it’s a class
>>   for i in nums.indices {
>> if nums[i] < 0 {
>>   nums.removeAtIndex(i)
>> }
>>   }
>>   // …because of this.
>>   if nums.lazy.filter { $0 == 0 }.count > 5 {
>> nums = C()
>>   }
>> }
>> 
>> var refCollection: SharedArrayOfSomeKind = …
>> // either the variable ‘refCollection’ or the instance of 
>> ‘SharedArrayOfSomeKind’ might be mutated…or both!
>> zapBadElements(&refCollection)
>> 
>> There are of course ways to safely use a protocol with mutating requirements 
>> with classes, namely if you only use them for mutation (i.e. they’re only 
>> called from ‘mutating’ members or on ‘inout’ parameters) and never rely on 
>> value copying (no assignment, no returning). Most simple wrappers around 
>> mutating members would fall into this category.
>> 
>> We didn’t really develop the idea very far yet because there’s been more 
>> pressing things to worry about. I’m bringing it up here because it’s an 
>> important idea that shouldn’t get lost.
>> 
>> ---
>> 
>> In lieu of this, I and a few others brought up the “incorrect” behavior of 
>> reassigning ‘self’ in a protocol extension when the model type is a class, 
>> and got shot down. I don’t have those discussions on hand at the moment, but 
>> I remember we deliberately decided to leave protocol extensions the way they 
>> were, allowing them to reassign class references. I think it’s because it 
>> means things like zapBadElements are more likely to work correctly^W as 
>> expected―if you don’t have any other references at the time you do the 
>> mutation, it can work. But yeah, I’m uncomfortable with the situation we’re 
>> in right now.
>> 
>> Jordan
>> 
>> 
>>> On May 3, 2016, at 13:09, James Froggatt via swift-evolution 
>>>  wrote:
>>> 
>>> Thanks for the response, I agree this is currently the best
>>> solution. Unfortunately, it's not just as simple as just
>>> implementing each method, since without being able to call super, I
>>> have to fully reimplement the original behaviour, which at best
>>> seems like bad practice, and would break in future versions of
>>> Swift, and at worst could lead to hard-to-detect bugs right now.
>>> 
>>> To recap for anyone reading, protocol extensions currently apply
>>> mutating methods unmodified to reference types, as I found trying
>>> to make a reference-type collecti

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

[David Sweeris via swift-evolution]

So… Is your idea that wrapping a SomeEnum in an Optional would add some 
“invalid” case to SomeEnum, or that switching on a SomeEnum? would be 
implicitly rewrite:
switch result {
case .heads: print("heads")
case .tails: print("tails")
case .none: print("not yet flipped") // exhaustive
}
to:
switch result {
case .none: print("not yet flipped")
case .some(let _result):
  switch _result {
  case .heads: print("heads")
  case .tails: print("tails")
  }
}

> On May 5, 2016, at 10:40 AM, Eric Miller via swift-evolution 
>  wrote:
> 
> Wondering if you guys think this is a reasonable idea.
> 
> I was switching on an optional enum today, and naturally gravitated towards 
> including nil as a case:
> 
> enum Coin {
>   case heads
>   case tails
> }
> var result: Coin?
> 
> switch result {
> case heads: print("heads")
> case tails: print("tails")
> case nil: print("not yet flipped") // exhaustive
> }
> 
> Doesn't compile, and of course I can if-let or guard to unwrap instead, but I 
> like the compactness of this.
> ___
> 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] Switch on an optional enum -- `case: nil`?

[Ross O'Brien via swift-evolution]

I was about to provide this, but Krzysztof's example is more compact than
mine:

enum Coin {

case heads

case tails

}

var result: Coin?


switch result {

case .Some(.heads): print("heads")

case .Some(.tails): print("tails")

case nil: print("not yet flipped") // exhaustive

}



On Thu, May 5, 2016 at 4:52 PM, Krzysztof Siejkowski via swift-evolution <
swift-evolution@swift.org> wrote:

> It doesn’t compile because you’re switching on the Optional and trying to
> pattern match it to Coin.
>
> It compiles right when you pattern match it to Optional:
>
> switch result {
>
> case .heads?: print("heads")
>
> case .tails?: print("tails")
>
> case nil: print("not yet flipped")
>
> }
>
> Best,
> Krzysztof
>
>
> On 5 May 2016 at 17:42:24, Eric Miller via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Wondering if you guys think this is a reasonable idea.
>
> I was switching on an optional enum today, and naturally gravitated
> towards including nil as a case:
>
> enum Coin {
>   case heads
>   case tails
> }
> var result: Coin?
>
> switch result {
> case heads: print("heads")
> case tails: print("tails")
> case nil: print("not yet flipped") // exhaustive
> }
>
> Doesn't compile, and of course I can if-let or guard to unwrap instead,
> but I like the compactness of this.
> ___
> 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

[swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Антон Жилин via swift-evolution]

Following my current cpp guidelines, I would suggest the following:

1. Make all letters of the abbreviation downcase
2. Make first letter uppercase if required

Examples: NanWrapper, getNan, nanGet, NextEmulator, emulateNext,
nextEmulate.

Although, this convention plays pretty hard on NeXT, I have to admit.

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

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

[Krzysztof Siejkowski via swift-evolution]

It doesn’t compile because you’re switching on the Optional and trying to 
pattern match it to Coin.

It compiles right when you pattern match it to Optional:

switch result {
case .heads?: print("heads")
case .tails?: print("tails")
case nil: print("not yet flipped")
}

Best,
Krzysztof

On 5 May 2016 at 17:42:24, Eric Miller via swift-evolution 
(swift-evolution@swift.org) wrote:

Wondering if you guys think this is a reasonable idea.

I was switching on an optional enum today, and naturally gravitated towards 
including nil as a case:

enum Coin {
  case heads
  case tails
}
var result: Coin?

switch result {
case heads: print("heads")
case tails: print("tails")
case nil: print("not yet flipped") // exhaustive
}

Doesn't compile, and of course I can if-let or guard to unwrap instead, but I 
like the compactness of this.
___
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] Make lazy an attribute

[Антон Жилин via swift-evolution]

I'm ready to submit a pull request:

https://github.com/Anton3/swift-evolution/blob/lazy-attribute/proposals/-lazy-attribute.md

- Anton

2016-05-03 0:25 GMT+03:00 David Sweeris :

> Yeah, I was just thinking that we should get the “call-site” syntax
> settled for property behaviors, for exactly that reason.
>
> > On May 2, 2016, at 3:39 PM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One of proposals that will probably be submitted for Swift 4, will be
> Property Behaviors propoal.
> >
> > It aims to generalize @IBOutlet, @synchronized, @delayedinit, and of
> course, @lazy.
> > (Side note: it would be great if it also included unowned)
> >
> > Because we aim for less breaking changes in Swift 4, we should prepare
> ground for it.
> > The suggestion is to rename `lazy` to `@lazy`.
> >
> > Besides the aforementioned reason, I think, lazy really has its place
> among attributes.
> > It does not change type of property, it just helps to delay side effects
> of initialization.
> >
> > - Anton
> > ___
> > 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] Case conventions for mixed-case words (like "iPad" and "NaN")

[David Sweeris via swift-evolution]

> On May 5, 2016, at 10:26 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> (“NeXT” is an especially tricky case because without case it’s not 
> distinguishable from the normal word “next”. This situation is rare but not 
> nonexistent. Then again, “Apple” is not distinguishable from the normal word 
> “apple” either, and we seem to do fine there.)
“Apple” isn’t the name of a common function for dealing with collections & 
sequences.

“NeXT” is probably rare enough that we could keep it as-written regardless of 
whatever we settle on for the rest. Personally, I prefer to use the correct 
(that is, whatever you’d normally use in written communication) camel case, 
capitalizing the first letter when necessary (such as “foo.isIPad”) and not 
bother worrying about it more than that unless doing so would make for an 
ambiguous name.

That said, I’ve never tried to take part in defining standard library naming 
conventions before... There’s a fair chance I’m not seeing an obvious problem, 
rather than merely disagreeing.

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

Re: [swift-evolution] [Pitch] make == more restrictive at compile time

[Joe Groff via swift-evolution]

> On May 5, 2016, at 2:24 AM, Gerd Castan via swift-evolution 
>  wrote:
> 
> Motivation:
> 
> The following code emits no compiler error in Swift 2.2:
> 
> import Foundation
> func EQTest(lhs: NSArray, rhs: String) -> Bool {
>return (lhs == rhs)
> }

This works because String can implicitly bridge to NSString, and both NSArray 
and NSString are subclasses of NSObject. SE-0072 proposes to remove the 
implicit bridging behavior, which would prevent this from compiling.

-Joe

> 
> 
> I can imagine no use case where this code example makes sense, so I
> would expect an error at compile time.
> 
> the function that makes this code valid is
> @warn_unused_result
> public func ==(lhs: T?, rhs: T?) -> Bool
> 
> 
> Proposal:
> 
> find a way for the compiler to emit an error for the code example.
> 
> 
> Discussion:
> 
> I can think of several ways to solve this:
> 
> 1. remove "public func ==(lhs: T?, rhs: T?) -> Bool" from
> the library
> 2. annotate "public func ==(lhs: T?, rhs: T?) -> Bool" so
> that the compiler emits an error in the cate that there is no more
> specific implementation.
> 
> I leave the way to implement this to a discussion since I'm not sure
> which one (or some completely different approach) will lead to a
> consistent language design.
> 
> I have the feeling that approach 2 is easier, better and gives more
> control since it moves the responsibility for the error handling from
> the compiler to the library where everybody (including the compiler) can
> read it.
> 
> There might be more functions like "public func ==(lhs:
> T?, rhs: T?) -> Bool" that lets the compiler accept nonsense tests for
> equality for more specific cases. They should be handled in a similar
> and consistent way if they exist.
> 
> This change is intended to let programers getting things done faster and
> with less coding errors in Swift.
> 
> 
> Gerd
> https://github.com/GerdC
> 
> 
> 
> 
> ___
> 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] [Oversight] Reference types allow mutating methods through generics

[Dave Abrahams via swift-evolution]

on Wed May 04 2016, "T.J. Usiyan"  wrote:

> Something about your first paragraph reminded me of a question I've had for a
> while. Is there a reasoning behind not being able to restrict a protocol to
> value types? 

There are two answers:

1. We haven't gotten around to it

2. As I mentioned elsewhere, that doesn't really have any meaning unless
   we also add some semantic restrictions, because a “value type” can have
   reference semantics. 

> One way that this might be workable is if we could overload protocols
> for Value vs for reference.
>
> TJ
>
> On Tue, May 3, 2016 at 11:02 PM, Jordan Rose  wrote:
>
> Dave and I have pondered this before, and considered that one possible
> (drastic) solution is to ban classes from implementing protocols with
> mutating members, on the grounds that it’s very hard to write an algorithm
> that’s correct for both.
>
> func removing(_ element: Element) -> Self {
> var result = self // not necessarily a copy…
> result.remove(element)
> return result // not necessarily an independent value
> }
>
> func zapBadElements C.Generator.Element == Int>(_ nums: inout C) {
> // requires inout on ‘nums’ even when it’s a class
> for i in nums.indices {
> if nums[i] < 0 {
> nums.removeAtIndex(i)
> }
> }
> // …because of this.
> if nums.lazy.filter { $0 == 0 }.count > 5 {
> nums = C()
> }
> }
>
> var refCollection: SharedArrayOfSomeKind = …
> // either the variable ‘refCollection’ or the instance of
> ‘SharedArrayOfSomeKind’ might be mutated…or both!
> zapBadElements(&refCollection)
>
> There are of course ways to safely use a protocol with mutating 
> requirements
> with classes, namely if you only use them for mutation (i.e. they’re only
> called from ‘mutating’ members or on ‘inout’ parameters) and never rely on
> value copying (no assignment, no returning). Most simple wrappers around
> mutating members would fall into this category.
>
> We didn’t really develop the idea very far yet because there’s been more
> pressing things to worry about. I’m bringing it up here because it’s an
> important idea that shouldn’t get lost.
>
> ---
>
> In lieu of this, I and a few others brought up the “incorrect” behavior of
> reassigning ‘self’ in a protocol extension when the model type is a class,
> and got shot down. I don’t have those discussions on hand at the moment, 
> but
> I remember we deliberately decided to leave protocol extensions the way 
> they
> were, allowing them to reassign class references. I think it’s because it
> means things like zapBadElements are more likely to work correctly^W as
> expected―if you don’t have any other references at the time you do the
> mutation, it can work. But yeah, I’m uncomfortable with the situation 
> we’re
> in right now.
>
> Jordan
>
> On May 3, 2016, at 13:09, James Froggatt via swift-evolution
>  wrote:
>
> Thanks for the response, I agree this is currently the best solution.
> Unfortunately, it's not just as simple as just implementing each 
> method,
> since without being able to call super, I have to fully reimplement 
> the
> original behaviour, which at best seems like bad practice, and would
> break in future versions of Swift, and at worst could lead to
> hard-to-detect bugs right now.
>
> To recap for anyone reading, protocol extensions currently apply
> mutating methods unmodified to reference types, as I found trying to
> make a reference-type collection. This results in the compiler
> disallowing ‘let’ when calling these functions, and allows methods to
> reassign the reference ‘self’ to a new object. The best solution is to
> manually implement each method, removing the mutating modifier, yet 
> this
> workaround doesn't extend to generic code.
>
> To fix this behaviour, we would need to distinguish between ‘true’
> mutating functions, which reassign self, and ‘partially’ mutating
> functions, for use in generics and protocol extensions, which can
> reassign properties only.
>
> Is there any support for making this change? Or are there any simpler
> solutions?
>
> I did submit a bug report, but I'm pretty sure a decent fix is not
> possible without some evolution of the language regarding the mutating
> keyword, so I'm trying to bring this up here in hope of us getting an
> actual solution. I've changed the title to what I hope is something 
> that
> better reflects the problem; this thread was originally titled
> ‘[swift-evolution] [Bug?] Reference types and mutating methods’.
>
> PS: I have noticed another side-effect of calling mutating fun

[swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

[Jordan Rose via swift-evolution]

Hi, everyone. Today in the API Design Guidelines 
 we have this section 
on case:

> Follow case conventions. Names of types and protocols are UpperCamelCase. 
> Everything else is lowerCamelCase.
> 
> Acronyms and initialisms that commonly appear as all upper case in American 
> English should be uniformly up- or down-cased according to case conventions:
> 
> var utf8Bytes: [UTF8.CodeUnit]
> var isRepresentableAsASCII = true
> var userSMTPServer: SecureSMTPServer
> 
> Other acronyms should be treated as ordinary words:
> 
> var radarDetector: RadarScanner
> var enjoysScubaDiving = true

However, this doesn't directly address words that are conventionally written 
with mixed case. Usually these are names, such as "iPad", "LaTeX", or “NeXT”, 
but sometimes they’re just acronyms or initialisms with very strong 
conventions, like “NaN”. (Yes, the FloatingPoint proposal is what prompted this 
whole thing.)

There are a few options for what we could do with these words to make them 
consistent with our existing rules for words that are all-uppercase, 
all-lowercase, or capitalized (first letter uppercase, remaining letters 
lowercase). It’s pretty clear from the “utf8Bytes” example above that use at 
the start of a “lowerCamelCase” identifier means uniformly downcasing all of 
the letters: “ipad”, “latex”, “next”, “nan”. However, it’s unclear exactly what 
operation is being applied to subsequent words in an identifier:

Option 1: Upcase the first letter, leave all the other letters alone. This is 
consistent with all of the examples shown in the API design guidelines, and 
produces “IPad”, “LaTeX”, “NeXT”, and “NaN”. (In context, that might be 
“supportsIPad”, “LaTeXRenderer”, “isNeXTPlatform”, and “signalingNaN”, 
alongside “ipadIcon”, “latexSource”, “nextLogo”, and “nanValue”.)

Option 2: If any letters are lowercase, upcase the first letter and downcase 
all other letters. This is also consistent with all of the examples shown in 
the API design guidelines, and produces “Ipad”, “Latex”, “Next”, and “Nan”. (In 
context, that’s “supportsIpad”, “LatexRenderer”, “isNextPlatform”, and 
“signalingNan”, alongside “ipadIcon”, “latexSource”, “nextLogo”, and 
“nanValue”.)

I prefer option 1 because I think it’s easier to recognize the original form of 
the word; DaveA notes that under option 2 it’s easier to find the word 
boundaries.

(“NeXT” is an especially tricky case because without case it’s not 
distinguishable from the normal word “next”. This situation is rare but not 
nonexistent. Then again, “Apple” is not distinguishable from the normal word 
“apple” either, and we seem to do fine there.)

Thoughts?
Jordan

P.S. The rules also don’t special-case all-lowercase initialisms, like “mph” 
(for “miles per hour”). Under either option above, we’d get “Mph”. If we want 
some other behavior, ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Referencing zero-parameter functions

[David Sweeris via swift-evolution]

What’s wrong with `foo()` again? To me, a `_` in the parameter list means that 
something is there, but the label doesn’t matter.

- Dave Sweeris

> On May 5, 2016, at 9:42 AM, Alex Hoppen via swift-evolution 
>  wrote:
> 
> The idea of adding a syntax to reference zero-argument functions just like 
> foo(arg:) is used to reference a one-parameter function has come up several 
> times on the list. Pyry and I have put together a proposal to let foo(_) 
> refer to a function foo without any parameters. GitHub-Link: 
> https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/-refernce-zero-param-func.md
>  
> 
> 
> Comments welcome, especially if someone thinks that any of the issues listed 
> in "Possible issues" are major or sees any other problems.
> 
> – Alex
> 
> 
> Referencing zero-parameter functions
> 
> Proposal: SE- 
> 
> Author(s): Alex Hoppen , Pyry Jahkola 
> 
> Status: Draft
> Review manager: TBD
>  
> Introduction
> 
> Since the approval of SE-0021 
> 
>  it is possible to reference a function by its argument names using the 
> foo(arg:) syntax but there is no way to reference a zero-parameter function. 
> This proposal adds a new syntax foo(_) to reference an overloaded function 
> with zero parameters.
> 
> This was one point in the discussion: [Pitch] Richer function identifiers, 
> simpler function types 
> 
>  
> Motivation
> 
> Consider the following example
> 
> class Bar {
>   func foo() {
>   }
> 
>   func foo(arg: Int) {
>   }
> }
> You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no 
> syntax to reference foo() without using disambiguation by type Bar.foo() as 
> () -> Void. We believe this is a major hole in the current disambiguation 
> syntax.
> 
>  
> Proposed
>  solution
> 
> We propose that Bar.foo(_) references the function with no parameters just as 
> Bar.foo(arg:) references the function with one argument named arg. 
> 
> In the context of functions declarations _ already has the meaning of "there 
> is nothing" (e.g. func foo(_ arg: Int)). Thus, we believe that _ is the right 
> character to mean that a function has no parameters.
> 
>  
> Detailed
>  design
> 
> The unqualified-name grammar rule from SE-0021 
> 
>  changes to 
> 
> unqualified-name -> identifier
>   | identifier '(' ((identifier | '_') ':')+ ')'
>   | identifier '(_)'
> If two overloads with zero-parameters exist with different return types, 
> disambiguation has still to be done via as just like with the foo(arg:) 
> syntax.
> 
>  
> Impact
>  on existing code
> 
> This is a purely additive feature and has no impact on existing code.
> 
>  
> Possible
>  issues
> 
> If Swift should ever support out-only parameters Bar.foo(_) could mean that 
> the only out-only parameter shall be ignored. This would clash with the 
> currently proposed syntax. However, since Swift functions may return multiple 
> values as a tuple, we don't see this coming.
> 
> Bar.foo(_) may be mistaken for Bar.foo(_:) if there is also a one-parameter 
> function without a label. This mistake would, however, be mostly detected by 
> the compiler when later calling the function with an argument.
> 
>  
> Alternatives
>  considered
> 
>  
> Alternative
>  1: Bar.foo
> 
> Let Bar.foo reference the function with zero parameters only. While this 
> works around the possible issue of ignored out-only parameters described 
> above, this has several minor drawbacks to the proposed solution (some of 
> these drawbacks are mutually exclusive based on possible future proposals but 
> one always applies):
> 
> Most functions are not overloadad and using the base name only offers a 
> shorthand way to reference these functions.
> This would b

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Basem Emara via swift-evolution]

How about mutating keyword just like func's:

mutating protocol Foo {…}

Isn’t that what the current “class” keyword is trying to indicate? It feels 
awkward that a protocol would inherit from a reference type when just looking 
at the syntax, whether it be class, AnyObject, etc.

> On May 5, 2016, at 10:52 AM, Jesse Squires via swift-evolution 
>  wrote:
> 
> > Personally I have always felt “class” was an oddball special case here
> that's unneeded because we have a perfectly good protocol that means the
> same thing: AnyObject.
> 
> +1 
> 
> Repurposing the `class` keyword to constrain a protocol to reference types 
> has always felt awkward, out-of-place, and inconsistent with the rest of the 
> language. I would love to see this changed to `AnyObject` as Dave suggests.
> 
> Given all of the other great refinements for language consistency that have 
> been proposed and accepted for Swift 3, the awkwardness of using `class` here 
> is even greater than before.
> 
> Jesse
> 
> 
> 
> On Tue, May 3, 2016 at 11:06 AM, Dave Abrahams via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> on Mon May 02 2016, David Sweeris  > wrote:
> 
> > I was just thinking that:
> >
> > protocol Foo : reference {}
> >
> > might be more to the point than:
> >
> > protocol Foo : class {}
> >
> > I know that it’s currently a moot point because classes are the only*
> > reference-semantics type of type in Swift, but it’s conceivable that there 
> > might
> > some day be others. Anyway, I’m not saying it’s a big deal or anything, I’m 
> > just
> > trying to think of any source-breaking changes we might want to make before
> > Swift 3 drops, and this seems like an easy one.
> >
> > - Dave Sweeris
> >
> > * I’m not actually sure this is true. I have a very vague recollection about
> > some protocols getting reference semantics in certain circumstances, but the
> > memory is so hazy I’m not sure I trust it. Also I can’t remember if the
> > “indirect” keyword in enums affects the semantics.
> 
> Personally I have always felt “class” was an oddball special case here
> that's unneeded because we have a perfectly good protocol that means the
> same thing: AnyObject.
> 
> --
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> -- 
> Jesse Squires
> 
> blog | jessesquires.com 
> github | github.com/jessesquires 
> hexedbits | hexedbits.com 
> ___
> 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] Should we rename "class" when referring to protocol conformance?

[Jesse Squires via swift-evolution]

> Personally I have always felt “class” was an oddball special case here
that's unneeded because we have a perfectly good protocol that means the
same thing: AnyObject.

+1

Repurposing the `class` keyword to constrain a protocol to reference types
has always felt awkward, out-of-place, and inconsistent with the rest of
the language. I would love to see this changed to `AnyObject` as Dave
suggests.

Given all of the other great refinements for language consistency that have
been proposed and accepted for Swift 3, the awkwardness of using `class`
here is even greater than before.

Jesse



On Tue, May 3, 2016 at 11:06 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon May 02 2016, David Sweeris  wrote:
>
> > I was just thinking that:
> >
> > protocol Foo : reference {}
> >
> > might be more to the point than:
> >
> > protocol Foo : class {}
> >
> > I know that it’s currently a moot point because classes are the only*
> > reference-semantics type of type in Swift, but it’s conceivable that
> there might
> > some day be others. Anyway, I’m not saying it’s a big deal or anything,
> I’m just
> > trying to think of any source-breaking changes we might want to make
> before
> > Swift 3 drops, and this seems like an easy one.
> >
> > - Dave Sweeris
> >
> > * I’m not actually sure this is true. I have a very vague recollection
> about
> > some protocols getting reference semantics in certain circumstances, but
> the
> > memory is so hazy I’m not sure I trust it. Also I can’t remember if the
> > “indirect” keyword in enums affects the semantics.
>
> Personally I have always felt “class” was an oddball special case here
> that's unneeded because we have a perfectly good protocol that means the
> same thing: AnyObject.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Jesse Squires

*blog* | jessesquires.com 
*github* | github.com/jessesquires 
*hexedbits* | hexedbits.com 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Referencing zero-parameter functions

[Alex Hoppen via swift-evolution]

The idea of adding a syntax to reference zero-argument functions just like 
foo(arg:) is used to reference a one-parameter function has come up several 
times on the list. Pyry and I have put together a proposal to let foo(_) refer 
to a function foo without any parameters. GitHub-Link: 
https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/-refernce-zero-param-func.md
 


Comments welcome, especially if someone thinks that any of the issues listed in 
"Possible issues" are major or sees any other problems.

– Alex


Referencing zero-parameter functions

Proposal: SE- 

Author(s): Alex Hoppen , Pyry Jahkola 

Status: Draft
Review manager: TBD
 
Introduction

Since the approval of SE-0021 

 it is possible to reference a function by its argument names using the 
foo(arg:) syntax but there is no way to reference a zero-parameter function. 
This proposal adds a new syntax foo(_) to reference an overloaded function with 
zero parameters.

This was one point in the discussion: [Pitch] Richer function identifiers, 
simpler function types 

 
Motivation

Consider the following example

class Bar {
  func foo() {
  }

  func foo(arg: Int) {
  }
}
You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no 
syntax to reference foo() without using disambiguation by type Bar.foo() as () 
-> Void. We believe this is a major hole in the current disambiguation syntax.

 
Proposed
 solution

We propose that Bar.foo(_) references the function with no parameters just as 
Bar.foo(arg:) references the function with one argument named arg. 

In the context of functions declarations _ already has the meaning of "there is 
nothing" (e.g. func foo(_ arg: Int)). Thus, we believe that _ is the right 
character to mean that a function has no parameters.

 
Detailed
 design

The unqualified-name grammar rule from SE-0021 

 changes to 

unqualified-name -> identifier
  | identifier '(' ((identifier | '_') ':')+ ')'
  | identifier '(_)'
If two overloads with zero-parameters exist with different return types, 
disambiguation has still to be done via as just like with the foo(arg:) syntax.

 
Impact
 on existing code

This is a purely additive feature and has no impact on existing code.

 
Possible
 issues

If Swift should ever support out-only parameters Bar.foo(_) could mean that the 
only out-only parameter shall be ignored. This would clash with the currently 
proposed syntax. However, since Swift functions may return multiple values as a 
tuple, we don't see this coming.

Bar.foo(_) may be mistaken for Bar.foo(_:) if there is also a one-parameter 
function without a label. This mistake would, however, be mostly detected by 
the compiler when later calling the function with an argument.

 
Alternatives
 considered

 
Alternative
 1: Bar.foo

Let Bar.foo reference the function with zero parameters only. While this works 
around the possible issue of ignored out-only parameters described above, this 
has several minor drawbacks to the proposed solution (some of these drawbacks 
are mutually exclusive based on possible future proposals but one always 
applies):

Most functions are not overloadad and using the base name only offers a 
shorthand way to reference these functions.
This would block the way of allowing properties with the same name as a 
function with zero parameters by banning Bar.foo as a function reference (could 
be another proposal once this one is accepted).
Bar.foo(arg:) hints that a function is referenced by its paranthesis. Bar.foo 
doesn't include paranthesis, which causes a subtle inconsistency.
 
Alte

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 5, 2016, at 8:25 AM, David Hart  wrote:
> 
>>> Answering Doug’s question: I’d like the name lookup to start in R and to be 
>>> able to refer to an associated type newly defined in R.
>> 
>> This seems confusing to me.  The associated type has not been introduced 
>> until inside the body of R.  It doesn't make sense to allow them to be 
>> constrained prior to introduction and it offers no additional functionality. 
>>  Separating the constraints on inherited associated types from the 
>> constraints on newly introduced associated types adds clarity and 
>> readability IMO.  Lookup should only consider inherited protocols.
> 
> I agree with you Matthew (as my proposal makes clear). If it started in R, 
> readers would have to scan both the declaration where clause and the 
> associated type where clause to get a full picture.
> 
> protocol R : Q where AssocType.Generator.Element == Int {
> associatedtype AssocType: Sequence
> }
> 
> vs
> 
> protocol R : Q {
> associatedtype AssocType: Sequence where AssocType.Generator.Element == 
> Int
> }
> 

Yep, I know you agree and am happy with the proposal.  Just clarifying the 
rationale (as I see it) for Thorsten.

> David.
> 
>> 
>>> 
>>> -Thorsten
>>> 
>>> 
 Am 03.05.2016 um 14:03 schrieb Matthew Johnson via swift-evolution 
 :
 
 
 
 Sent from my iPad
 
> On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On May 2, 2016, at 3:50 PM, David Hart  wrote:
>> 
>> Hi Doug,
>> 
>> In the latest version of the proposal, which is now linked to a pull 
>> request, I mentioned in the Detail Design section that the following 
>> syntax be valid:
>> 
>> protocol R : Q where AssocType : P {
>>   // …
>> }
>> 
>> Can you read through that part of the proposal and let me know if it is 
>> descriptive enough?
> 
> I think you need to clarify the intended name lookup semantics. Does name 
> lookup for "AssocType" start its lookup in R or in Q? If the former, can 
> one refer to an associated type newly defined in R?
 
 To me this syntax reads as a constraint on Q only.  If we need a 
 constraint on associated types defined in R the constraint should be 
 attached to the definition.
 
> 
>   - Doug
> 
> 
>> 
>> David.
>> 
 On 26 Apr 2016, at 05:28, Douglas Gregor  wrote:
 
 
 On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution 
  wrote:
 
 I wrote the proposal which was discussed to introduce generic 
 constraints for associated types. I’d like to get some feedback on it 
 and get it ready before submitting it:
 
 More Powerful Constraints for Associated Types
 Proposal: SE-
 Author(s): David Hart
 Status: TBD
 Review manager: TBD
 Introduction
 
 This proposal seeks to introduce a where expression to associated 
 types declarations to bring the same expressive power as generic type 
 constraints.
 
 This proposal was discussed on the Swift Evolution list in the 
 [swift-evolution] [Completing Generics] Arbitrary requirements in 
 protocols thread.
 
>>> Believe it or not, I support this direction…
>>> 
 Motivation
 
 Currently, associated type declarations can only express simple 
 inheritance constraints and not the more sophisticated constraints 
 available to generic types with the where expression. Some designs, 
 including many in the Standard Library, require more powerful 
 constraints for associated types to be truly elegant. For example, the 
 SequenceType protocol can be declared as follows:
 
 protocol Sequence {
 associatedtype Iterator : IteratorProtocol
 associatedtype SubSequence : Sequence where 
 SubSequence.Iterator.Element == Iterator.Element
 ...
 }
 Detail Design
 
 With this proposal, the grammar for protocols associated types would 
 be modified to:
 
 protocol-associated-type-declaration → attributesopt 
 access-level-modifieropt associatedtype typealias-name 
 ­type-inheritance-clause­opt­ typealias-assignment­opt 
 requirement-clauseopt
 
 The new requirement-clause is then used by the compiler to validate 
 the associated types of conforming types.
 
>>> The only thing that bothers me about this syntax is that I have to 
>>> introduce an associated type to add requirements. For example, what if 
>>> I want my inheriting protocol to add a requirement to an existing 
>>> associated type?
>>> 
>>> protocol P { }
>>