[swift-evolution] Proposal: label-only constructors
Andrew Bennett
cacoyi at gmail.com
Mon Dec 14 03:43:16 CST 2015
Interesting suggestion :)
Perhaps, try doing the work outside the constructor, then the static
function suggestions work:
struct Key {
public static func createRSA() {
var data: String
// calculate RSA
...
return Key(bitLength: 2048, data: data)
}
private init(bitLength: Int, data: String) {
self.bitLength = bitLength
self.data = data
}
}
var myKey = Key.createRSA()
In my opinion this is much less ambiguous to the compiler and programmer. I
personally wouldn't be sure which of these 'Key(withRSA)' was:
let withRSA: Int
init(_ something: Int)
Or:
init(withRSA _ _)
On Mon, Dec 14, 2015 at 6:22 PM, David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:
>
> > On Dec 13, 2015, at 1:56 PM, Drew Crawford <drew at sealedabstract.com>
> 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.
>
> Granted. I think it’s just sadly one of those things that are lost when we
> combine the allocation and the initialization phase. I don’t like the
> labels as you’ve proposed because they are yet another special thing about
> initialization. For example, to solve this problem with functions, we could
> simply change the name of them.
>
> Your problem also reminds me of the cluster cluster problem. While they
> are not quite the same, they share many of the same concerns. It’s not a
> stretch to return different types from the Key initializer so that you
> don’t need to waste 1024bits with a 128bit key is all that’s needed. Of
> course, this requires sized arrays that Swift doesn’t have yet or some
> other construct to get a fixed size, but I think the point is clear.
>
> Unfortunately, I think Dave’s workaround is probably the best for your
> specific use case.
>
> > struct Key {
> > enum RSA_ { case RSA }
> > init(_: RSA_) { ... }
> >
> > enum AES_ { case AES }
> > init(_: AES_) { ... }
> > }
> >
> > Key(.RSA)
> > Key(.AES)
>
>
> Then you have this:
>
> > Q: Can we extend this to support arbitrary labels e.g. `init(random
> length: 2000)` vs `init(zeroed length: 2000)`, `mkdir(path,
> creatingIntermediateDirectoriesIfRequired)` and many more?
> > A: Yes, although these are probably more controversial proposals than
> simply supporting multiple parameterless constructors.
>
> I’m not sure this really applies generally. What if I want a mkdir() that
> doesn’t create the directories if required? This seems to fall right into
> the strong house of default parameters.
>
> -David
> _______________________________________________
> 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/20151214/5827663c/attachment.html>
More information about the swift-evolution
mailing list