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

> 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

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

On Thu, May 5, 2016 at 5:11 PM, Nate Cook wrote: > Thanks for the feedback, Dmitri , 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

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

- 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

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

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

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

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*

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

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

Re: [swift-evolution] Making `.self` After `Type` Optional

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

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

+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

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

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,

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

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 >

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

> 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

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

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

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

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

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

> 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 > > wrote: > NaN is really a problem only because of using it as an

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

> 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

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

> 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

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

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

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

> 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

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

> 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 >> > wrote: >> >> >>> On 5 May 2016, at 14:17, David Hart

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

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

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

> 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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

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 >

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

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

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

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

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

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

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

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

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

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]

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

> 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

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

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

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

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 */ "

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

> 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

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

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

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

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

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

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

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

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()’

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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.

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

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,

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

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:

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

[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

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

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

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

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

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

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:

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

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

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

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

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

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

Re: [swift-evolution] [Idea] Make lazy an attribute

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

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

> 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

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

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

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

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,

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

> 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

[swift-evolution] Referencing zero-parameter functions

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:

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

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

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

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

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Same, -1 from me. I’m not saying its a bad idea, just no worth polluting the standard library. > On 05 May 2016, at 06:06, Chris Lattner via swift-evolution > wrote: > > On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution >

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

> 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

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

Sent from my iPad > On May 5, 2016, at 7:30 AM, Thorsten Seitz wrote: > > To me it reads as a constraint on R. Otherwise we would have to write > `protocol R where … : Q where …, S where … { … }` which would not only be > confusing but would not make much sense IMHO

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

> Le 4 mai 2016 à 14:49, Nicola Salmoria via swift-evolution > a écrit : > >> * What is your evaluation of the proposal? > > -1. The proposed change seems to require a somewhat complex implementation > in the compiler, and I fail to see clear benefits in the change.

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

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

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

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

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

> Le 4 mai 2016 à 11:55, Pyry Jahkola a écrit : > > Hi Gwendal, > > Nice writeup. So I see that you recognise how this extra specification will > complicate (while also facilitate) things. And I also see that you're a > co-author of the proposal. So I'm more than happy

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

-1 for me as well. One of the most FAQ of other fellow developers coming from other languages are often confuse by the YES/NO boolean in Obj-C and always asks why I use those and not true/false (and don’t get me started on nil/Nil/NULL). I don’t want to find in the future discussion on

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

Even if that were removed "heterogenous" equality checks are valid under the remaining typing rules because both objects are Equatable and descend from NSObject meaning Swift will upcast, invoke this "nonsense", and make the comparison anyway. You can verify this by reimplementing vanilla ==

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

Motivation: The following code emits no compiler error in Swift 2.2: import Foundation func EQTest(lhs: NSArray, rhs: String) -> Bool { return (lhs == rhs) } 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

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

I haven't tried any languages which have anything like this, but I support the idea of bringing real properties and single-case functions to enums in this way. Using properties rather than parameterised values will prevent pattern matching in switch statements to get those properties, but the

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I think the descriptive/natural language aspect of Objective-C and Cocoa was and is a strength that should be kept in Swift too. It may be perceived as a pragmatist attempt to simplify the language somewhat or make it appear friendlier, but it is not a bad thing in and of itself. [[iOS

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I have seen wrong usage of bool values in Objective-C many times, and although most of those weren't real problems, I'd rather prefer to be forced to use a single pair of words for true/false. If this single pair is true/false or yes/no (or even .yes/.no [enum]) isn't that important to me, so

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

My quibble with this proposal (which should go through in one form or another) is that the initializers don’t throw. I know that this was discussed before, but was this before "try?” was introduced to Swift? Because to me this seems cleaner (with init(exact value: Float) throws) let x =

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

I've been thinking of a different name as well — but I was concerned by the fact that "class" is lowercase, while all "regular" types start uppercase… I'd prefer "Class" or "Reference" over "reference". Tino ___ swift-evolution mailing list

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

Rust and Scala support macros, C++ has templates, and even the venerable C has #defines. Introducing mera-programming is by no means easy as it generally equates introducing a second, more limited, language inside the original. There exists today an opportunity to take advantage of the string

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

Comments inline. > On May 4, 2016, at 7:57 PM, Brent Royal-Gordon wrote: > They separate indentation from the string's contents. Traditional multiline > strings usually include all of the content between the start and end > delimiters, including leading whitespace. This