View mode: basic / threaded / horizontal-split · Log in · Help
May 25, 2006
A few inconsistentcies left
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
May 25, 2006
Re: A few inconsistentcies left
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;
May 25, 2006
Re: A few inconsistentcies left
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;
May 25, 2006
Re: A few inconsistentcies left
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
May 25, 2006
Re: A few inconsistentcies left
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
May 26, 2006
Re: A few inconsistentcies left
> 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.
May 27, 2006
Explicit keyword for "plain old local variable" storage class?
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
May 27, 2006
Re: Explicit keyword for "plain old local variable" storage class?
"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".
May 27, 2006
Re: Explicit keyword for "plain old local variable" storage class?
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 :)
May 27, 2006
Re: Explicit keyword for "plain old local variable" storage class?
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home