Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> Thanks Chris. I just meant where is that string going? > > To a developer -> CustomDebugStringConvertible / Reflection > To standard output -> Streamable > To a user -> NSLocalizedString — no protocol (yet?) > To an API / for serialisation -> LosslessStringConvertible > To a playground ->

Re: [swift-evolution] [Proposal] Protected Access Level

> > I can't reply directly to all the points in this thread, but I will just say > that there are ways of emulating protected in the language as it exists today: > > If the goal is to have functions that can be overridden by subclasses without > being called by external classes, you can create

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 3:42 AM, Tino Heth via swift-evolution > wrote: > >> I can't reply directly to all the points in this thread, but I will just say >> that there are ways of emulating protected in the language as it exists >> today: >> >> If the goal is to have

Re: [swift-evolution] [Proposal] Protected Access Level

That's a cool hack! For a lighter way to distinguish overridable methods that one shouldn't ordinarily call, did anyone consider approximating "protected" (or as called in Objective-C speak, "private extension") methods with public class methods? public class UIView { public class

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > > But `protected` is quite different from other access levels; it does not > limit the visibility of the symbols, but rather their use. And protocols face > the same sort of problem as

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On Sun, May 29, 2016 at 11:23 PM, Brent Royal-Gordon via swift-evolution wrote: > There are *very* few conformances to Streamable in the standard library—just > Character, String, and UnicodeScalar. I think that Streamable is for data > that can be *directly* written

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On 29 May 2016, at 20:39, Chris Lattner wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk > > wrote: On May 27, 2016, at 12:11 PM, Joe Groff > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

> The core team believes that the existing strideable API cannot efficiently > and correctly handle all the real-world use cases one would want. However, a > multiplication-based implementation similar to the one proposed in SE-0050 > (but potentially extended) seems sufficiently general to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On 30.05.2016 13:40, Haravikk via swift-evolution wrote: >... I understand that the need for semi-colon separators probably arose as a requirement of removing where, but I think it makes more sense to cover semi-colons first as a result, and come back to removing where clauses afterwards.

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPad > On May 29, 2016, at 10:22 PM, Charles Srstka wrote: > >> On May 29, 2016, at 10:13 PM, Matthew Johnson wrote: >> >> On May 29, 2016, at 9:43 PM, Charles Srstka wrote: >> On May 29, 2016,

Re: [swift-evolution] Variadic generics discussion

I’ll keep this quick since I see upthread you have already revised the proposal. > On May 29, 2016, at 12:36 PM, Austin Zheng wrote: > >> …something like the above is definitely a "nice to have", but not having it >> will close off certain use cases. > > Oh, this is

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

I believe you should add currently available syntax to proposal text: let c = zip(a,b).reduce(0) { (acc, tuple: (a: Int, b: Int)) in acc + tuple.a + tuple.b } func takesATuple(tuple : (valueA: Int, valueB: Int)) { print("a: \(tuple.valueA) b:\(tuple.valueB)") } Not so nice as proposed, but

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

> // Allowed today: > func takesATuple(tuple: (Int, Int)) { > let valueA = tuple.0 > let valueB = tuple.1 > // ... > } > > // Proposed syntax: > func takesATuple(tuple (valueA, valueB): (Int, Int)) { > // use valueA > // use valueB > } Personally, I find this example confusing because

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

Sent from my iPad On May 30, 2016, at 8:01 AM, Brent Royal-Gordon via swift-evolution wrote: >> // Allowed today: >> func takesATuple(tuple: (Int, Int)) { >> let valueA = tuple.0 >> let valueB = tuple.1 >> // ... >> } >> >> // Proposed syntax: >> func

Re: [swift-evolution] [Proposal] Protected Access Level

I kind of want something like protected for protocols, but not necessarily protected as it is implemented in other languages. I often have a few low-level methods in a protocol which the higher level methods in protocol extensions use to do their work. Occasionally, I need to guarantee a

Re: [swift-evolution] Variadic generics discussion

A few more comments inlined now that I’ve read it. > On May 30, 2016, at 7:44 AM, plx via swift-evolution > wrote: > - if you have e.g. 2+ packs, can you enforce (T…) and (U…) have the same > arity? Seems the answer is yes iff there’s a `T.Foo... == U.Bar…` style

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

Great catch! I didn’t know that was possible! I’ll add it to the proposal. Thanks! - Dennis > On May 30, 2016, at 3:53 PM, Vladimir.S wrote: > > I believe you should add currently available syntax to proposal text: > > let c = zip(a,b).reduce(0) { (acc, tuple: (a: Int, b:

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

> I like the idea of allowing destructuring everywhere we bind a name very > much. My only (minor) concern with doing this for tuples right now is that > it might encourage overuse of them where a struct would be a better choice. > > I have been thinking about destructuring of structs and

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 30, 2016, at 5:13 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 29, 2016, at 9:43 PM, Charles Srstka > wrote: > >>> On May 29, 2016, at 9:20 PM, Matthew

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 30, 2016, at 5:22 AM, Charles Srstka via swift-evolution > wrote: > >> On May 29, 2016, at 10:13 PM, Matthew Johnson > > wrote: >> >> On May 29, 2016, at 9:43 PM, Charles Srstka

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

> On May 30, 2016, at 4:10 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> The core team believes that the existing strideable API cannot efficiently >> and correctly handle all the real-world use cases one would want. However, >> a multiplication-based

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

Hi Brent, Thanks! Those are great points! I haven’t thought about the possibility of suppressing the external label. I like your option 2 very much! I’ll add it to the proposal and change the used variable names. - Dennis > On May 30, 2016, at 3:01 PM, Brent Royal-Gordon

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 2:46 AM, Rod Brown via swift-evolution > wrote: > > Brent, > > You make a very good point about the fact internal is not necessarily the > same as subclass, something I hadn’t considered. > > I think that the level of exposure these APIs then

[swift-evolution] [Proposal] Shorthand Argument Renaming

Hello, I was thinking about this, and would like to get some feedback before making my first proposal. Best regards, Fred. --- Shorthand Argument Renaming Introduction Swift automatically provides shorthand argument names to inline closures which cleverly allows us to write reversed

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 29, 2016, at 4:12 PM, Vladimir.S via swift-evolution > wrote: > > On 27.05.2016 18:37, plx via swift-evolution wrote: >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>> >

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

I have concerns. Responses inline. Sincerely, Zachary Waldowski z...@waldowski.me On Fri, May 27, 2016, at 12:11 PM, Joe Groff via swift-evolution wrote: > • What is your evaluation of the proposal? -1. Neither semicolon-based nor newline-based conditionals strike me as sufficiently

Re: [swift-evolution] [Proposal] Protected Access Level

> Couldn’t you use the same reasoning to claim there shouldn’t be access > control at all? Just add documention on methods you want to mark private > telling users of the library not to call them! I guess you are making fun, but actually, good old Objective-C messaging works just that way: You

Re: [swift-evolution] [Pitch] #warning

I've used custom warnings and errors in other languages and find them both useful. Forgive my ignorance, but does Swift have warning levels, warning IDs and pragmas/build settings to disable specific warnings? If so, it would be good to specify exactly how this feature interact with those. For

Re: [swift-evolution] [Pitch] #warning

On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution < swift-evolution@swift.org> wrote: > Tools like SonarQube can raise a "warning" for comments started with > "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be > presented as warnings instead of using

Re: [swift-evolution] [Pitch] #warning

I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce. I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 29, 2016, at 3:31 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 8:25 AM, Vladimir.S wrote: >> >> >> Should 'deriving' allows us to manually implement protocol requirements? For >>

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

Fréderic, the idea and reasoning are good and do make sense but I'm not 100% go on this. When I started using this syntax I felt like I was back in PHP but once I got used it's ok. I don't see anything wrong that justifies the change in syntax. Looking at your examples I even think it's easier to

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

If you're asking me, it depends on what gets filled in for "syntax". I see no reason to explicitly prohibit classes from participating, though. - Dave Sweeris > On May 30, 2016, at 16:12, Vladimir.S wrote: > > In case we discuss this feature not for just value types but for

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

I assume that Core team is scheduling a discussion or already discussing the proposal, and that really takes time in our case. In reply to Brent, I think that we can start requiring `public` if (when?) operator visibility levels are added. - Anton 2016-05-24 13:53 GMT+03:00 Brent Royal-Gordon

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that automatic conformance can be defined in the language itself and that derived protocol instances don't have to be implemented as compiler intrinsics. That's just not the case. You cannot define something like @auto

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 30, 2016, at 10:54 PM, Erica Sadun via swift-evolution > wrote: > > >>> On May 28, 2016, at 4:48 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> >>> On May 27, 2016, at 12:11 PM, Joe Groff wrote:

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

This is an interesting proposal, but I think splatting like Python would be preferable: creators of functions use separate parameters and callers can expand tuples as necessary by prefixing a tuple at point of use with * to expand it into separate arguments. Even with the Swift language as it is

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

In light of Chris and Dave's responses about how this discussion will be mostly absent of core team members until Swift 3 is more or less wrapped up, perhaps we should let this thread sit idle until then. As the original necromancer, I'm sure this will be brought back to life when it's

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Thank you, Brent. But for me you just described a serialization to/from string ;) So, using your example, if I have struct A: CustomStringConvertible { var a = 0, b = 0 var description: String { return "a:\(a) b:\(b)" } } and I want to use it in your code. Will I be able to do this?

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 31, 2016, at 12:54 AM, Brent Royal-Gordon via swift-evolution wrote: >> Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend >> the proposal: now you can use semicolons or a newline to separate clauses of >> different types. > > This

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> I can't understand this. For me ValuePreservingStringConvertible usually will > be different than CustomStringConvertible. Can't I want to have some string > view of my struct to present data(also in UI) *and* value preserving string > value for the same struct? > So my .description will show

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend > the proposal: now you can use semicolons or a newline to separate clauses of > different types. This change does not alter my concern about the overloading of the semicolon as a statement separator, and in fact, it

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Yes exactly, use the protocol conformance syntax, Michael’s description was mistaken I think. Just the same way you get protocol extensions without having to use a special keyword. > On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution > wrote: > > I see

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Of course, an alternative is to eliminate `where` for all uses of `case` as well. On Mon, May 30, 2016 at 11:55 PM Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 29.05.2016 um 17:11 schrieb Thorsten Seitz via swift-evolution < > swift-evolution@swift.org>: > > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 29.05.2016 um 17:11 schrieb Thorsten Seitz via swift-evolution > : > > >> Am 28.05.2016 um 22:35 schrieb Chris Lattner : >> >> >>> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: >>> >>> What about requiring

Re: [swift-evolution] [Proposal] Protected Access Level

It might be worth being more specific with your comparison between the "lock and key" access control I described and the other techniques described in this thread. Given that the designers of Swift were familiar with protected access level from other languages and deliberately chose to exclude it,

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

> On May 30, 2016, at 6:01 AM, Brent Royal-Gordon via swift-evolution > wrote: > > // Proposed syntax: > func takes(a (valueA, valueB): (Int, Int)) { > // use valueA > // use valueB > } FWIW, Swift 1 supported tuple destructuring in parameter lists, and we took it

Re: [swift-evolution] [Pitch] #warning

Btw, FWIW, regarding the state that some warning semantics can change later.. @warn_unused_result func TODO()->Bool {return true} Then in code: TODO(/*Make it faster*/) // any comment you want Will have: WARNING at line 12, col 3: result of call to 'TODO()' is unused TODO(/*Make it

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

What about declaring the requirements for auto-conformance in a sub-protocol? @auto protocol AutoEquatable : Equatable { //"syntax" for how to conform to Equatable } struct Foo : AutoEquatable {} //the compiler automatically synthesizes everything struct Bar : Equatable {} //you manually

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 4:48 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition

[swift-evolution] [Draft] Lazy evaluation when assigning static variables

Several weeks ago I posted that I was confused by the differences between how static variables and lazy variables evaluated (or - as I would expect - didn’t evaluate) when initially assigned with a different value. It didn’t result in any discussion, but I encountered it again and decided to

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Is there no one that thinks it's sufficient if users can create a tuple from a list of properties and reuse tuple equality and hash? Is there no one that thinks it's sufficient if the system were to supply a named function for comparing two Any's for equality (with reference equality semantics

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

> On May 30, 2016, at 2:39 PM, Chris Lattner via swift-evolution > wrote: > >> On May 30, 2016, at 6:01 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> // Proposed syntax: >> func takes(a (valueA, valueB): (Int, Int)) { >> //

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

In case we discuss this feature not for just value types but for classes also - will such AutoEquatable allows to implement protocol manually? Now we can have: func == (lhs: A, rhs: A) -> Bool { return true } class A: Hashable { var hashValue: Int { return 100 } } class B: A { override var

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

> On May 30, 2016, at 2:19 PM, Frédéric Blondiau via swift-evolution > wrote: > > I personally never found that this “$n” convention was “Swift-like”... but > it’s true that a “$n” is easier to spot than a “.n”, and I got used to also. > > However, I realised how

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 11:23 AM, Tino Heth <2...@gmx.de> wrote: > >> Couldn’t you use the same reasoning to claim there shouldn’t be access >> control at all? Just add documention on methods you want to mark private >> telling users of the library not to call them! > > I guess you are making

Re: [swift-evolution] Variadic generics discussion

(inline, again) On Mon, May 30, 2016 at 5:44 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > I’ll keep this quick since I see upthread you have already revised the > proposal. > > On May 29, 2016, at 12:36 PM, Austin Zheng wrote: > > …something like the

Re: [swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

> • What is your evaluation of the proposal? Mixed. But I think it leans towards the negative. At first I thought it was a big improvement, but after looking at how our team currently writes guard statements, the where clause is almost always using the unwrapped value (as opposed to an

Re: [swift-evolution] [Pitch] #warning

Something similar to #error seems to be already implemented ;) #if os(iOS) import Error_sorryThisDoesntWorkOnIOSyet #endif I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, #error would look nicer) -Michael > Am

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

Personally I also don't like the `$N` syntax. But I don't suport `.N` syntax as it looks like the closure argument is tuple, and like we use tuple's values in body. But we removed association between tuples and function parameters in Swift. First my thoughts were about `_1` `_2` syntax.

Re: [swift-evolution] [Pitch] #warning

Hmm... and like `#warning` : let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use " // some comments that you need to show and we have a warning(unused value)! from compiler! with WARNING at line 8, col 7: initialization of immutable value

Re: [swift-evolution] [Pitch] #warning

1. I don't think we'll lose 'unused value' warning in future, probably another warning could be found for this 'feature' that definitely will not be dropped. 2. The point was that currently we can 'emulate' user-defined warnings *if we really wants*. I believe we need special #warning or

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

In Java I would use Project Lombok's @EqualsAndHashCode annotation on a class. Caveats: 1. Swift is not Java and that's a good thing (TM). 2. Project Lombok is not Java, either. 3. 'deriving Equatable, Hashable' makes those interfaces 'magic'. Is that good?

Re: [swift-evolution] Variadic generics discussion

(more inline) On Mon, May 30, 2016 at 6:30 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > A few more comments inlined now that I’ve read it. > > I like the `fold` construct but feel like for this use it needs a few more > options-or-variants. > > The first one is some

Re: [swift-evolution] [Proposal] Protected Access Level

> The purpose of access control isn’t really to keep out malicious users, > though, it’s to prevent accidental misuse and clarify the interface. mh, I would call this a "documenting intend" ;-) > One nice vector for accidental misuse is autocomplete. Even if > layoutSubviews() has a great big

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

It seems that there are two groups here. 1) Group 1 wants Equatable (and others) be derived automatically unless specifically overridden: similar to auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants Equatable (and others) be derived explicitly using a `deriving`

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 2:02 PM, Tino Heth <2...@gmx.de> wrote: > >> The purpose of access control isn’t really to keep out malicious users, >> though, it’s to prevent accidental misuse and clarify the interface. > mh, I would call this a "documenting intend" ;-) If you get the method as an

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Seems to me like a heavy weight solution to invent a special keyword that will be applicable to 2 protocols in the entire standard library. If I am not mistaken, the Swift philosophy seems to be that Protocols carry the meaning, not how we apply them. So in this instance, something like the

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

Thanks for your feedback. I personally never found that this “$n” convention was “Swift-like”... but it’s true that a “$n” is easier to spot than a “.n”, and I got used to also. However, I realised how much this was disturbing for newcomers, when explaining closure shorthand argument names to

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I see these two groups: both wants explicit conformance to protocols, but first thinks that current syntax is enough (`: Equatable`) and second thinks we should introduce new keyword `deriving` for this(`: deriving Equatable`). I see no opinions(except the one opinion in proposal itself) to

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 30, 2016, at 12:04 PM, Michael Peternell via swift-evolution > wrote: > > It seems that there are two groups here. 1) Group 1 wants Equatable (and > others) be derived automatically unless specifically overridden: similar to > auto-synthesis of properties

Re: [swift-evolution] [Pitch] #warning

> On May 29, 2016, at 10:36 PM, Charlie Monroe > wrote: > >> As to #warning, Swift’s use of warnings are significant different than the >> use in C. In C compilers, many of the warnings produced *should* be errors, >> but can’t be because that effects language