Re: [swift-evolution] [idea] errors in properties

Brent Royal-Gordon has written a draft proposal: > On 25 Jul 2017, at 21:58, Gor Gyolchanyan via swift-evolution > wrote: > > This sounds like a challenge  > But seriously, seems like straight-up implementing the

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

> On Jul 26, 2017, at 12:36 AM, Daryle Walker via swift-evolution > wrote: > [Sorry if this's been discussed before.] > > As long as the superclass sub-object gets initialized, it shouldn't matter if > the initializer was designated or convenience. Is there some

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

I think it's some subtlety... I might vaguely remember someone saying something about it. Since a proposal didn't come of that, I'm assuming there was a technical issue or something. I could easily be wrong, though. - Dave Sweeris > On Jul 25, 2017, at 9:36 PM, Daryle Walker via

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

It prevents accidental infinite loops of inits, which is possible in Obj-C. > On Jul 26, 2017, at 12:36 AM, Daryle Walker via swift-evolution > wrote: > > [Sorry if this's been discussed before.] > > As long as the superclass sub-object gets initialized, it

[swift-evolution] Why couldn't a class call any of its superclass' initializers?

[Sorry if this's been discussed before.] As long as the superclass sub-object gets initialized, it shouldn't matter if the initializer was designated or convenience. Is there some subtle step on the two-phase initialization I'm missing? Or is this a point to extend in a future version of

Re: [swift-evolution] [Pre-pitch] Conform Int (and others) to LosslessStringConvertible

Agree. The approved text of SE-0089 explicitly contemplates Int conforming to LosslessStringConvertible. This would mean that it's a bug that the conformance hasn't been implemented. On Tue, Jul 25, 2017 at 8:03 PM, Angelo Villegas via swift-evolution < swift-evolution@swift.org> wrote: > I

Re: [swift-evolution] [Pre-pitch] Conform Int (and others) to LosslessStringConvertible

I think this is a bug. Basing on other numeric types, the intended result would be the same for Int. On 26 Jul 2017, 7:40 AM +0800, Niels Andriesse via swift-evolution , wrote: > I'm +1 on this. > > > On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution >

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

On Tue, Jul 25, 2017 at 16:35 Robert Bennett wrote: > Optional.some(Void) gives me "Expected member name or constructor call > after type name”. > That would appear to be straightforwardly a compiler bug. For instance, the following compiles: ``` let _Void = Void let foo

Re: [swift-evolution] [Pre-pitch] Conform Int (and others) to LosslessStringConvertible

I'm +1 on this. On Mon, 24 Jul 2017 at 15:37 Niels Andriesse via swift-evolution < swift-evolution@swift.org> wrote: > And CustomStringConvertible (to String) is basically the inverse of > LosslessStringConvertible (from String). > On Mon, Jul 24, 2017 at 3:23 PM, Niels Andriesse

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 2:20 PM, Xiaodi Wu wrote: > > Yes, I discussed this some time back. It breaks some things with overloads, > if I recall, but off the top of my head not recalling what. Functions that are overloaded with one version taking no arguments and another

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

This problem is not limited to JSON. I have scads of underscored variables and guard bindings in my code because of this limitation, though I rarely work with JSON. On Tue, Jul 25, 2017 at 5:13 PM, Niels Andriesse wrote: > Although I have come across this problem as

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

Catching and throwing exceptions is not the same as a controlled guard fail. It’s also quite verbose and requires extra types to be defined outside the scope of the initializer. On Tue, Jul 25, 2017 at 5:35 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Jul 25,

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

> On Jul 25, 2017, at 2:08 PM, David Hart via swift-evolution > wrote: > > >> On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution >> > wrote: >> >> Hi Morten, >> >> This is something we’ve

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 4:02 PM, Xiaodi Wu wrote: > > Default values for associated types are approved for Swift 4. They just > haven’t been implemented. Ahh, I had forgotten that. Thanks for clarifying! :) > > > On Tue, Jul 25, 2017 at 16:02 Matthew Johnson via

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

Optional.some(Void) gives me "Expected member name or constructor call after type name”. And as I said, the compiler should not be allowed to use the absence of parentheses to infer a Void generic type; only when the generic type is known to be Void may the parentheses be omitted. Under this

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

On Tue, Jul 25, 2017 at 4:44 AM, philohan95 via swift-evolution < swift-evolution@swift.org> wrote: > As you can see we had to use the properties twice (this would also be the > case of `if let`) making the initializer twice as long as necessary and > becomes a pain to implement when having more

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

I’ll take the opposite stance. Why limit this to initialization? I’d love to be able to guard assignments to *any* variable, whether it’s a property or not: func foo() { let bar: String if someCondition { guard bar = mightReturnOptional() else {

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

Yes, I discussed this some time back. It breaks some things with overloads, if I recall, but off the top of my head not recalling what. At some point, I also suggested regarding any case without associated values as equivalent to a case with an associated value of type Void. This was never

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

Although I have come across this problem as well (particularly when initializing from JSON), I don't think the solution is to fundamentally change initialization behavior like this, because 1. ) that is probably going to break a good deal of existing code and 2. ) I think that the introduction of

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

Default values for associated types are approved for Swift 4. They just haven’t been implemented. On Tue, Jul 25, 2017 at 16:02 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 25, 2017, at 3:26 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 3:26 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution > > wrote: > >> Currently if you have the following enum: >>

Re: [swift-evolution] [idea] errors in properties

This sounds like a challenge  But seriously, seems like straight-up implementing the feature and then wondering whether or not the pull request will be merged in or rejected is an unnecessary gamble, which is why swift-evolution exists. Haven’t anyone tried to make a proposal for this? I’d

Re: [swift-evolution] [idea] errors in properties

I’d give my +1 to support this as I’ve wished at one time or another that I could throw in the get, set, willSet, or didSet. Would this be something a proposal should be written up for when the Swift 5 reviews begin? > On Jul 25, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] [idea] errors in properties

There have been a number of discussions on the list in this—Google finds a number of these with a search “swift throwing properties site: lists.swift.org”. The “tldr” seems to be that it’s not supported because no one has written code to support it yet. On Tue, Jul 25, 2017 at 15:29 Gor

[swift-evolution] [idea] errors in properties

I’ll just cut to the chase: Why is throwing from get, set, willSet and didSet disallowed? var login: String { willSet throws { guard newValue.count > 5 else { throw LoginError.loginTooSmall } } } try login = “JebediahKerman”

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

> On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution > wrote: > > Currently if you have the following enum: > > enum E { > case c(T) > } > > then if T is Void, you have to write one of the following: > > let x: E = .c(Void()) > let y: E = .c(()) >

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

Thank you so much for the comments Itai and David. Makes perfect sense that the current implementation could be changed in the future. A stream implementation would be awesome and sounds like it’s perfectly doable. A future StructureEncoder has my vote. :-) Thanks again for the feedback!

[swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

Currently if you have the following enum: enum E { case c(T) } then if T is Void, you have to write one of the following: let x: E = .c(Void()) let y: E = .c(()) Looks awkward, no? In this case you can omit `` after `E` because it can be inferred, but if writing a (non-generic)

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

> On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution > wrote: > > Hi Morten, > > This is something we’ve considered adding and may do so in the future — > however, this will require additional API review and will not make it in time > for the Swift 4.0

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

on Wed Jul 12 2017, Gor Gyolchanyan wrote: > Hello, swift community! > > Recently I’ve come across a dilemma regarding value-type semantics > when dealing with generic types. Consider a protocol that has a > mutating in-place function and a non-mutating returning

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

Hi Morten, This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release. The usage of `JSONSerialization` as the serialization backend is a current implementation detail, and may

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

I’d be in favor of this. On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution < swift-evolution@swift.org> wrote: > I think the current way to initiate models in a Failable Initializer > `init?()` is overly verbose and should be shortened down so less > boilerplate should be needed. >

[swift-evolution] Idea: Properties in Failable Initializers less verbose

I think the current way to initiate models in a Failable Initializer `init?()` is overly verbose and should be shortened down so less boilerplate should be needed. The current way: ``` let someProperty: Any let anotherProperty: Any init?(data: [String: Any]) { guard

[swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

In the implementation og JSONEncoder and JSONDecoder we have the internal functionality that encodes Codable types to a structure that is compatible with JSONSerialization. The JSONEncoder then calls JSONSerialization on this structure - and JSONDecoder vice versa. In some situations it could be

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> Le 24 juil. 2017 à 10:43, Tino Heth <2...@gmx.de> a écrit : > > >> The last point is especially worrying to me because things like non-type >> generic parameters are *much bigger* than fixed-size arrays. > > Why do you think that's the case? This is a bit of a naive thing to say since we