Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

on Fri Oct 14 2016, Paul Cantrell wrote: > A late-arriving strong +1 for me. The index-related stuff is elegant and much > needed. I’m surprised > to learn that dict.keys and dict.values are copies and not already > views! They are views. > Clearly they should be.

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

> On Oct 15, 2016, at 6:41 PM, Charles Constant via swift-evolution > wrote: > > How would we all feel about allowing multiple modules with one import > statement? > > Eg: the option to write > > import Cocoa, Foo, Bar.Baz > > in addition to just: > >

[swift-evolution] [pitch] "import" declaration, support for comma-separated modules

How would we all feel about allowing multiple modules with one import statement? Eg: the option to write *import Cocoa, Foo, Bar.Baz * in addition to just: *import Cocoa * *import Foo * *import Bar.Baz * When I'm writing smaller files that import a few modules, I'd

Re: [swift-evolution] Tuples as RawRepresentable

> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky > wrote: > > Tuples cannot conform to protocols, so despite the existence of an “==” > operator for certain tuples, no tuple conforms to Equatable. > > This is problematic, because it means that a function

Re: [swift-evolution] private & fileprivate

in 10-15 years compilers/interpreters are merged and update themselves as AI. so we can tell in human language what an app should do :o) @Jean: can you explain that about extensions in this context (oop) ? TedvG ted van gaalen > On 15 Oct 2016, at 21:44, Goffredo Marocchi

Re: [swift-evolution] Tuples as RawRepresentable

> On 15 Oct 2016, at 19:00, Karl Wagner wrote: > > The edge-case I have in mind is... let's say we synthesised RawRep > conformance for all Equatable raw-types. That would allow you use struct and > class rawvalues with our shorthand syntax. I am not saying the compiler should do all the

Re: [swift-evolution] private & fileprivate

We will see how this will fare one way or the other in say 10-15 years. Sent from my iPhone > On 15 Oct 2016, at 14:43, Jean-Daniel via swift-evolution > wrote: > > >> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen a écrit >> : >> >> Please

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> On Oct 14, 2016, at 12:59 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" > begins now and runs through October 18. The proposal is available here: > > >

Re: [swift-evolution] private & fileprivate

> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen a écrit : > > Please do NOT drop the current distinction between *private* and *fileprivate* > as it is now in Swift 3 > It is needed for correct OOP. > That argument don’t apply for a language where you can structure

Re: [swift-evolution] Tuples as RawRepresentable

Tuples cannot conform to protocols, so despite the existence of an “==” operator for certain tuples, no tuple conforms to Equatable. This is problematic, because it means that a function which takes a generic Equatable parameter cannot be called with a tuple argument, even though an applicable

Re: [swift-evolution] Tuples as RawRepresentable

If you're looking for a use case for tuple equality, I often pack a bunch of values in a tuple and check it with another, which makes it easy to compare a multiple values at once and perform something only if all of them are equal. On Sat, Oct 15, 2016 at 09:28 Haravikk via swift-evolution <

Re: [swift-evolution] Tuples as RawRepresentable

> On 15 Oct 2016, at 16:04, Xiaodi Wu wrote: > > Yes it absolutely matters what the types are. Two floating point values can > compare equal when their raw bytes differ and they can compare not equal even > when their raw bytes are the same, and it would be absolutely

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> * What is your evaluation of the proposal? -1. I would much rather see it either as an operator, or more likely as some other special syntax/meaning in Swift. > * Is the problem being addressed significant enough to warrant a change > to Swift? No. Providing backwards

Re: [swift-evolution] Tuples as RawRepresentable

Yes it absolutely matters what the types are. Two floating point values can compare equal when their raw bytes differ and they can compare not equal even when their raw bytes are the same, and it would be absolutely necessary that a tuple of two floating point values behaves the same way.

Re: [swift-evolution] Tuples as RawRepresentable

The edge-case I have in mind is... let's say we synthesised RawRep conformance for all Equatable raw-types. That would allow you use struct and class rawvalues with our shorthand syntax. But Equatable values might overlap. A single raw-value might be considered equal to multiple

[swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> * What is your evaluation of the proposal? -1 The only use case of ‘$’ would be in short funny swift examples or in a playground, e.g. as a variable for a monetary amount. Similar to the emojis used as variables in the wild. But then, you could just use the ＄emoji… > * Is the problem

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Currently, we can expect that fields of a type are all collected in the same place. This expectation applies more for "static" and less for "dynamic" types. So I agree with the idea for @objc classes, strongly disagree for structs, and disagree for regular classes.

Re: [swift-evolution] Tuples as RawRepresentable

> On 14 Oct 2016, at 19:11, Karl wrote: > > >> On 14 Oct 2016, at 19:56, Haravikk > > wrote: >> >> Huh, see, that's why I posted the thread; I didn't know you could do it that >> way (I've been trying the

Re: [swift-evolution] Tuples as RawRepresentable

> On 15 Oct 2016, at 01:53,Karl wrote: > > There are no restrictions on what can be RawRepresentable (structs and > classes can also conform), and no limitation on the type of RawType (can also > be a struct or a class). You just need to implement it yourself in those > cases; I’m guessing

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I’m haven’t read the implementation, but as I see it, “weak” has the effect of storing associated values. Can that mechanism be made generic? > +1 from me too for internal extensions; I think this is the logical place to > start for now so we can see how many use cases this actually covers. >

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> On 14 Oct 2016, at 20:59, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? Not in favour, sorry. While I've used this kind of pattern in Javascript I just don't see what it really adds compared to a more explicit

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution > wrote: > > >> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution >> wrote: >> >> Let extensions introduce stored properties, but only in the same module as >>

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

Done. https://bugs.swift.org/browse/SR-2963. > On 14 Oct 2016, at 22:42, John McCall wrote: > >> On Oct 11, 2016, at 12:04 AM, Karl via swift-evolution >> > wrote: >>> >>> On 11 Oct 2016, at 08:49, Benjamin