[swift-evolution] Proposal: label-only constructors

[Jason Dusek]

Is this equivalent to having "flags" for functions? Like `--rsa`, `--aes`?
On Sun, 13 Dec 2015 at 13:56, Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:

> The problems with enums as parameters were explained in the proposal.  I
> don't see how these responses address any of the concerns that were
> initially raised.
>
>
> On Dec 13, 2015, at 2:25 PM, David Owens II via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Agreed. It's also likely that you'll be setting some internal flag with
> this information already.
>
> Sent from my iPhone
>
> On Dec 13, 2015, at 8:55 AM, Harlan Haskins via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Also I think it’d be cleaner to just accept an enum in one initializer
>
> enum KeyType {
>     case RSA
>     case Curve25519
>     case AES
> }
>
> Then you get that semantic niceness of:
>
> init(keyType: .RSA)
> init(keyType: .Curve25519)
> init(keyType: .AES)
>
> — Harlan
>
> On Dec 13, 2015, at 11:41 AM, Sean Heber via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/7ffdcbe6/attachment.html>