Should the comma operator be removed in D2?
Yigal Chripun
yigal100 at gmail.com
Tue Nov 17 21:05:09 PST 2009
Bill Baxter wrote:
> On Tue, Nov 17, 2009 at 3:57 PM, retard <re at tard.com.invalid> wrote:
>> Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote:
>>
>>>> I agree, a tuple of one element (doesn't matter what type, array in
>>>> this case) should be semantically identical to that single element.
>>>>
>>>> proper semantics for language supported tuples should IMO include: 1)
>>>> syntax to explicitly [de]construct tuples and no auto-flattening 2) a
>>>> tuple of one element is identical to a scalar:
>>>> int a = 5; // scalar integer
>>>> auto b = (5); // tuple of one integer a == b // is true
>>> Interesting. It does kinda make sense. So should indexing work too?
>>> And properties? 5[0] == 5? 5.length == 1? If not that could be painful
>>> for functions that process generic N-tuples. If so then what does that
>>> do if the "scalar" type happens to be float*?
>> In some languages () is a distinct Unit type. Tuples are defined
>> recursively from the Pair type, e.g. Pair[int,int], Pair[int, Pair
>> [int,int]] === (int,int,int). And have a special indexing syntax with 1-
>> based indexing.
>
> That wasn't really the question. It was what should 5[0] do in D, if
> scalars are considered to be 1-tuples?
> I think that's a killer for 1-tuple / scalar equivalence in D.
> Neither behavior is acceptable in my opinion.
> So it seems you can't have 1-tuple/scalar equivalence unless you have
> a distinct tuple-indexing syntax.
>
> Right now std.typecons.tuple uses x.at!(0) because you can't have a
> x[i] return different types, but the built-in "A..." template tuples
> do it.
> So that's something that needs to be fixed anyway, because "good for
> me but not for thee" is lame. (Took that phrase from a review of
> Go...)
> I think probably D should allow a templated opIndex!(int) so that user
> types can implement tuple-like indexing where each index could be a
> different type.
>
> Or we should try to come up with another syntax for indexing tuples.
>
>
>>>> 3) function's argument list is a tuple like in ML:
>>>> void foo(int a, char b);
>>>> int a = 5; char b ='a';
>>>> auto tup = (5, 'a');
>>>> foo(a, b) is identical to foo(t);
>> Tuples can't encode things like by-ref, by-val, lazy etc.
>
> That does seem to kill that idea.
>
>
>>> That seems like a kind of auto-flattening. Shouldn't (t) be a tuple of
>>> a tuple?
>>> What if you have an actual tuple in the signature, like void foo((int
>>> a,char b))?
>>> Or you have both overloads -- foo(int,char) and foo((int,char)) I think
>>> I like Python's explicit "explode tuple" syntax better.
>>> foo(*t)
>>> Probably that syntax won't work for D, but I'd prefer explicit
>>> flattening over implicit.
>> Good boy.
>>
>>>> 4) unit type defined by the empty tuple instead of c-like void
>>> This is kind of neat, but does it actually change anything? Or just
>>> give an aesthetically pleasing meaning to void/unit?
>> The empty tuple can be considered to be the unit type.
>
> Yes, Yigal said basically that. The question I have is what practical
> difference does that make to the language?
> Seems no different from defining the empty tuple to be void, then
> renaming void to unit.
>
>
> --bb
to clarify what I meant regarding function args list lets look at a few
ML examples:
fun f1() = ()
f1 is unit -> unit
fun f2 (a) = a
f2 `a -> `a
fun f3 (a, b, (c, d)) = a + b + c + d
f3 is (`a, `a, (`a, `a)) -> `a
it doesn't auto flatten the tuples but the list of parameters is
equivalent to a tuple.
regarding unit type, it has by definition exactly one value, so a
function that is defined now in D to return "void" would return that
value and than it's perfectly legal to have foo(bar()) when bar returns
a unit type.
More information about the Digitalmars-d
mailing list