I think D could be made much more powerful by extending the tupleof property
(or a new property) to arbitrary expressions, similar to stringof, along the lines of

(func(a, b)).tupleof resulting in a tuple like Tuple!(int function(int, int), (a, b)).

Or deeper: ((a+b)*c).tupleof == Tuple!(int function(int, int), ((int function(int, int), a, b), c));

From what I can see, that would allow D to evaluate arbitrarily complex expressions with the minimal amount of language change.
And it also looks a bit like LISP :p

Whaddya think?

 -- greetings, downs

Downs wrote:
> I think D could be made much more powerful by extending the tupleof property
> (or a new property) to arbitrary expressions, similar to stringof, along the lines of
> 
> (func(a, b)).tupleof resulting in a tuple like Tuple!(int function(int, int), (a, b)).
> 
> Or deeper: ((a+b)*c).tupleof == Tuple!(int function(int, int), ((int function(int, int), a, b), c));

Currently tuples can't be nested; they automatically flatten. You can't have a tuple inside a tuple.

What are 'a' and 'b' inside the tuple? Are they types, aliases, or values?

eg
int a;
const int b=7;
alias c a;
What would ((a+b)*c).tupleof return?

>  From what I can see, that would allow D to evaluate arbitrarily complex expressions with the minimal amount of language change.
> And it also looks a bit like LISP :p
> 
> Whaddya think?
> 
>  -- greetings, downs

Don Clugston wrote:
> Downs wrote:
>> I think D could be made much more powerful by extending the tupleof property
>> (or a new property) to arbitrary expressions, similar to stringof, along the lines of
>>
>> (func(a, b)).tupleof resulting in a tuple like Tuple!(int function(int, int), (a, b)).
>>
>> Or deeper: ((a+b)*c).tupleof == Tuple!(int function(int, int), ((int function(int, int), a, b), c));
> 
> Currently tuples can't be nested; they automatically flatten. You can't have a tuple inside a tuple.

Right, I forgot. Damn.
Is this necessary behavior? I mean, is there any reason why we need automatic flattening?
If they weren't, could they be flattened manually?

> 
> What are 'a' and 'b' inside the tuple? Are they types, aliases, or values?
> 
> eg
> int a;
> const int b=7;
> alias c a;
> What would ((a+b)*c).tupleof return?

Not sure actually, I just thought it might be neat.
I'm kinda undecided between values and aliases.

Downs wrote:

> Don Clugston wrote:
>> Downs wrote:
>>> I think D could be made much more powerful by extending the tupleof
>>> property
>>> (or a new property) to arbitrary expressions, similar to stringof,
>>> along the lines of
>>>
>>> (func(a, b)).tupleof resulting in a tuple like Tuple!(int
>>> function(int, int), (a, b)).
>>>
>>> Or deeper: ((a+b)*c).tupleof == Tuple!(int function(int, int), ((int
>>> function(int, int), a, b), c));
>> 
>> Currently tuples can't be nested; they automatically flatten. You can't have a tuple inside a tuple.
> 
> Right, I forgot. Damn.
> Is this necessary behavior? I mean, is there any reason why we need
> automatic flattening? If they weren't, could they be flattened manually?

This is something I have been thinking too. Maybe the rationale behind this is that function parameter signatures are tuples and vice versa. But there are many cases where you would need nested tuples. Let's say you want to test the equality of two tuples. Or do lazy evaluation.

Hehe, I guess you just cannot avoid implementing a superset of Lisp if you want to make as expressive a language.

Also one other thing, wouldn't ? : operator be more consistent with the runtime version if it evaluated lazily on compile time. That would also avoid the need for long static if blocks in many places.

> 
>> 
>> What are 'a' and 'b' inside the tuple? Are they types, aliases, or values?
>> 
>> eg
>> int a;
>> const int b=7;
>> alias c a;
>> What would ((a+b)*c).tupleof return?
> 
> Not sure actually, I just thought it might be neat.
> I'm kinda undecided between values and aliases.

--