On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud <philippe.sig...@gmail.com> wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
<seewebsitetocontac...@semitwist.com> wrote:
That said, I'm not necessarily opposed to the strict separation if
we had a good candidate for built-in tuple literal syntax. But *if*
the best we have is parens (and maybe there *is* something better?)
then maybe this would be an acceptable way to achieve it?
If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?
I'm all for that. In fact, I was was just about to post the same
suggestion.
My bikeshed is colored one of these:
(:1,2)
(|1,2)
At that point you might as well just use
import std.typecons : q = tuple, Q = Tuple;
Q!(int, int) foo(){
return q(1, 2);
}
If built-in tuples are not going to look like
(1, 2)
then imho we might as well leave them out, while still addressing
unpacking in the locations bearophile has designated.
Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.
For example choosing { 1, 2} to represent a tuple?
I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)
Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:
{ foo(); } // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon
Not sure if that's a big enough deal, though.
...
q(foo())
