[swift-evolution] Proposal: label-only constructors

[David Owens II]

> 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