On 5/18/11 5:12 PM, Timon Gehr wrote:
Timon Gehr:
Library code should make use of the language to implement its semantics.
Not the other way round.
Why?
Short story: Obvious?
Do you really want to make some non-built-in types more equal than others? Why
would you want to have a dependency cycle between std and the compiler?
Longer story: You get all the drawbacks of a library-based solution except
literal
syntax (a one-character alias for tuple can already make up much of it without
work from the compiler so your benefit is basically zero).
But you want improved return type deduction, many will want tuple assignments in
the style (a,b)=(b-a,a+b), etc. tuple cannot do it. Therefore the part the
compiler takes will get so large that in the end the only relict of the library
stuff will be that you have to import std.typecons; or else you will get some
strange errors that do not at all look like your code. (Or even more silly, the
compiler will directly nag you "Did you forget to import std.typecons?"). The
question is, do you want to import typecons or not. It is just that and
furthermore a question of clean design.
How tuples are handled internally should be a compiler/runtime thing, not a
standard library thing. I would be fine with Tuple!(T) defining conversions from
and to the built-in tuple.
Another reason I dislike it: it looks different to other "tuple literals"
that are already built-in:
foo (note, how, this, is, a, tuple, "!");
Looking different from the built-in ones was the point of it, to avoid clashes.
No. There is no way it could clash with foo (a,b,c).
The only use case where the straightforward solution would clash is something
like
this:
auto a=(i++,j++,k++);
Nobody who is sane writes such code!
Still, I think (|1,2,3|) is not optimal.
Please, invent better things :-)
1. Deprecate using CommaExpression inside ParanthesizedExpression. (This does
not
affect most code that uses the comma operator!)
2. Wait a few releases.
3. Introduce straightforward, built-in tuples:
[snip]
We've been thinking of this approach but it would be difficult to pull off.
One possibility that I hadn't thought before is to use ";" for
separating tuple elements. Upon a casual inspection, it turns out no
statement can be enclosed directly in "(" and ")" so there's no
ambiguity. It would also take care of the issue "did you mean to pass
them as function arguments, or as one tuple argument?" Just a thought...
auto t=(1; "string"; 'c');
Ehm.
Andrei
