(;) returns nothing rather than empty named tuple

[piever]

Intuitively I would have imagined that (;) would be the syntax for the empty NamedTuple, whereas it returns nothing instead. After posting it on slack it seems that the rationale is that it is parsing as a concatenation of expressions. For example (1;) returns 1, so (;) should return the value of the first expression which is nothing.

I'm not sure which is more intuitive but maybe it could be changed to return NamedTuple(). The change in technically breaking though I imagine in practice very little code will rely on (;) === nothing

[StefanKarpinski]

We should definitely fix this since the empty named tuple is something that it's useful to have syntax for whereas having (;) as a confusing syntax for nothing is distinctly non-useful.

[JeffBezanson]

Used to be a syntax error, then from what I can tell this "feature" was "added" in v0.5 :) Probably best to make it an error again in 1.1?

[StefanKarpinski]

Is the plan to make it an error and later use if for an empty named tuple? Or leave it as an error?

[JeffBezanson]

I'm not sure; I guess it's (slightly) breaking either way, so maybe it's equally good/bad to just switch it directly to an empty named tuple?

[StefanKarpinski]

so maybe it's equally good/bad to just switch it directly to an empty named tuple?

👍 yes, I think that's the way to go.

[JeffBezanson]

Triage is ok with that.

[JeffBezanson]

There is some package code (very little) that uses :(;) in macros to make an empty block expression.

[StefanKarpinski]

Triage has decided to make (;) an error for now.

[StefanKarpinski]

We never did end up doing anything about this, did we?

[JeffBezanson]

It doesn't seem too important. I can make a branch that turns it into an error though. MacroTools changed its use of it already, so it might be ok.

[JeffBezanson]

Here's something I don't think came up: how to parse (;;), (;;;) etc? Error? Still as an empty block?

[StefanKarpinski]

As 3- and 4-dimensional tuples, obviously.