[swift-evolution] StringInterpolationConvertible and StringLiteralConvertible inheritance

StringInterpolationConvertible inheritance of StringLiteralConvertible would allow "static-string" and \(string-expression) segments to be differentiated. /// For example, `"\(paragraph)" as HTML` would invoke: /// /// HTML.init(stringInterpolation: /// HTML.init(stringLiteral: ""), ///

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

It would be useful for clarification of a computed property being constant in extensions. For example: extension SKSpriteNode { static let type: String { return “Sprite” } } Andru ___ swift-evolution mailing list

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

Re: UPDATED APPROACH ## Initializable +1 although the existing -Convertible suffix isn't bad. (ExtendedGraphemeClusterLiteral could also be renamed to CharacterLiteral). ## Representable +1 for the

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

I tend to agree with Jon Shier, Karl Wagner, Nicola Salmoria, and Tony Allevato. I think moving `where` to the end hinders comprehension. The extra constraint abilities that Nicola brought up look interesting. > On 15 May 2016, at 1:52 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> Being able to let the developer decide how to place relevant type information > with the freedom of being able to keep some/all/none type information local > and some/none/all extra information moved to the end of the declaration. To be clear, I do think it makes sense to move *all* `where`

Re: [swift-evolution] Removing "_ in" from empty closures

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution >> wrote: >> >> Currently if a closure takes a value, it requires "_ in" to note >> that the value is ignored. This makes sense in many

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

on Fri May 13 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 13, 2016, at 9:12 AM, Dave Abrahams wrote: >> >> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> >>>My claim is that substituting the constraint of “it has value >>>semantics,” while

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

on Fri May 13 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 13, 2016, at 9:19 AM, Dave Abrahams wrote: >> >> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> >>>Remember that the only value semantic reference types are immutable, so >>>the

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

on Mon May 09 2016, Matthew Johnson wrote: >> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: >> >> >> on Sat May 07 2016, Andrew Trick wrote: >> > >>>On May 7, 2016, at 2:04 PM, Dave Abrahams wrote: >>> >>>2. Value types are not

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Nate Cook wrote: >>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> on Mon May 09 2016, Nate Cook wrote: >>> >>> Yet another alternative would be to drop Set and Dictionary down a >>> level to a

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 7:30 AM, Dave Abrahams wrote: >> >> >> on Mon May 09 2016, Joe Groff wrote: >> > On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution wrote: > *

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 14, 2016, at 11:16 PM, Chris Lattner via swift-evolution > wrote: > > On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution > wrote: >>> This encourages the use of empty closures over optional closures, which I >>> think is

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Tino, I believe you can start just with [Draft]... thread where you can present the draft of your proposal. Then, after you'll get opinions and after the draft will be polished, you can form an 'official' proposal. For now I didn't hear if someone else wanted to create that proposal. So I

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

I brought these up because the current implementation produces an error in these cases. You have to insert additional min/max operations. > Am 15.05.2016 um 16:38 schrieb Luis Henrique B. Sousa : > > Exactly, the idea is to return an empty array just like other languages do.

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Exactly, the idea is to return an empty array just like other languages do. (e.g. python) - Luis On Sun, May 15, 2016 at 10:13 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 15.05.2016 0:09, Maximilian Hünenberger via swift-evolution wrote: > >> One point which

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Sent from my iPhone On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution wrote: >> There we are. I read the declaration of the function from beginning to end >> and gradually formed a rough understanding of it without needing to change >> my expectations

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> There we are. I read the declaration of the function from beginning to end > and gradually formed a rough understanding of it without needing to change > my expectations halfway through. I still have doubts about 'insertCount', > but I was at least able to formulate an hypothesis about its use.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

On Sat, May 14, 2016 at 7:45 AM, Daniel Steinberg via swift-evolution wrote: > I appreciate your rework on this - I still don’t understand one thing and > disagree with a second: > > (1) I don’t understand what the word “Custom” adds to > CustomStringRepresentable and

[swift-evolution] [Proposal] Using Union instead of Generic Enum to implement Optional

This is the example implemented with generic and enum. enum UnionOf3 { case type0(T) case type1(U) case type2(V) } func input(value: UnionOf3) { switch value { case let .type0(a): print(a) case let .type1(b): print(b) case let .type2(c):

Re: [swift-evolution] Union instead of Optional

I don't know if there has been any internal discussion about using union-types instead of enums, but afaics, there are no obvious downsides for that approach. > I'm a little curious as to why union types keep on coming up, when enums can > do everything they can and much more (methods,

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

David Hart via swift-evolution writes: > > > Hi Karl, > > As author of this proposal, the one about constraints on associated types, and the one on type-aliases in protocols (all from the Generics Manifesto - original authorship to Douglas Gregor) I’d like to provide

[swift-evolution] Fwd: Union instead of Optional

for example, there is a method input union of 3 types: A, B, C, This is the three class. class A {} class B {} class C {} This is how it implemented under Swift 2: enum UnionABC { case classA(A) case classB(B) case classC(C) } func input(value: UnionABC) { } let a = A()

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> Tino, would you like to form an 'official' proposal for this(newlines as > separators) feature? As I can see, there is a much support in community for > this idea, but no one said yet he/she will create a proposal for this.(or I > just missed this) I feel honored, but I guess there are

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I think an important point is that `all<>` should NOT be restricted to having only one reference or value type! This is a little problematic and I’m not a compiler expert so from my perspective I could allow that but in a different way you see it (I’ll explain below). Ceylon does not have any

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I really don’t like that proposal too. While I can understand why it may be useful for list, I find it very confusing to allow it in function declaration. The motivation do not apply here. You can’t simply remove a parameter or reorder that without breaking all code that use that function

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> On May 15, 2016, at 9:17 AM, David Hart wrote: > > Hi Karl, > > As author of this proposal, the one about constraints on associated types, > and the one on type-aliases in protocols (all from the Generics Manifesto - > original authorship to Douglas Gregor) I’d like to

Re: [swift-evolution] Union instead of Optional

Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve? > On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution > wrote: > > > It’s kind of same idea of TypeScipt 2,

Re: [swift-evolution] "AnyValue", "protocol MyProtocol : value" as counterpart to "AnyObject", ": class"

Might have a look at this thread, where value semantics is been discussed already:  https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html  (Should we rename "class" when referring to protocol conformance?) I’m also proposing for a `Type` merging mechanism with

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Hi Karl, As author of this proposal, the one about constraints on associated types, and the one on type-aliases in protocols (all from the Generics Manifesto - original authorship to Douglas Gregor) I’d like to provide additional reasoning behind my wish to push this proposal through, as a