[swift-evolution] Proposal: label-only constructors

[Sean Heber]

In this particular example, perhaps Key should be an enum instead of a struct.

l8r
Sean

Sent from my iPad

> On Dec 13, 2015, at 10:07 AM, ilya via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Good point on that. I still think the best solution is to take the existing syntax of
> 
> 
> struct Key {
>     init(forRSA:Void) { /* */ }
>     init(forCurve25519:Void) { /* */ }
>     init(forAES:Void) { /* */ }
> }
> 
> let a = Key(forRSA: ())
> 
> or 
> 
> let empty: Void = ()
> let c = Key(forAES: empty)
> 
> and make it somewhat easier to read.  Perhaps
> 
> let b = Key(forCurve25519: _ )
> 
> I think many people will read Key(forAES) as Key.init(_: forAES), so that may be not the best expression here.
> 
> 
> 
>> On Sun, Dec 13, 2015 at 4:21 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>> 
>>> On Dec 13, 2015, at 7:13 AM, ilya <ilya.nikokoshev at gmail.com> wrote:
>>> 
>>> You can easily call a private parametrized init from a class function though. 
>> 
>> 
>> Sure, but we're just shuffling the deck.  We've gone from a bad public API to a bad private API.
>> 
>> Actually, it's worse, because we now have BOTH a bad private API AND a bad public API.  There is a reason that NSData.dataWithData(...) is a Swift compile error.
>> 
>> The (ab)use of class functions as constructors is a holdover from ObjC times.  If you want to make an instance in Swift, you should type ClassName( and see what autocomplete suggests; you should not have to read through the documentation of class functions to see if they are secretly constructors that have been filed at the wrong shelf in the library.
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/73d6ecf0/attachment.html>