1)  No operator function opIn().  Everyone loves this operator why not let us overload it ?  Its the only operator we can't overload.

2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration.  I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.

3)  Not really an inconsistency	, but I recently ran into this one _again_ http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/36922 .

Thanks for listening,
Charles

Charlie escribió:

> 2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration.  I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.

Yeah, this was discussed ~100 times. I hope it to be fixed soon.

--
Tom;

Charlie wrote:
> 2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration.  I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.

auto can mean many many things!!

I prefer to get rid of auto all together.
for automatic type inference ==> use 'var'
for RAII, hmm, maybe use something like 'raii'

# raii var foo = new Foo;

Hasan Aljudy wrote:
> Charlie wrote:
> 
>> 2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration.  I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.
> 
> 
> auto can mean many many things!!
> 
> I prefer to get rid of auto all together.
> for automatic type inference ==> use 'var'
> for RAII, hmm, maybe use something like 'raii'
> 
> # raii var foo = new Foo;
> 
> 
IIRC that would be:

#raii foo = new Foo;

the "auto" dosn't indicate auto typing, it's just a storage classe to indecate a decleration. "auto" is used because most of the time it has no effect.

These all works:

void main()
{
        auto f2 = cast(int)'\n';
        const f3 = cast(int)'\n';
        extern f5 = cast(int)'\n';
        static f8 = cast(int)'\n';
        synchronized f9 = cast(int)'\n';
}

see http://www.digitalmars.com/d/declaration.html#AutoDeclaration

Hasan Aljudy wrote:
> Charlie wrote:
>> 2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration.  I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.
> 
> auto can mean many many things!!
> 
> I prefer to get rid of auto all together.
> for automatic type inference ==> use 'var'

For what it's worth, the next iteration of C++ will use 'auto' to denote automatic type inference.

> for RAII, hmm, maybe use something like 'raii'
> 
> # raii var foo = new Foo;

I still think the signifier for this is probably more appropriately associated with the instance than with the reference, since 'raii' isn't really a type qualifier.  I'd prefer:

auto foo = local Foo;

where 'auto' denotes automatic type inference and 'local' replaces 'new' to denote stack-based construction.  As far as 'local' is concerned, it's too bad 'new' is so generic.  Perhaps it should be 'new local' for scoped allocations?


Sean

> auto foo = local Foo;
> 
> where 'auto' denotes automatic type inference and 'local' replaces 'new' to denote stack-based construction.  As far as 'local' is concerned, it's too bad 'new' is so generic.  Perhaps it should be 'new local' for scoped allocations?

or using the already available new() syntax:

auto foo = new(local) Foo;

(Of course this will cause conflicts with any overridden 'new' in the class)

Anyway, I think I've read a post from Walter in which he seemed to like the implicit new/ctor syntax:

Foo f = new Foo(...);// heap
Foo f(...); //stack


L.

BCS wrote:
> Hasan Aljudy wrote:
>> Charlie wrote:
>>
>>> 2)  auto auto foo = new Class;  The current double meaning of auto won't  allow for both a RAII and type-deduced variable declaration. I think every other language use's 'var' or similar ( var gets my vote, used in php, javascript, C#-3.0) .  The current error is 'redundant storage class 'auto''.
>>
>>
>> auto can mean many many things!!
>>
>> I prefer to get rid of auto all together.
>> for automatic type inference ==> use 'var'
>> for RAII, hmm, maybe use something like 'raii'
>>
>> # raii var foo = new Foo;
>>
>>
> IIRC that would be:
> 
> #raii foo = new Foo;
> 
> the "auto" dosn't indicate auto typing, it's just a storage classe to indecate a decleration. "auto" is used because most of the time it has no effect.

Maybe that common confusion could be lifted by introducing a new storage class (e.g. "local" or "var") indicating a "plain old local variable". This would be the default for any variable declared with a type and without storage class, but it would be useful in declaring a type-induced variable that is not intended to be an auto variable.

> 
> These all works:
> 
> void main()
> {
>         auto f2 = cast(int)'\n';
>         const f3 = cast(int)'\n';
>         extern f5 = cast(int)'\n';
>         static f8 = cast(int)'\n';
>         synchronized f9 = cast(int)'\n';
> }
> 
> see http://www.digitalmars.com/d/declaration.html#AutoDeclaration

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:e596k7$2k4o$1@digitaldaemon.com...

> Maybe that common confusion could be lifted by introducing a new storage class (e.g. "local" or "var") indicating a "plain old local variable". This would be the default for any variable declared with a type and without storage class, but it would be useful in declaring a type-induced variable that is not intended to be an auto variable.

We already have it; it's called "auto"  ;)  That's exactly what auto means - a plain old variable, one which is not accessible once the scope ends.  It's already the default storage class for variables declared without one. That's why we use auto to indicate type inference for most variables, because they're plain old local variables, and that's the default storage class.

The problem is just when it comes to auto classes.  Either we come up with a new keyword for the behavior of auto classes, i.e. "raii":

raii Foo f = new Foo();

// Type inference
raii g = new Goo();

Or, something I was thinking - just reuse scope, as it's not used by itself anywhere.

scope Foo f = new Foo();

Though I'll admit, it's not as self-explanatory as "raii Foo".

Jarrett Billingsley wrote:
> The problem is just when it comes to auto classes.  Either we come up with a new keyword for the behavior of auto classes, i.e. "raii":
> 
> raii Foo f = new Foo();
> 
> // Type inference
> raii g = new Goo();
> 
> Or, something I was thinking - just reuse scope, as it's not used by itself anywhere.
> 
> scope Foo f = new Foo();
> 
> Though I'll admit, it's not as self-explanatory as "raii Foo". 



Are you kidding? RAII is about as self explanatory as a goat in a tumble-dryer. On the face of it, the use of 'scope' here seems like a great idea :)

kris wrote:
> Jarrett Billingsley wrote:
>> The problem is just when it comes to auto classes.  Either we come up with a new keyword for the behavior of auto classes, i.e. "raii":
>>
>> raii Foo f = new Foo();
>>
>> // Type inference
>> raii g = new Goo();
>>
>> Or, something I was thinking - just reuse scope, as it's not used by itself anywhere.
>>
>> scope Foo f = new Foo();
>>
>> Though I'll admit, it's not as self-explanatory as "raii Foo". 
> 
> Are you kidding? RAII is about as self explanatory as a goat in a tumble-dryer. On the face of it, the use of 'scope' here seems like a great idea :)

I agree with you on raii. But I think local would be the optimal
keyword. local in scope, local on stack. local would be up to the
compiler to implement, depending on the environment, like register
in C. (meaning could even be tuned by a compiler switch).
scope is a good second IMO.

Roald