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

[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

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 >

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

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

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”

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

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

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

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

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,

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

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

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

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

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

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

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:

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

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

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

[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

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

[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

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

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

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

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

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

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

> On Jul 3, 2016, at 11:50 PM, Tino Heth via swift-evolution > wrote: > > Overall, -1. > > I agree that labels should not affect the type, but imho the current status > (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't > achieve what it

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

Overall, -1. I agree that labels should not affect the type, but imho the current status (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't achieve what it says in the title: For me, that is no question of types at all, but only of names: var a: (Int, z: Int) -> Void =

Re: [swift-evolution] [Idea] Large integer literals

On Sun, Jul 3, 2016 at 9:20 PM, Brent Royal-Gordon via swift-evolution wrote: > 2. Use a tuple/array of `Int`s/`UInts` > > Like `String`, this lends itself to becoming variable-width in a later > version; unlike `String`, it's relatively compact. But also unlike

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

+1 Finally, let’s get it done > On 4 Jul 2016, at 03:36, Gabriel Lanata via swift-evolution > wrote: > > Hello, this has been proposed multiple times before in different ways. > > Link to detailed proposal draft: >