On Fri, 02 Feb 2007 12:57:06 +0200, Don Clugston <dac@nospam.com.au> wrote:

> ???
> This has been part of the compiler for a very long time. There's no need
> for the inline keyword, just use the -inline compiler switch and it
> happens automatically.
> Or did I miss something?

AFAIK, even with -inline, the compiler doesn't automatically inline functions in certain circumstances - for example, if they contain loops. Sometimes it is critical for the functions to be inlined - out of performance or security (obfuscation) reasons.

Either way, what are the disadvantages of such inline functions compared to the discussed expression types?

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com

Vladimir Panteleev wrote:
> On Fri, 02 Feb 2007 12:57:06 +0200, Don Clugston <dac@nospam.com.au>
> wrote:
> 
>> ??? This has been part of the compiler for a very long time.
>> There's no need for the inline keyword, just use the -inline
>> compiler switch and it happens automatically. Or did I miss
>> something?
> 
> AFAIK, even with -inline, the compiler doesn't automatically inline
> functions in certain circumstances - for example, if they contain
> loops. Sometimes it is critical for the functions to be inlined - out
> of performance or security (obfuscation) reasons.
> 
> Either way, what are the disadvantages of such inline functions
> compared to the discussed expression types?

They are different beasts. Expression transformations specify syntactic processing exclusively.

Andrei

Functions aren't powerful enough to be used in place of expressions.

-- Functions can't return references, which prevents you from using them as l-values. The best you can do is return a pointer, which you have to manually dereference.
-- All of the types in an expression are automatic, including the return type. Getting the parameter types for a function can be simple, but the return type can be difficult.
-- Functions can't take full advantage of features like conditionals, because conditionals can have two or more possible 'return types'. Functions can only return a single type.

Xinok wrote:
> Functions aren't powerful enough to be used in place of expressions.
> 
> -- Functions can't return references, which prevents you from using them as l-values. The best you can do is return a pointer, which you have to manually dereference.
> -- All of the types in an expression are automatic, including the return type. Getting the parameter types for a function can be simple, but the return type can be difficult.
> -- Functions can't take full advantage of features like conditionals, because conditionals can have two or more possible 'return types'. Functions can only return a single type.

Conditionals always have one return type that can be detected as typeof(true? T : U).

The advantage of expression aliases is that indeed there's no need to worry for their type. Also, expression aliases work when passing e.g. constant expressions to templates because they expand during compilation. The disadvantages are that (1) writing statements in the replacement expression is not possible, (2) separate compilation is not possible.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Xinok wrote:
>> Functions aren't powerful enough to be used in place of expressions.
>>
>> -- Functions can't return references, which prevents you from using them as l-values. The best you can do is return a pointer, which you have to manually dereference.
>> -- All of the types in an expression are automatic, including the return type. Getting the parameter types for a function can be simple, but the return type can be difficult.
>> -- Functions can't take full advantage of features like conditionals, because conditionals can have two or more possible 'return types'. Functions can only return a single type.
> 
> Conditionals always have one return type that can be detected as typeof(true? T : U).
> 
> The advantage of expression aliases is that indeed there's no need to worry for their type. 

That's already possible, albeit clumsy. You can duplicate the expression inside an anonymous delegate, and use D's automatic return type inference, together with an is( : return) expression. This works even when there are statements in the delegate, together with expressions.

So I suspect something even more general might be possible.

Also, expression aliases work when passing e.g.
> constant expressions to templates because they expand during compilation. The disadvantages are that (1) writing statements in the replacement expression is not possible, (2) separate compilation is not possible.
> 
> 
> Andrei

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Xinok wrote:
>>> Functions aren't powerful enough to be used in place of expressions.
>>>
>>> -- Functions can't return references, which prevents you from using them as l-values. The best you can do is return a pointer, which you have to manually dereference.
>>> -- All of the types in an expression are automatic, including the return type. Getting the parameter types for a function can be simple, but the return type can be difficult.
>>> -- Functions can't take full advantage of features like conditionals, because conditionals can have two or more possible 'return types'. Functions can only return a single type.
>>
>> Conditionals always have one return type that can be detected as typeof(true? T : U).
>>
>> The advantage of expression aliases is that indeed there's no need to worry for their type. 
> 
> That's already possible, albeit clumsy. You can duplicate the expression inside an anonymous delegate, and use D's automatic return type inference, together with an is( : return) expression. This works even when there are statements in the delegate, together with expressions.
> 
> So I suspect something even more general might be possible.

Oh, yes, it's definitely possible. "Worrying about" does not mean "can't do anything about" :o). It's just annoying. For example, half of varargs_reduce deals with types, although it doesn't care about them at all.

A more general thing I was thinking of was to allow statements to bind to aliases. Then D will have a pretty interesting macro mechanism.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Don Clugston wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Xinok wrote:
>>>> Functions aren't powerful enough to be used in place of expressions.
>>>>
>>>> -- Functions can't return references, which prevents you from using them as l-values. The best you can do is return a pointer, which you have to manually dereference.
>>>> -- All of the types in an expression are automatic, including the return type. Getting the parameter types for a function can be simple, but the return type can be difficult.
>>>> -- Functions can't take full advantage of features like conditionals, because conditionals can have two or more possible 'return types'. Functions can only return a single type.
>>>
>>> Conditionals always have one return type that can be detected as typeof(true? T : U).
>>>
>>> The advantage of expression aliases is that indeed there's no need to worry for their type. 
>>
>> That's already possible, albeit clumsy. You can duplicate the expression inside an anonymous delegate, and use D's automatic return type inference, together with an is( : return) expression. This works even when there are statements in the delegate, together with expressions.
>>
>> So I suspect something even more general might be possible.
> 
> Oh, yes, it's definitely possible. "Worrying about" does not mean "can't do anything about" :o). It's just annoying. For example, half of varargs_reduce deals with types, although it doesn't care about them at all.
> 
> A more general thing I was thinking of was to allow statements to bind to aliases. Then D will have a pretty interesting macro mechanism.

Agreed. I think mixins were supposed to be a replacement for macros, but they're just too limited.

> 
> 
> Andrei