Perhaps I should be!
But to be fair, although I'm way too used to it to think about it objectively, my instinct is that
func foo() -> Void {...}
...is confusing because it suggests the function returns something that represents 'nothing', whereas
func foo() {...}
...suggests to me that the function does not return anything at all. Unlike func foo {...}, which could potentially have multiple meanings, I'm not sure what else the latter example could mean.
At this point, this thread is going in circles. If you wish to proceed, despite the negative feedback, I suggest you create a branch of the compiler that allows the parentheses to be omitted and submit a PR to include a formal proposal.
The proposal only considers the case for length of tuple > 1, but the length of the proposed example is zero.
@Pampel wrote:
func foo() {...}...suggests to me that the function does not return anything at all. Unlike
func foo {...}, which could potentially have multiple meanings, I'm not sure what else the latter example could mean.
Generally leaving any typing should be inferred as unbound type.
Your example above would be inferred as: foo:Void->T where T gets inferred from the body.
Otherwise, the example func foo {...} should be inferred to foo:T may doesn't need to be a arrow type, depending on the body.
Unfortunately, swift already decided to infer func foo() {...} to must return a value of type Void.
In this regard it would be more sound to infer foo:Void->Void given func foo {}.
In this regard, @GetSwifty is right, though I don't like that much, likewise for func f<T>(t:T) {...} to be inferred as T->Void
In retrospect, perhaps Swift should have forced both an explicit return type and an explicit return for Void functions. However, this would go against practically every language that would be familiar to newcomers to Swift, especially those coming from ObjC, which were the first, and in some ways still primary, audience.
I don't think Swift's relaxed handling of Void functions in terms of syntax can, or should be, generalized to other, even related, features of the syntax. Other than scripting languages, I don't know of any that require parentheses for parameters, except in certain, very specific, cases.
I completely agree with Avi; this discussion is no longer going anywhere, and the path forward is to complete a proposal (including an implementation).
I agree. I have a proposal here:
Could you be the review manager?
@Nicholas_Maccharoli Under the current rules for Swift Evolution, proposals must be accompanied by a prototype implementation. You should work on that, and then update the proposal with a link to the PR on the main repo.
@Nicholas_Maccharoli Keep in mind that a core team member has already given the following guidance:
I'm sorry for not speaking up earlier, but I think it's very unlikely that this proposal would be accepted, and I'm not sure it's worth your time to work on it.
You can, of course, spend your time however you want.