Re: [swift-evolution] Public classes with private superclass

Personally, it's perhaps more of an "aesthetic" thing I suppose but I would definitely prefer that my internal classes stay internal even if there is a public subclass... I don't like how that leaks my internal implementation like that... Though maybe the more swift thing to do would be to use

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

Vladimir.S via swift-evolution writes: > > Proposal: > === > > 1. Separate function types with parameter list and a tuple parameter. They > should be two separate types. > > 2. Require this syntax to assign tuple parameter's sub-values to variables > in func/closure: `{ ((x, y))

[swift-evolution] [Idea] Modification to Mirror struct to support dynamic reference cycle detection

I would like to suggest the following modification to the Mirror.DisplayStyle enum: for the Class case I would add an associated value of type ReferenceType (better naming is welcomed) which is yet another enum: enum ReferenceType { case Strong, Weak, Unowned } enum Mirror.DisplayStyle { ...

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

If uses NS_EXTENSIBLE_STRING_ENUM for `domain` names and `userInfo` keys, would a generic type (cf. DispatchSpecificKey) also be possible? FOUNDATION_EXPORT NSErrorUserInfoKey const NSStringEncod

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

> -1 this is why we have collection.forEach{} > > (1...10).forEach { > // do something. > } This is not equivalent since it doesn't allow you to break from the for loop. > > On Jul 1, 2016, at 12:38 AM, Diego Barros via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> When yo

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

Regards (From mobile) > On Jul 3, 2016, at 10:18 AM, Andrew Trick via swift-evolution > wrote: > > >> On Jul 2, 2016, at 8:10 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I have a pile of naming quibbles; rather than describe them all in prose >> (which turned into a mess),

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

This is the first version of this proposal which I've had time to read. I like it a lot overall. If I have some more time, I may try pulling the branch and writing some code with it to see how it feels. (If we could get a toolchain built from the branch, that might help others review it.) Here are

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On Jul 4, 2016, at 3:32 PM, Andrew Trick via swift-evolution > wrote: > > >> On Jun 28, 2016, at 11:05 PM, Chris Lattner > > wrote: >> >> Hello Swift community, >> >> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through >> July 4, 2016. The

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

on Sun Jul 03 2016, Andrew Trick wrote: >> On Jul 2, 2016, at 8:10 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I have a pile of naming quibbles; rather than describe them all in >> prose (which turned into a mess), I've annotated parts of the "Full >> UnsafeRawPointer API" secti

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On Jun 28, 2016, at 11:05 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of “SE-0107: UnsafeRawPointer API” begins now and runs through > July 4, 2016. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsafe

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

> On Jul 4, 2016, at 2:39 PM, Karl Wagner via swift-evolution > wrote: > > -1. I like the underscore. If it turns out you do need the loop variable > later, it's easy to see where to add it. > > Karl -1 I agree with this and doing something a specific number of times without accessing the

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

-1. I like the underscore. If it turns out you do need the loop variable later, it's easy to see where to add it. Karl > > On Jul 1, 2016 at 9:38 AM, (mailto:swift-evolution@swift.org)> wrote: > > > > > When you want a simple `for` loop, for example: > > > >

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

-1 this is why we have collection.forEach{} (1...10).forEach { // do something. } > On Jul 1, 2016, at 12:38 AM, Diego Barros via swift-evolution > wrote: > > When you want a simple `for` loop, for example: > > for _ in 1...10 { > > // do something 10 times > > } > > > > Clean-up and si

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

And it is something the compiler can check whether it is necessary for your code or not based on some simple and easy pattern. If it is so simple, why not let the compiler handle it? On 4 July 2016 at 16:02, Vladimir.S via swift-evolution wrote: > On 04.07.2016 21:21, Brent Royal-Gordon via swift

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

On 04.07.2016 21:21, Brent Royal-Gordon via swift-evolution wrote: On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa wrote: My issue with this being opt-in is third-party libraries. That's why we have retroactive modeling. :^) import SomeEnumKit extension SomeEnum: ValuesEnumerabl

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

On Mon, Jul 4, 2016 at 12:14 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hello, this has been proposed multiple times before in different ways. > > It

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

> On Jul 4, 2016, at 10:43 AM, Leonardo Pessoa wrote: > > My issue with this being opt-in is third-party libraries. That's why we have retroactive modeling. :^) import SomeEnumKit extension SomeEnum: ValuesEnumerable {} You can extend another module's public enum to add conform

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

An interesting take on arg label/name, granted this is including destructuring of obj literals (so one level down from the method sig, but which is not without analogy to what could be done to tuples with named fields). The main point of comparison is what the type of f1 and f2 are. This is in

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

My issue with this being opt-in is third-party libraries. The developer of a library may not have intended or thought of a use for the enum this way but some other developer might have. Being opt-in would prevent such scenarios from easily happening or require the developer to (again) manually impl

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

That is actually something I argued over this list with other users and (at least when I proposed) was not very well accepted. This certainly has my +1. On 4 July 2016 at 02:52, Gabriel Lanata via swift-evolution wrote: > I know! I am amazed this hasn’t had a formal proposal and review yet. I did

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

On 04.07.2016 16:33, Anton Zhilin via swift-evolution wrote: How does this proposal agree with tuple labels? Compare: func find(array: [Int], value: Int) -> (index: Int, value: Int) let result = find(...) result.index //=> 0 func getHandler(for kind: EventKind) -> (event: Event, parent: Widget

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

2016-07-04 18:34 GMT+03:00 Karl via swift-evolution < swift-evolution@swift.org>: > > Now that you mention it; why is Bool *not* an enum? > Probably, for the same reason Int is not an enum. ___ swift-evolution mailing list swift-evolution@swift.org https

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

This is now being tracked as https://bugs.swift.org/browse/SR-1882 - Chris (Lattner) thought this should not go through the official proposal process as something more complicated, but just add a warning with redundant parentheses around it silencing the w

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

> On 4 Jul 2016, at 09:14, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution >> wrote: >> >> Hello, this has been proposed multiple times before in different ways. > > It has indeed. Unfortunately, for various reasons it did

[swift-evolution] Proposal: Deprecate optionals in string interpolation

> The string interpolation is one of the strong sides of Swift, but also one of > its weaknesses. > > It has happened to me more than once that I've used the interpolation with an > optional by mistake and the result is then far from the expected result. > > This happened mostly before Swift 2.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

How does this proposal agree with tuple labels? Compare: func find(array: [Int], value: Int) -> (index: Int, value: Int) let result = find(...) result.index //=> 0 func getHandler(for kind: EventKind) -> (event: Event, parent: Widget) -> () let result = getHandler(...) result(event: ..., parent:

[swift-evolution] Public classes with private superclass

I'm running into "class cannot be declared public because its superclass is internal" issues on a regular basis, and I wonder if it wouldn't make sense to allow this combination: It might be less useful as soon as there are abstract classes or generic protocols, but even then I think I'd like to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 4, 2016, at 1:36 PM, Vladimir.S via swift-evolution > wrote: > > On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote: >>> * What is your evaluation of the proposal? >> >> I agree that the current situation is incoherent. If the type system doesn't >> care about the

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> As has been discussed exhaustively in this thread, Swift 3 function labels > don't convey the meaning of parameters, they are almost always prepositional > phrases that don't make sense apart from the primary function name they are > attached to. Why should there be different rules for closu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote: * What is your evaluation of the proposal? I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type. In the long run, it must be p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

> * What is your evaluation of the proposal? I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type. In the long run, it must be possible to label the parameters of a closure. But that labeling does

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 3, 2016, at 9:52 AM, David Sweeris wrote: > > >> On Jul 2, 2016, at 23:16, Erica Sadun via swift-evolution >> wrote: >> >> Change it to "Syntax.ExpressibleByIntegerLiteral" and I'd be onboard but >> I don't think it would pass the DaveTest despite it being only 2 characters >> long

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

> On Jul 3, 2016, at 6:36 PM, Gabriel Lanata via swift-evolution > wrote: > > Hello, this has been proposed multiple times before in different ways. It has indeed. Unfortunately, for various reasons it did not get into review in time, and Swift 3 is basically closed to additive features at th

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

+1 on anything that removes underscores ;-) ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution