"Bent Rasmussen" <exo@bent-rasmussen.info> escribió en el mensaje
news:cdf91l$2sjf$1@digitaldaemon.com
| I can't imagine. To test this write
|
|     type value = expr;
|
| where typeof(expr) is incompatible with type, and expr is an arbitrarily
| complex expression.
|
| It should be clear that since the compiler can catch type mismatches
between
| the type of value and the type of expr, it must know the type of expr and
| hence be able to deduce the type of a val/autotype.
|
| I can imagine implicit template instantiation complex to implement though.
| But then either it can deduce the types or it can't, in which case
| compilation fails.

Yes, I think that makes sense.

-----------------------
Carlos Santander Bernal

I agree that this would be a good and useful feature for 2.0.  In the meantime, it would be a very easy thing to implement with a preprocessing tool.

Andy Friesen wrote:
> It even looks (to my feeble brain, at least) easy to implement:
> 
>     autotype r = expr;
>     // equivalent to:
>     typeof(expr) r = expr;
> 
>  -- andy

Russ Lewis wrote:

> Andy Friesen wrote:
> 
>> It even looks (to my feeble brain, at least) easy to implement:
>>
>>     autotype r = expr;
>>     // equivalent to:
>>     typeof(expr) r = expr;
>>
>>  -- andy
> 
> I agree that this would be a good and useful feature for 2.0.  In the meantime, it would be a very easy thing to implement with a preprocessing tool.
> 

Maybe, but what I was trying to imply was that it's so easy to implement that it could realistically be added before 1.0. (the weight of the world hasn't crushed my hopes yet!)

 -- andy

Bent Rasmussen wrote:

>> B.t.w: autotypes for local variables have proven rather convenient in
> Sather
>> as well. There is no meta-programming possibility, so it really is just a matter of convenience, but still, you quickly get addicted to it...
> 
> It sure would be sweet to have both in 2.0. I like it even before I've tried it. :-)
> 
> val t, i;
> ...
> t = s[5 .. 25];
> i = index(s,"abc");

I think, the feature only makes sense for variables that are immediately initialized:

        val t = s[5 .. 25];
        val i = index(s,"abc");

since the initialization is needed to determine the type. Of course, it would be possible to allow predeclaring such variables, but then you would have to assure that the variable is initialized at exactly one point, and it would seem strange that the first assignment to the variable has a special meaning compared to the others.

Carlos Santander B. wrote:

> "Andy Friesen" <andy@ikagames.com> escribió en el mensaje
> news:cde51k$2dpc$1@digitaldaemon.com
> | Matthew wrote:
> || Since D is not going to have implicit instantiation, I suggest that we
> *must*
> || have the autotype keyword, which will be akin to the semantics proposed
> for auto
> || in C++ 0.x. That is to say, the type is deduced, at compile time - it's
> no
> || variant type! - from the initialising expression, so:
> ||
> || Thoughts, everyone? Walter?!?
> |
> 
> I don't really care about the name, but I do like the idea.
> 
> | It even looks (to my feeble brain, at least) easy to implement:
> |
> | autotype r = expr;
> | // equivalent to:
> | typeof(expr) r = expr;
> |
> |   -- andy
> 
> What if "expr" is really complex (like that really long expression that Matthew posted before) and the compiler can't directly determine what it's type is? Wouldn't it mean evaluating it twice? Of course, if it just can't happen, then just tell me so, I just wanna be sure.

In general, the compiler can always determine the type of an exception without knowledge of its usage. There are just two exceptions:

* function pointers/delegates to overloaded functions. The syntax here is not sufficient to determine which of the functions is meant, so the compiler has to look at the variable that it is assigned to.

* struct/array initializers. Even though these look like plain assignments at first sight, they are not.

In both cases, type deduction would not work. In all other cases, it is no problem.

>> I agree that this would be a good and useful feature for 2.0.  In the meantime, it would be a very easy thing to implement with a preprocessing tool.
>> 
>
>Maybe, but what I was trying to imply was that it's so easy to implement that it could realistically be added before 1.0. (the weight of the world hasn't crushed my hopes yet!)
>

Hmm, I proposed it about a half year ago and we still don't have it.


Anyway, are we going to allow something like this:

void foo (autotype bar)
{...}

So we would have the missed implicitly instantiated functions.

-- Matthias Becker

> since the initialization is needed to determine the type. Of course, it would be possible to allow predeclaring such variables, but then you would have to assure that the variable is initialized at exactly one point, and it would seem strange that the first assignment to the variable has a special meaning compared to the others.

I don't find it that confusing*, in fact an error message would clear up any confusion quite easily:

    "(23): attempt to redefine type of 't' from prior definition (15)"

or something like that. It is a choice to be made by the programmer. Its one more "use it if you like it, don't if you don't" kind of thing. But of course if it turns out confusing to too many then its probably not a good idea.

It would be interesting to have an editor with sufficient compiler interaction to annotate the types of values as you assign expressions to them.

* But then there's no experience with it to speak of.

What about multimethods? It would be fine if I can do following:

class Figure { ... }
class Rect : Figure { ... }
class Circle: Figure { ... }
class Triangle: Figure { ... }

float IntersectionSquare(Rect r, Circle c) // (1)
{ ... }

float IntersectionSquare(Circle r, Circle c) // (2)
{ ... }

float IntersectionSquare(Rect r, Figure f) // (3)
{ ... }

multimethod float IntersectionSquare(Figure a, Figure b);

void main()
{
Figure r = new Rect;
Figure c = new Circle;
Figure t = new Triangle;
float sq;

sq = IntersectionSquare(r, c); // (1) called
sq = IntersectionSquare(c, c); // (2) called
sq = IntersectionSquare(r, t); // (3) called
}

Any facts against?

Why the new keyword?  Doesn't D handle overload resolution just fine without it?


Sean

Norbert Nemec wrote:
> Bent Rasmussen wrote:
> 
> 
>>>B.t.w: autotypes for local variables have proven rather convenient in
>>
>>Sather
>>
>>>as well. There is no meta-programming possibility, so it really is just a
>>>matter of convenience, but still, you quickly get addicted to it...
>>
>>It sure would be sweet to have both in 2.0. I like it even before I've
>>tried it. :-)
>>
>>val t, i;
>>...
>>t = s[5 .. 25];
>>i = index(s,"abc");
> 
> 
> I think, the feature only makes sense for variables that are immediately
> initialized:
> 
>         val t = s[5 .. 25];
>         val i = index(s,"abc");
> 
> since the initialization is needed to determine the type. Of course, it
> would be possible to allow predeclaring such variables, but then you would
> have to assure that the variable is initialized at exactly one point, and
> it would seem strange that the first assignment to the variable has a
> special meaning compared to the others.

Right: "If it's easy to explain, it might be a good idea."  (quoth the zen of Python)

 - Can be used for local variables and constants only.
 - Must be initialized in its declaration.  The attribute's type is statically determined by the initializer.
 - Otherwise not special in any way. (no implicit constness, runtime variant behaviour or anything like that)

Also, this would offer a simple way to get an integer whose size is whatever the host CPU likes best: var x = 0;

 -- andy