Russell Lewis wrote:

> Norbert Nemec wrote:
>> Kimberley Burchett wrote:
>> 
>> 
>>>In article <b09jar$5na$1@digitaldaemon.com>, Sean L. Palmer says...
>>>
>>>>I believe I prefer a new operator such as := or ::= over the "var" keyword. "var" is more in-line with how C, C++, and D parse declarations though.
>>>
>>>I don't mind ::= and I generally like to use existing syntax if possible. However, it would look weird to use ::= for a return type.  Example:
>> 
>> 
>> Please forget about using it for return types. One would need to take a look at the implementation to get the necessary information for the interface. It is nice for local variables, where declaration and "implementation" (i.e. the expression that actually determines the type) are always directly at the same place, but for nothing else. Allowing this "undeterminedness" to spread outside of the function scope woule really make the program unreadable, and in case of recursive functions, the compiler would not even able to determine any type at all.
> 
> Don't be so quick to judge it.  Often, APIs return "handles" and such. The user is NEVER supposed to access them, although they often are just typedef's of void pointers or unsigned integers.  A function that returned handle could return var.

But that doesn't fit at all with the meaning of "var" as discussed for local variable declaration. "var" is not an unknown type, but a definite type to be determined at compile time. It is semantically identical to specifying the type by hand. Just saves typing and editing whenever the type might change.

Norbert Nemec wrote:
> 
> But that doesn't fit at all with the meaning of "var" as discussed for local variable declaration. "var" is not an unknown type, but a definite type to be determined at compile time. It is semantically identical to specifying the type by hand. Just saves typing and editing whenever the type might change.
> 

Particularly, in templates where it *has* to change, but shall be known at instantiation. And it might save one from picking up the CPUs native type to save the intermediate results of a calculation.

-i.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b09jar$5na$1@digitaldaemon.com...
> Where is an D expression's type not 100% deterministic?  It's never determined by the type of the result variable.  So it must be determinable just from the expression itself and any declarations that are in scope.  I can't think of a single example.

There are two examples:

1) &func, where func is an overloaded function. Which overloaded function it
is gets determined by type inference.
2) "string", where whether it is a wchar[] or char[] is determined by type
inference.

I really don't like either of those, but never found a palatable alternative. The first exists in C++, the second does not (as L"string" is used). I have some experience with C++ L strings, and the clumsy use of macros to convert back and forth, and found the result unacceptable.

"Kimberley Burchett" <kimbly at kimbly.comKimberley_member@pathlink.com> wrote in message news:b0a8c3$iuq$1@digitaldaemon.com...
> ::= add(SomeType x, SomeType y) {
> return x+y;
> }

Inferring the return type of functions requires that the compiler be able to do the semantic analysis of the function before its type can be determined. This is a problem not only for the case of recursive function calls, but for the compiler when trying to figure out what order to do the semantic analysis of functions in.

I don't think it will work.

But the var idea does have a lot of merit if constrained to be for local variables.