<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Optional.some(Void) gives me "Expected member name or constructor call after type name”.</div><div class=""><br class=""></div><div class="">And as I said, the compiler should not be allowed to use the absence of parentheses to infer a Void generic type; only when the generic type is known to be Void may the parentheses be omitted. Under this proposal, Optional.some would not be allowed.</div><div class=""><br class=""></div><div class="">The scenario I’m working with, which inspired this thought, is roughly:</div><div class=""><br class=""></div><div class="">enum Result<T> {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case success(T)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case failure(Error)</div><div class="">}</div><div class=""><br class=""></div><div class="">func doSomething(completion: @escaping (Result<Void>)->()) { /* At some point, call completion(.success(())) */ }</div><div class=""><br class=""></div><div class="">The idea is that in case of success, I merely want to indicate success, whereas in case of an error I want to pass the error through to the completion. This requires calling `completion(.success(()))`. I don’t think I should have to make another enum with the same cases but no associated value for success (and no generic type) to make this work nicely — that makes things brittle in case I ever want to replace Void with a different type.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jul 25, 2017, at 5:20 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Yes, I discussed this some time back. It breaks some things with overloads, if I recall, but off the top of my head not recalling what.<br class=""><br class="">At some point, I also suggested regarding any case without associated values as equivalent to a case with an associated value of type Void. This was never adopted. There _is_ an underlying issue with that idea, as the property “foo” is not the same as the method “foo(_: Void)”, and it is even permitted to have both of these on the same type. The purpose of the most recent Swift proposal on enum cases was to align the syntax with functions as closely as possible; if overloading the base name of a case (as proposed back then to favorable reviews) is ever allowed, then the same will naturally be possible with enums (that is, a case named “foo” and another named “foo(_: Void)” in the same type).<br class=""><br class="">In the case of concrete enums, a case with associated value of type Void can be given a default value once they are supported (already approved); the trouble here is that in the generic case presented here the same is not possible. It is unclear to me whether this special rule would see broad use, as it appears to come into play *only* for a generic enum. Moreover, in the one scenario I can think of, it reads cryptically: “let foo = Optional.some” would then be allowed (while “let bar = Optional.none” still would not). The upside is that it avoids having to write four or six letters (“Optional.some(Void())” is never necessary, as it’s also just “Optional.some(Void)”, and that reads acceptably in my view).<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jul 25, 2017 at 15:26 David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""></div><div class="">On Jul 25, 2017, at 12:38, Robert Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Currently if you have the following enum:<div class=""><br class=""></div><div class="">enum E<T> {<br class=""><span class="m_7478467993860922014Apple-tab-span" style="white-space:pre-wrap"> </span>case c(T)<br class="">}</div><div class=""><br class=""></div><div class="">then if T is Void, you have to write one of the following:</div><div class=""><br class=""></div><div class=""><font face="Inconsolata" class="">let x: E<Void> = .c(Void())</font></div><div class=""><font face="Inconsolata" class="">let y: E<Void> = .c(())</font></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><div class="">let x: E<Void> = .c</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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(())`.</div><div class=""><br class=""></div><div class="">Thoughts?</div></div></blockquote><br class=""></div><div dir="auto" class=""><div class="">My first response is +1</div><div class=""><br class=""></div><div class="">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 `<span style="background-color:rgba(255,255,255,0)" class="">func foo(x: Void = ()) {...}`?</span> I have a sneaking suspicion that this question's already been asked, but I'm not sure.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>