> On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Currently if you have the following enum:
>
> enum E<T> {
> case c(T)
> }
>
> then if T is Void, you have to write one of the following:
>
> let x: E<Void> = .c(Void())
> let y: E<Void> = .c(())
>
> Looks awkward, no? In this case you can omit `<Void>` after `E` because it
> can be inferred, but if writing a (non-generic) function taking an argument
> of type `E<Void>`, then the `<Void>` cannot be omitted, and you still have to
> write `.c(())` for the case name.
>
> I’m proposing that for enum cases with a single associated value of Void
> type, or of a generic type that is equal to Void in some instance, you may
> omit the parentheses altogether and merely write
>
> let x: E<Void> = .c
>
> The rationale is twofold: first, double parentheses just looks bad; second,
> there is only a single value of type Void, which means the associated value
> of `.c` is trivially inferable, and hence should be omissible.
>
> I am not proposing that a bare `E.c` imply a type of `E<Void>` — `E.c` should
> still be illegal in the absence of specification of the generic type — only
> that when the type is known to be `E<Void>`, `.c` can replace `.c(())`.
>
> Thoughts?
My first response is +1
My second response is to ask just how much would it break things to expand this
and allow omitting the argument anywhere its type is known to be Void? Maybe by
implicitly providing a default value of `()` wherever there's a `Void`
argument? Like make `func foo(x: Void) {...}` implicitly become `func foo(x:
Void = ()) {...}`? I have a sneaking suspicion that this question's already
been asked, but I'm not sure.
- Dave Sweeris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
