www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - disable

reply Leandro Lucarella <llucax gmail.com> writes:
What is  disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336

Thanks.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cada uno da lo que recibe
y luego recibe lo que da
nada es más simple
no hay otra norma
nada se pierde
todo se transforma
Jan 14 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?
 http://www.dsource.org/projects/dmd/changeset/336

 Thanks.


#define STCdisable       0x2000000000LL // for functions that are not 
callable
Jan 14 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Pelle MÃ¥nsson wrote:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?
 http://www.dsource.org/projects/dmd/changeset/336

 Thanks.


 #define STCdisable       0x2000000000LL // for functions that are not 
 callable


The main idea is to allow creation of noncopyable types by marking 
this(this) as  disable.

Noncopyable types are pivotal for a number of idioms important in 
concurrency and elsewhere.


Andrei
Jan 14 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?




 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.
 
 Noncopyable types are pivotal for a number of idioms important in 
 concurrency and elsewhere.



It's similar to the motivation for the "= delete" capability proposed 
for C++0x. Lawrence Crowl makes a good case for it:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete
Jan 14 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Noncopyable types are pivotal for a number of idioms important in 
 concurrency and elsewhere.


Why isn't it named  nocopy or something similar?

Bye,
bearophile
Jan 14 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 Noncopyable types are pivotal for a number of idioms important in 
 concurrency and elsewhere.


 
 Why isn't it named  nocopy or something similar?


Because  disable applies to any function.

Andrei
Jan 14 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Because  disable applies to any function.


What's the purpose of disabling any random function? (Is such extra generality
worth its cognitive cost?)

Bye,
bearophile
Jan 14 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 Because  disable applies to any function.


 
 What's the purpose of disabling any random function? (Is such extra generality
worth its cognitive cost?)


There's no added cognitive cost from  nocopy to  disable (au contraire 
I'd say).

Andrei
Jan 14 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 14 de enero a las 19:05 me escribiste:

 Andrei Alexandrescu:

 Because  disable applies to any function.


 
 What's the purpose of disabling any random function? (Is such extra generality
worth its cognitive cost?)


Exactly, it seems to me that the generalization in this case is
counterproductive. What's the point on disabling a function, except for
those automatically generated by the compiler.

I this it would be cleaner to add some kind of annotation  noncopiable to
the struct/class, instead of annotating each constructor.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Do not get mad with others
Because they know more than you
It is not their fault
Jan 14 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Exactly, it seems to me that the generalization in this case is
 counterproductive.


It's similar to the motivation for the "= delete" capability proposed 
for C++0x. Lawrence Crowl makes a good case for it:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete

Lawrence mentions several uses for it.
Jan 14 2010
parent reply john foo <bar land.net> writes:
Walter Bright Wrote:


 Leandro Lucarella wrote:

 Exactly, it seems to me that the generalization in this case is
 counterproductive.


 
 It's similar to the motivation for the "= delete" capability proposed 
 for C++0x. Lawrence Crowl makes a good case for it:
 
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete
 
 Lawrence mentions several uses for it.


So you're copying yet another C++0x feature and renaming it to attract more
positive publicity..
Jan 14 2010
next sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/15/2010 07:35 AM, john foo wrote:

 Walter Bright Wrote:


 Leandro Lucarella wrote:

 Exactly, it seems to me that the generalization in this case is
 counterproductive.


 It's similar to the motivation for the "= delete" capability proposed
 for C++0x. Lawrence Crowl makes a good case for it:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete

 Lawrence mentions several uses for it.


 So you're copying yet another C++0x feature and renaming it to attract more
positive publicity..


How is this not a good thing?
Jan 14 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
john foo wrote:

 So you're copying yet another C++0x feature and renaming it to
 attract more positive publicity..


D is full of good ideas from other languages. Hopefully, we left the bad 
ideas behind.
Jan 14 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
john foo wrote:

 Walter Bright Wrote:
 

 Leandro Lucarella wrote:

 Exactly, it seems to me that the generalization in this case is
 counterproductive.


 It's similar to the motivation for the "= delete" capability proposed 
 for C++0x. Lawrence Crowl makes a good case for it:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete

 Lawrence mentions several uses for it.


 
 So you're copying yet another C++0x feature and renaming it to attract more
positive publicity..


At least we copy with attribution :o).

Andrei
Jan 14 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 At least we copy with attribution :o).


The good thing is that programming language designs are not yet copyrighted :-)
So D can copy from many languages.

Bye,
bearophile
Jan 15 2010
parent retard <re tard.com.invalid> writes:
Fri, 15 Jan 2010 03:19:16 -0500, bearophile wrote:


 Andrei Alexandrescu:

 At least we copy with attribution :o).


 
 The good thing is that programming language designs are not yet
 copyrighted :-) So D can copy from many languages.


Language specification documents can be copyrighted even though ideas are 
free (unless patented in the USA - software patents aren't enforceable in 
Europe yet and we all probably know that e.g. China doesn't care about IP 
rights anyway).

If you implement old ideas invented by some computer scientist, it's 
polite to give attribution - preferably to the original inventor. Even 
the C++0x community should remember this, since most of their "new" ideas 
are stolen from old CS papers. For instance the Abrahams & Gurtovoy book 
doesn't attribute functional languages that much whilst most of their 
content is stolen from the functional language community. They just 
geniously ran sed 's/function/meta-function/g' over some old text, 
mentioned some random c++ gurus like Unruh and veldhuizen, and, lo and 
behold, hardcore new computer science was born.
Jan 15 2010
prev sibling parent "Danny Wilson" <danny decube.net> writes:
On Fri, 15 Jan 2010 07:54:56 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 At least we copy with attribution :o).

 Andrei


 lol

And yes, it was out loud.

:D
Jan 15 2010
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
john foo wrote:

 Walter Bright Wrote:

 




http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.html#delete

 Lawrence mentions several uses for it.


 So you're copying yet another C++0x feature and renaming it to 


attract more positive publicity..

C++0x would have used a different name than 'delete' if it did not have 
a major point of not introducing new keywords. This is deliberate to try 
to prevent breaking legacy code, written even in C.

Even the keyword 'auto' is C's defunct 'auto' in C++0x (and I strongly 
belive also in D); just because "automatic variable" and "automatically 
typed" both start with "auto". :)

Ali
Jan 15 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
 Even the keyword 'auto' is C's defunct 'auto' in C++0x (and I strongly 
 belive also in D); just because "automatic variable" and "automatically 
 typed" both start with "auto". :)
 
 Ali


If I'm not mistaken (surely I am), D's auto keyword is the same as C's. But D
has type inference so we just state the storage class and not the type.

http://www.digitalmars.com/d/2.0/declaration.html#AutoDeclaration
Jan 15 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Jesse Phillips wrote:

 Even the keyword 'auto' is C's defunct 'auto' in C++0x (and I strongly
 belive also in D); just because "automatic variable" and "automatically
 typed" both start with "auto". :)

 Ali


 If I'm not mistaken (surely I am), D's auto keyword is the same as C's.


C's auto is about lifetimes (storage duration). 'auto' makes function 
local variables and parameters automatically terminated upon exit from 
functions.

Since that's the default in C (and C++), 'auto' is redundant there. 
That's why the keyword has been reused by C++0x to mean "infer the type".


 But D has type inference so we just state the storage class and not 


the type.

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


It is news to me that the following works without 'auto':

struct S
{
     int i;

     this(int i)
     {
         this.i = i;
     }
}

void main()
{
     const c = S(42);   // <-- no 'auto' needed
}

Now I realize that 'auto' is for when we want type inference for mutable 
variables because this doesn't work:

     c = S(42);   // <-- compiler ERROR

So we have to use a keyword:

     auto c = S(42);
     ++c.i;

If I understand it correctly, 'auto' serves as the nonexistent 'mutable' 
keyword in this case.

I think to be consistent, I will continue using 'auto' even for when a 
storage class is specified:

     const auto c = S(42);  // works too

For me, that gives 'auto' a single meaning: "the inferred type".

Do I get it right? :)

Ali
Jan 15 2010
parent reply Leandro Lucarella <llucax gmail.com> writes:
Ali Çehreli, el 15 de enero a las 16:01 me escribiste:

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


 
 It is news to me that the following works without 'auto':
 
 struct S
 {
     int i;
 
     this(int i)
     {
         this.i = i;
     }
 }
 
 void main()
 {
     const c = S(42);   // <-- no 'auto' needed
 }
 
 Now I realize that 'auto' is for when we want type inference for
 mutable variables because this doesn't work:
 
     c = S(42);   // <-- compiler ERROR
 
 So we have to use a keyword:
 
     auto c = S(42);
     ++c.i;
 
 If I understand it correctly, 'auto' serves as the nonexistent
 'mutable' keyword in this case.
 
 I think to be consistent, I will continue using 'auto' even for when
 a storage class is specified:
 
     const auto c = S(42);  // works too
 
 For me, that gives 'auto' a single meaning: "the inferred type".
 
 Do I get it right? :)


I don't think so. auto means in D the same that in C/C++, the difference
is that D do type inference when a *storage class* is given. const,
static, immutable, shared are other storage classs, so when you used
them, you can infer the type too (if no type is given).

You can do const auto c = 1; (I think), but I can't do static auto c = 1;
(I think too). You can omit auto when declaring automatic variables if you
specify the type (seen the other way :), because it defaults to auto. And
you can omit the type if you use a storage class, because it defaults
to the infered type.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
¿Qué será lo que hace que una brújula siempre marque el norte?
- Ser aguja, nada más, y cumplir su misión.
	-- Ricardo Vaporeso
Jan 15 2010
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/16/2010 01:46 AM, Leandro Lucarella wrote:

 Ali Çehreli, el 15 de enero a las 16:01 me escribiste:

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


 It is news to me that the following works without 'auto':

 struct S
 {
      int i;

      this(int i)
      {
          this.i = i;
      }
 }

 void main()
 {
      const c = S(42);   //<-- no 'auto' needed
 }

 Now I realize that 'auto' is for when we want type inference for
 mutable variables because this doesn't work:

      c = S(42);   //<-- compiler ERROR

 So we have to use a keyword:

      auto c = S(42);
      ++c.i;

 If I understand it correctly, 'auto' serves as the nonexistent
 'mutable' keyword in this case.

 I think to be consistent, I will continue using 'auto' even for when
 a storage class is specified:

      const auto c = S(42);  // works too

 For me, that gives 'auto' a single meaning: "the inferred type".

 Do I get it right? :)


 I don't think so. auto means in D the same that in C/C++, the difference
 is that D do type inference when a *storage class* is given. const,
 static, immutable, shared are other storage classs, so when you used
 them, you can infer the type too (if no type is given).

 You can do const auto c = 1; (I think), but I can't do static auto c = 1;
 (I think too). You can omit auto when declaring automatic variables if you
 specify the type (seen the other way :), because it defaults to auto. And
 you can omit the type if you use a storage class, because it defaults
 to the infered type.


Makes sense, but static auto totally works.

I think auto just means inferred type.
Jan 16 2010
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Pelle MÃ¥nsson wrote:

 On 01/16/2010 01:46 AM, Leandro Lucarella wrote:

 Ali Çehreli, el 15 de enero a las 16:01 me escribiste:

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


 It is news to me that the following works without 'auto':

 struct S
 {
      int i;

      this(int i)
      {
          this.i = i;
      }
 }

 void main()
 {
      const c = S(42);   //<-- no 'auto' needed
 }

 Now I realize that 'auto' is for when we want type inference for
 mutable variables because this doesn't work:

      c = S(42);   //<-- compiler ERROR

 So we have to use a keyword:

      auto c = S(42);
      ++c.i;

 If I understand it correctly, 'auto' serves as the nonexistent
 'mutable' keyword in this case.

 I think to be consistent, I will continue using 'auto' even for when
 a storage class is specified:

      const auto c = S(42);  // works too

 For me, that gives 'auto' a single meaning: "the inferred type".

 Do I get it right? :)


 I don't think so. auto means in D the same that in C/C++, the difference
 is that D do type inference when a *storage class* is given. const,
 static, immutable, shared are other storage classs, so when you used
 them, you can infer the type too (if no type is given).

 You can do const auto c = 1; (I think), but I can't do static auto c = 1;
 (I think too). You can omit auto when declaring automatic variables if 
 you
 specify the type (seen the other way :), because it defaults to auto. And
 you can omit the type if you use a storage class, because it defaults
 to the infered type.


 Makes sense, but static auto totally works.
 
 I think auto just means inferred type.


Why not read the specification?

http://www.digitalmars.com/d/2.0/attribute.html#auto

"The auto attribute is used when there are no other attributes and type 
inference is desired."

So basically type inference is always done except when you specify the type.
Jan 16 2010
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Ary Borenszweig wrote:


 Why not read the specification?

 http://www.digitalmars.com/d/2.0/attribute.html#auto

 "The auto attribute is used when there are no other attributes and type 
 inference is desired."

 So basically type inference is always done except when you specify the type.


That doesn't really explain what it is, just how to use it.

I was under the impression auto was the same as the one in C because I
thought I read it somewhere (along with, "you can specify either a
storage class or a type and the other will be infered, but one of them
must be specifided"). But since I can't find it I must have made it up
in a dream about D.
Jan 16 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Pelle MÃ¥nsson, el 16 de enero a las 14:00 me escribiste:

I don't think so. auto means in D the same that in C/C++, the difference
is that D do type inference when a *storage class* is given. const,
static, immutable, shared are other storage classs, so when you used
them, you can infer the type too (if no type is given).

You can do const auto c = 1; (I think), but I can't do static auto c = 1;
(I think too). You can omit auto when declaring automatic variables if you
specify the type (seen the other way :), because it defaults to auto. And
you can omit the type if you use a storage class, because it defaults
to the infered type.


 Makes sense, but static auto totally works.


You are right, that's odd... o.O

Even more, auto int x = 0 doesn't even compile:
variable x both auto and explicit type given


 I think auto just means inferred type.


That seems to be the case then... So Ali Çehreli was right and I was
wrong.

I still like my logic better, I will keep thinking that auto is a real
storage class and ignore this whole thread =P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Los jóvenes no son solo brazos que nos cargan... También se los puede
mandar a la guerra, que es su obligación.
	-- Ricardo Vaporeso
Jan 16 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Leandro Lucarella wrote:


 I think auto just means inferred type.


 
 That seems to be the case then... So Ali Çehreli was right and I was
 wrong.


Oh no... I had already adopted your thinking. :)


 I still like my logic better, I will keep thinking that auto is a real
 storage class and ignore this whole thread =P


The points that made my think my way are:

- auto is a whitespace word in C and C++; so there was no need for a 
language like D2, which does not have backward compatibility concerns, 
to keep it

- auto has a new meaning in C++0x: "infer the type from the 
initializer". As D2's and C++0x' developments overlapped in time; it was 
easy to assume that this feature was the same and was shared between 
these related languages

I was happy about my logic until this thread. :)

Ali
Jan 16 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
This discussion clearly shows that the current semantics of the "auto" is not
clean enough and it needs to be improved.
To improve it D needs to adopt the strategy of using all attributes in a more
tidy and semantically clean way, as Java does. Java doesn't compile "useless"
or wrong attributes as D sometimes does.

So it can be better to this to be a compilation error:
enum x = 10;
And accept only:
auto enum x = 10;
Or:
int enum x = 10;

Such tidy enforcement of attributes can be seen as fussy and sometimes it
requires extra compilations to remove all the mistakes, but it helps the
programmer understand in less time the semantics of those attributes. In
pedagogy it's well known that when a student is learning something, it's much
better if the rules are enforced in a strict way at the beginning.

And I'd like in D2 the "override" to be always necessary (even when the code is

such possible bugs.

Bye,
bearophile
Jan 17 2010
next sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
bearophile wrote:


 This discussion clearly shows that the current semantics of the "auto" is
 not clean enough and it needs to be improved. To improve it D needs to
 adopt the strategy of using all attributes in a more tidy and semantically
 clean way, as Java does. Java doesn't compile "useless" or wrong
 attributes as D sometimes does.
 
 So it can be better to this to be a compilation error:
 enum x = 10;
 And accept only:
 auto enum x = 10;
 Or:
 int enum x = 10;
 
 Such tidy enforcement of attributes can be seen as fussy and sometimes it
 requires extra compilations to remove all the mistakes, but it helps the
 programmer understand in less time the semantics of those attributes. In
 pedagogy it's well known that when a student is learning something, it's
 much better if the rules are enforced in a strict way at the beginning.
 
 And I'd like in D2 the "override" to be always necessary (even when the

 an example of such possible bugs.
 
 Bye,
 bearophile


Indeed. It was bad when C defaulted functions and variables to int if you 
didn't specify the return type or type respectively. C++ was smart to make 
that illegal. All it does is invite errors. Saving those few keystrokes 
isn't worth the added cost in clarity and potential bugs.

As for override, I second, third, and fourth that. I don't know why it 

guys and it's a lot more effective if it's required. Like not requiring a 
type (or auto), not requiring it (and not allowing it when it isn't 
applicable) invites confusion and errors. I'm all for requiring it.

- Jonathan M Davis
Jan 17 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
On 01/17/2010 11:53 AM, bearophile wrote:

 This discussion clearly shows that the current semantics of the "auto" is not
clean enough and it needs to be improved.
 To improve it D needs to adopt the strategy of using all attributes in a more
tidy and semantically clean way, as Java does. Java doesn't compile "useless"
or wrong attributes as D sometimes does.

 So it can be better to this to be a compilation error:
 enum x = 10;
 And accept only:
 auto enum x = 10;
 Or:
 int enum x = 10;

 Such tidy enforcement of attributes can be seen as fussy and sometimes it
requires extra compilations to remove all the mistakes, but it helps the
programmer understand in less time the semantics of those attributes. In
pedagogy it's well known that when a student is learning something, it's much
better if the rules are enforced in a strict way at the beginning.

 And I'd like in D2 the "override" to be always necessary (even when the code

of such possible bugs.

 Bye,
 bearophile


huh, you want to ditch type inference?

Java may be strict or even clean, but of all programmers I know, there 
are just one or two that do not hate that language with a passion and 
one of the reasons is this pedantic verbosity.
Jan 17 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lutger: 

 huh, you want to ditch type inference?


Nope. What are the parts of my post you have not understood?
Bye,
bearophile
Jan 17 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger:

 huh, you want to ditch type inference?


Sorry for my last answer.
I'd like to keep the type inference, but I'd like the const/immutable/etc
annotations to become orthogonal to the type, that can be given or inferred
with auto.
(And I'd like other attributes to be managed in a clean way, and override to be
compulsive.)

Bye,
bearophile
Jan 17 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
On 01/17/2010 04:35 PM, bearophile wrote:

 Lutger:

 huh, you want to ditch type inference?


 Sorry for my last answer.
 I'd like to keep the type inference, but I'd like the const/immutable/etc
annotations to become orthogonal to the type, that can be given or inferred
with auto.
 (And I'd like other attributes to be managed in a clean way, and override to
be compulsive.)

 Bye,
 bearophile


No problem, I misunderstood. You wanted to make auto compulsory for type 
inference, right?
Jan 17 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Lutger:

You wanted to make auto compulsory for type inference, right?<


Right, I think an orthogonal syntax can be better for people, especially people
that need to learn D. If it gets too much long to write, then a different

or the := of Go (3 or 4 chars less).

Bye,
bearophile
Jan 17 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Lutger:

 huh, you want to ditch type inference?


 
 Sorry for my last answer.
 I'd like to keep the type inference, but I'd like the const/immutable/etc
annotations to become orthogonal to the type, that can be given or inferred
with auto.
 (And I'd like other attributes to be managed in a clean way, and override to
be compulsive.)


Override will be compulsory.

Andrei
Jan 17 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Override will be compulsory.


A clean and positive answer, thank you :-)

A bear hug,
bearophile
Jan 17 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 This discussion clearly shows that the current semantics of the "auto" is not


clean enough and it needs to be improved.

 To improve it D needs to adopt the strategy of using all attributes in a more


tidy and semantically clean way, as Java does. Java doesn't compile "useless" or
wrong attributes as D sometimes does.

 So it can be better to this to be a compilation error:
 enum x = 10;
 And accept only:
 auto enum x = 10;
 Or:
 int enum x = 10;
 Such tidy enforcement of attributes can be seen as fussy and sometimes it


requires extra compilations to remove all the mistakes, but it helps the
programmer understand in less time the semantics of those attributes. In
pedagogy
it's well known that when a student is learning something, it's much better if
the
rules are enforced in a strict way at the beginning.

 And I'd like in D2 the "override" to be always necessary (even when the code is



such possible bugs.

 Bye,
 bearophile


What would this accomplish?  Everyone who's been using D for a while knows that,
if some other qualifier that proves to the compiler that you're declaring a
variable is in your declaration, the variable is `auto` unless you explicitly
declare it some other type.  It works perfectly, and immutable et al. have the
same semantics:

immutable x = 3.14;  // x is an immutable value of inferred type.
immutable real x = 3.14;  // x is explicitly a real.
const y = 1;  // y is a const value of inferred type.
const uint y = 1;  // y is a const uint.

Furthermore, I think that less verbosity encourages good practices.  I've gotten
into the habit of declaring all my stack variables immutable when writing a
function, unless I really need them to be mutable.  This makes code a lot easier
to understand because, when I look at the function later and try to figure out
how
it works, I know right off the bat that only a small subset of the variables are
ever modified after they're declared.  If doing this were more verbose, i.e. if
I
couldn't just write:

immutable y = 2 * x + 1;

I might be less inclined to do this.
Jan 17 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

 What would this accomplish?  Everyone who's been using D for a while knows
that,


It will help people that aren't using D for a lot of time yet, as I have said.



 If doing this were more verbose, i.e. if I couldn't just write:
 immutable y = 2 * x + 1;
 I might be less inclined to do this.


Is this too much long?
auto immutable y = 2 * x + 1;

If it's too much long, there are other ways to shorten it (require a syntax
change):
var immutable y = 2 * x + 1;
Or:
immutable y := 2 * x + 1;

Bye,
bearophile
Jan 17 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Sun, 17 Jan 2010 10:20:10 -0500, bearophile wrote:


 dsimcha:

 What would this accomplish?  Everyone who's been using D for a while
 knows that,


 
 It will help people that aren't using D for a lot of time yet, as I have
 said.
 
 

 If doing this were more verbose, i.e. if I couldn't just write:
 immutable y = 2 * x + 1;
 I might be less inclined to do this.


 
 Is this too much long?
 auto immutable y = 2 * x + 1;
 
 If it's too much long, there are other ways to shorten it (require a
 syntax change): var immutable y = 2 * x + 1;
 Or:
 immutable y := 2 * x + 1;


Nobody has complained the approach Scala has taken:

val a = 1           // immutable value
var b = List(1,2,3) // mutable ref to immutable list

OTOH the ascription in Scala uses a dedicated uniform syntax unlike type 
definitions in C-like languages.
Jan 17 2010
parent KennyTM~ <kennytm gmail.com> writes:
On Jan 17, 10 23:38, retard wrote:

 Sun, 17 Jan 2010 10:20:10 -0500, bearophile wrote:


 dsimcha:

 What would this accomplish?  Everyone who's been using D for a while
 knows that,


 It will help people that aren't using D for a lot of time yet, as I have
 said.



 If doing this were more verbose, i.e. if I couldn't just write:
 immutable y = 2 * x + 1;
 I might be less inclined to do this.


 Is this too much long?
 auto immutable y = 2 * x + 1;

 If it's too much long, there are other ways to shorten it (require a
 syntax change): var immutable y = 2 * x + 1;
 Or:
 immutable y := 2 * x + 1;


 Nobody has complained the approach Scala has taken:

 val a = 1           // immutable value
 var b = List(1,2,3) // mutable ref to immutable list

 OTOH the ascription in Scala uses a dedicated uniform syntax unlike type
 definitions in C-like languages.


On the first glance I don't even know why the 2 statements are 
different! Not a good sign [to me] :)
Jan 17 2010
prev sibling parent =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/17/2010 04:20 PM, bearophile wrote:

 dsimcha:

 What would this accomplish?  Everyone who's been using D for a while knows
that,


 It will help people that aren't using D for a lot of time yet, as I have said.



 If doing this were more verbose, i.e. if I couldn't just write:
 immutable y = 2 * x + 1;
 I might be less inclined to do this.


 Is this too much long?
 auto immutable y = 2 * x + 1;

 If it's too much long, there are other ways to shorten it (require a syntax
change):
 var immutable y = 2 * x + 1;
 Or:
 immutable y := 2 * x + 1;

 Bye,
 bearophile


Do you find that the extra : adds a lot of otherwise missing clarity?

I think the way it is now is great. Maybe if the := syntax added 
automatic immutability too, it would be useful.
Jan 17 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

It works perfectly,<


This thread is a proof that it doesn't work well inside the head of some
programmers.

Bye,
bearophile
Jan 17 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Furthermore, I think that less verbosity encourages good practices.  I've
gotten
 into the habit of declaring all my stack variables immutable when writing a
 function, unless I really need them to be mutable.  This makes code a lot
easier
 to understand because, when I look at the function later and try to figure out
how
 it works, I know right off the bat that only a small subset of the variables
are
 ever modified after they're declared.



Andrei introduced me to that style, and I'm starting to use it more and 
more. I like it for the reasons you state.
Jan 17 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Andrei introduced me to that style, and I'm starting to use it more and 
 more. I like it for the reasons you state.


I'm not using it because I'm not using D2 much yet, but I have read that a good
number of people are adopting that style in other languages as Scala, so it can
be a good way to program (I can appreciate it myself). If this is true then a
syntax like:
auto immutable x = y * 2;

can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-) For example into "val"
(also as "retard" has said), so it becomes shorter (here "auto" is present if
and only if the programmer wants type inference, as I have written in other
posts, to clean up its semantics):
auto val x = y * 2;

Bye and thank you,
bearophile
Jan 17 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 17 de enero a las 14:45 me escribiste:

 dsimcha wrote:

Furthermore, I think that less verbosity encourages good practices.  I've gotten
into the habit of declaring all my stack variables immutable when writing a
function, unless I really need them to be mutable.  This makes code a lot easier
to understand because, when I look at the function later and try to figure out
how
it works, I know right off the bat that only a small subset of the variables are
ever modified after they're declared.


 
 Andrei introduced me to that style, and I'm starting to use it more
 and more. I like it for the reasons you state.


Do you remember when people asked for default immutability? I do :)

To be fair, all I can find in the archives are about default immutability
of function parameters, not local variables, but I'm under the impression
that there was some discussion about making local variables immutable by
default...

I like the idea of making x := y an alias for immutable x = y (or even
enum x = y). That would make this style much more attractive without
breaking backward compatibility as immutable-by-default would do.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, dont help them to bury the light
Don't give in without a fight.
Jan 18 2010
next sibling parent Jason House <jason.james.house gmail.com> writes:
Leandro Lucarella Wrote:


 Walter Bright, el 17 de enero a las 14:45 me escribiste:

 dsimcha wrote:

Furthermore, I think that less verbosity encourages good practices.  I've gotten
into the habit of declaring all my stack variables immutable when writing a
function, unless I really need them to be mutable.  This makes code a lot easier
to understand because, when I look at the function later and try to figure out
how
it works, I know right off the bat that only a small subset of the variables are
ever modified after they're declared.


 
 Andrei introduced me to that style, and I'm starting to use it more
 and more. I like it for the reasons you state.


 
 Do you remember when people asked for default immutability? I do :)
 
 To be fair, all I can find in the archives are about default immutability
 of function parameters, not local variables, but I'm under the impression
 that there was some discussion about making local variables immutable by
 default...
 
 I like the idea of making x := y an alias for immutable x = y (or even
 enum x = y). That would make this style much more attractive without
 breaking backward compatibility as immutable-by-default would do.


enum is a manifest constant. My vote would be to use pure:

pure x = y;
Jan 18 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Do you remember when people asked for default immutability? I do :)


Yes, but it would break every other line of code already written in D.



 I like the idea of making x := y an alias for immutable x = y (or even
 enum x = y). That would make this style much more attractive without
 breaking backward compatibility as immutable-by-default would do.



Actually,

     const x = y;

is better than immutable, because if y is a T*, it cannot be implicitly 
converted to immutable, while it can be implicitly converted to const.
Jan 18 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Leandro Lucarella wrote:

 Do you remember when people asked for default immutability? I do :)


 Yes, but it would break every other line of code already written in D.

 I like the idea of making x := y an alias for immutable x = y (or even
 enum x = y). That would make this style much more attractive without
 breaking backward compatibility as immutable-by-default would do.


 Actually,
      const x = y;
 is better than immutable, because if y is a T*, it cannot be implicitly
 converted to immutable, while it can be implicitly converted to const.


Refresh my memory, is there any difference whatsoever between const and
immutable
for pure value types (int, float, char, etc.), including in terms of the
compiler
optimizations they allow?  As far as I can tell, the difference only comes into
existence when there's indirection involved.
Jan 18 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 18 Jan 2010 15:35:17 -0500, dsimcha <dsimcha yahoo.com> wrote:


 == Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Leandro Lucarella wrote:

 Do you remember when people asked for default immutability? I do :)


 Yes, but it would break every other line of code already written in D.

 I like the idea of making x := y an alias for immutable x = y (or even
 enum x = y). That would make this style much more attractive without
 breaking backward compatibility as immutable-by-default would do.


 Actually,
      const x = y;
 is better than immutable, because if y is a T*, it cannot be implicitly
 converted to immutable, while it can be implicitly converted to const.


 Refresh my memory, is there any difference whatsoever between const and  
 immutable
 for pure value types (int, float, char, etc.), including in terms of the  
 compiler
 optimizations they allow?  As far as I can tell, the difference only  
 comes into
 existence when there's indirection involved.


For pure value types (including structs with only pure value types in  
them), no there is no difference.  That is why such value types are  
implicitly convertable to/from mutable, const and immutable because you  
always make a complete copy on assignment.

-Steve
Jan 18 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Yes, but it would break every other line of code already written in D.<


Is this a lot of D2 code? How much time does it need?

Bye,
bearophile
Jan 18 2010
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 18 de enero a las 17:07 me escribiste:

 Walter Bright:

 Yes, but it would break every other line of code already written in D.<


 
 Is this a lot of D2 code? How much time does it need?


I think he includes D1 code, which would be harder to port to D2. Makes
sense to me, that's why I think introducing the := operator as an alias to
immutable/const would be a good compromise. It makes extremely easy to use
immutable/const variables while keeping backward compatibility.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
DIEZ "PUNGAS" MENOS
	-- Crónica TV
Jan 19 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Jan 19, 2010 at 11:52:16AM -0300, Leandro Lucarella wrote:

 I think he includes D1 code, which would be harder to port to D2. Makes
 sense to me, that's why I think introducing the := operator as an alias to
 immutable/const would be a good compromise. It makes extremely easy to use
 immutable/const variables while keeping backward compatibility.



Would this be a realistic fear with it?

receiver := 1;

reciever := 2; // meant to rebind, but spelling error goes unnoticed by compiler


If so, bah. Of course, I like it how it is now anyway.


 
 -- 
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
 ----------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------
 DIEZ "PUNGAS" MENOS
 	-- Crónica TV


-- 
Adam D. Ruppe
http://arsdnet.net
Jan 19 2010
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Adam D. Ruppe, el 19 de enero a las 10:56 me escribiste:

 On Tue, Jan 19, 2010 at 11:52:16AM -0300, Leandro Lucarella wrote:

 I think he includes D1 code, which would be harder to port to D2. Makes
 sense to me, that's why I think introducing the := operator as an alias to
 immutable/const would be a good compromise. It makes extremely easy to use
 immutable/const variables while keeping backward compatibility.


 
 
 Would this be a realistic fear with it?
 
 receiver := 1;
 
 reciever := 2; // meant to rebind, but spelling error goes unnoticed by
compiler
 
 
 If so, bah. Of course, I like it how it is now anyway.


I don't understand, you are vulnerable to that kind of bugs now too:

const receiver = 1;

const reciever = 2; // meant to rebind, but spelling error goes unnoticed by
compiler

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
aFR [afr my.farts.cause.nuclear.reaction.org] has quit IRC (Ping timeout)
Jan 19 2010
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Jan 19, 2010 at 02:44:29PM -0300, Leandro Lucarella wrote:

 I don't understand, you are vulnerable to that kind of bugs now too:
 
 const receiver = 1;
 
 const reciever = 2; // meant to rebind, but spelling error goes unnoticed by
compiler


Right, but it is more of a conscious effort to type const X = x; than it
is to type X := x;.

If you wanted to do immutable by default, wouldn't that means you get
yourself in the habit of typing := instead of =? That's not the same as
training yourself to type const (or immutable) where you would have typed
auto before.

Maybe I don't understand the proposal :S

-- 
Adam D. Ruppe
http://arsdnet.net
Jan 19 2010
parent Leandro Lucarella <llucax gmail.com> writes:
Adam D. Ruppe, el 19 de enero a las 14:12 me escribiste:

 On Tue, Jan 19, 2010 at 02:44:29PM -0300, Leandro Lucarella wrote:

 I don't understand, you are vulnerable to that kind of bugs now too:
 
 const receiver = 1;
 
 const reciever = 2; // meant to rebind, but spelling error goes unnoticed by
compiler


 
 Right, but it is more of a conscious effort to type const X = x; than it
 is to type X := x;.
 
 If you wanted to do immutable by default, wouldn't that means you get
 yourself in the habit of typing := instead of =? That's not the same as
 training yourself to type const (or immutable) where you would have typed
 auto before.


But := is a declaration, = is an expression! You will use := all over the
places for *declaring* stuff, not for assigning stuff.


 Maybe I don't understand the proposal :S


I think you understand the proposal, we just don't agree on how
error-prone it would be ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hey you, standing in the road
always doing what you're told,
Can you help me?
Jan 19 2010
prev sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
On 01/19/2010 04:56 PM, Adam D. Ruppe wrote:

 On Tue, Jan 19, 2010 at 11:52:16AM -0300, Leandro Lucarella wrote:

 I think he includes D1 code, which would be harder to port to D2. Makes
 sense to me, that's why I think introducing the := operator as an alias to
 immutable/const would be a good compromise. It makes extremely easy to use
 immutable/const variables while keeping backward compatibility.



 Would this be a realistic fear with it?

 receiver := 1;

 reciever := 2; // meant to rebind, but spelling error goes unnoticed by
compiler


 If so, bah. Of course, I like it how it is now anyway.


Python, and most other dynamic languages, have that problem. They are 
not suffering because of it.

Also, const cannot be rebound.
Jan 19 2010
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Jan 19, 2010 at 10:51:11PM +0100, Pelle Månsson wrote:

 Python, and most other dynamic languages, have that problem. They are 
 not suffering because of it.


Meh, that's in the eye of the beholder.


 Also, const cannot be rebound.


Ah, so it can't. I figured they could, since strings can be, but I see you're
right. I guess that makes this moot.


-- 
Adam D. Ruppe
http://arsdnet.net
Jan 19 2010
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
bearophile Wrote:


 Walter Bright:

 Andrei introduced me to that style, and I'm starting to use it more and 
 more. I like it for the reasons you state.


 
 I'm not using it because I'm not using D2 much yet, but I have read that a
good number of people are adopting that style in other languages as Scala, so
it can be a good way to program (I can appreciate it myself). If this is true
then a syntax like:
 auto immutable x = y * 2;
 
 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-)


Fortunately, the "auto" keyword can be left out.  "auto" is actually a storage
class, it doesn't directly mean "infer the type."
Jan 18 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:

 Fortunately, the "auto" keyword can be left out.<


The point of my post was that I think that's bad. And I have tried to explain
why.
Bye,
bearophile
Jan 18 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Sean Kelly, el 18 de enero a las 16:10 me escribiste:

 bearophile Wrote:
 

 Walter Bright:

 Andrei introduced me to that style, and I'm starting to use it more and 
 more. I like it for the reasons you state.


 
 I'm not using it because I'm not using D2 much yet, but I have read that a
good number of people are adopting that style in other languages as Scala, so
it can be a good way to program (I can appreciate it myself). If this is true
then a syntax like:
 auto immutable x = y * 2;
 
 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-)


 
 Fortunately, the "auto" keyword can be left out.  "auto" is actually
 a storage class, it doesn't directly mean "infer the type."


I was under that impression too, but that's not what my test show. You can
write auto int x = 5;, it fails to compile with an error saying that
x have both explicit type and auto. I find this very odd, I think auto
should be a regular storage class.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I've always been mad, I know I've been mad, like the most of us...
very hard to explain why you're mad, even if you're not mad...
Jan 19 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Leandro Lucarella wrote:


 Sean Kelly, el 18 de enero a las 16:10 me escribiste:

 bearophile Wrote:
 

 Walter Bright:

 Andrei introduced me to that style, and I'm starting to use it more and 
 more. I like it for the reasons you state.


 
 I'm not using it because I'm not using D2 much yet, but I have read that a
good number of people are adopting that style in other languages as Scala, so
it can be a good way to program (I can appreciate it myself). If this is true
then a syntax like:
 auto immutable x = y * 2;
 
 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-)


 
 Fortunately, the "auto" keyword can be left out.  "auto" is actually
 a storage class, it doesn't directly mean "infer the type."


 I was under that impression too, but that's not what my test show. You can
 write auto int x = 5;, it fails to compile with an error saying that
 x have both explicit type and auto. I find this very odd, I think auto
 should be a regular storage class.


auto int foo = 5; 

Works fine for me, dmd 2.037
Jan 19 2010
parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el 19 de enero a las 15:21 me escribiste:

 Leandro Lucarella wrote:
 

 Sean Kelly, el 18 de enero a las 16:10 me escribiste:

 bearophile Wrote:
 

 Walter Bright:

 Andrei introduced me to that style, and I'm starting to use it more and 
 more. I like it for the reasons you state.


 
 I'm not using it because I'm not using D2 much yet, but I have read that a
good number of people are adopting that style in other languages as Scala, so
it can be a good way to program (I can appreciate it myself). If this is true
then a syntax like:
 auto immutable x = y * 2;
 
 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-)


 
 Fortunately, the "auto" keyword can be left out.  "auto" is actually
 a storage class, it doesn't directly mean "infer the type."


 I was under that impression too, but that's not what my test show. You can
 write auto int x = 5;, it fails to compile with an error saying that
 x have both explicit type and auto. I find this very odd, I think auto
 should be a regular storage class.


 
 auto int foo = 5; 
 
 Works fine for me, dmd 2.037


I only have LDC (based on DMD 1.051) and GDC (based on DMD 1.024) here,
LDC fails with this message:
/tmp/x.d(4): Error: variable x.main.x both auto and explicit type given
And GDC works, so I think it might be a regression. I should test with the
latest DMD...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
	-- Sidharta Kiwi
Jan 19 2010
prev sibling next sibling parent reply Jerry Quinn <jlquinn optonline.net> writes:
bearophile Wrote:


 myself). If this is true then a syntax like:
 auto immutable x = y * 2;
 
 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-) For example into "val"
(also as "retard" has said), so it becomes shorter (here "auto" is present if
and only if the programmer wants type inference, as I have written in other
posts, to clean up its semantics):
 auto val x = y * 2;


How about "fixed"?  It's a little longer than val, but still carries "set in
stone" semantics.

auto fixed x = y * 2;
Jan 18 2010
parent Travis Boucher <boucher.travis gmail.com> writes:
Jerry Quinn wrote:

 bearophile Wrote:
 

 myself). If this is true then a syntax like:
 auto immutable x = y * 2;

 can be seen as too much long and boring to write all the time, so the
"immutable" keyword may need to be changed again :-) For example into "val"
(also as "retard" has said), so it becomes shorter (here "auto" is present if
and only if the programmer wants type inference, as I have written in other
posts, to clean up its semantics):
 auto val x = y * 2;


 
 How about "fixed"?  It's a little longer than val, but still carries "set in
stone" semantics.
 
 auto fixed x = y * 2;
 


It'd be nice to not introduce 'fixed' unless it referred to fixed point 
math.  (not using it at all leaves the openings for vendor extensions 
targeting embedded platforms)
Jan 19 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
bearophile wrote:


 This discussion clearly shows that the current semantics of the "auto" is not
clean enough and it needs to be improved.
 To improve it D needs to adopt the strategy of using all attributes in a more
tidy and semantically clean way, as Java does. Java doesn't compile "useless"
or wrong attributes as D sometimes does.

 So it can be better to this to be a compilation error:
 enum x = 10;
 And accept only:
 auto enum x = 10;
 Or:
 int enum x = 10;

 Such tidy enforcement of attributes can be seen as fussy and sometimes it
requires extra compilations to remove all the mistakes, but it helps the
programmer understand in less time the semantics of those attributes. In
pedagogy it's well known that when a student is learning something, it's much
better if the rules are enforced in a strict way at the beginning.

 And I'd like in D2 the "override" to be always necessary (even when the code

of such possible bugs.

 Bye,
 bearophile


I don't like it. And I don't think the suggested alternatives make the


duck-typing). And Go's := hides even more information than the
current situation.

The issue this thread is showing is that what 'auto' means is not well
defined in the documentation. Storage classes already have intricate
rules on who can be used where and with whome. And having 'auto ref'
won't help.
Jan 18 2010
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Leandro Lucarella wrote:

 Exactly, it seems to me that the generalization in this case is
 counterproductive. What's the point on disabling a function, except for
 those automatically generated by the compiler.


Unwanted inherited functions.  Unwanted functions generated by a
template mixin.  (But I'm not certain if  disable will work for either
of these cases, so...)


-- 
Rainer Deyke - rainerd eldwood.com
Jan 14 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 14 Jan 2010 21:28:42 +0300, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:


 Pelle M=C3=A5nsson wrote:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?
 http://www.dsource.org/projects/dmd/changeset/336

 Thanks.


 #define STCdisable       0x2000000000LL // for functions that are not=




  =


 callable


 The main idea is to allow creation of noncopyable types by marking  =



 this(this) as  disable.

 Noncopyable types are pivotal for a number of idioms important in  =



 concurrency and elsewhere.


 Andrei


Why not just make it final abstract instead? For example, the following =
 =

works now:

// class can not be instantiated, serves just like a namespace
abstract final class Namespace
{
     static void foo() { ... }
}
Jan 14 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Thu, 14 Jan 2010 21:28:42 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Pelle MÃ¥nsson wrote:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?
 http://www.dsource.org/projects/dmd/changeset/336

 Thanks.


 #define STCdisable       0x2000000000LL // for functions that are not 
 callable


 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.

 Noncopyable types are pivotal for a number of idioms important in 
 concurrency and elsewhere.


 Andrei


 
 Why not just make it final abstract instead? For example, the following 
 works now:
 
 // class can not be instantiated, serves just like a namespace
 abstract final class Namespace
 {
     static void foo() { ... }
 }


It's about a struct, and it can be instantiated so it's not abstract 
even in principle.

Andrei
Jan 14 2010
prev sibling next sibling parent reply Clemens <eriatarka84 gmail.com> writes:
Andrei Alexandrescu Wrote:


 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.


I must be missing something, but isn't this usually done by making the copy
constructor private?
Jan 15 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Clemens wrote:

 Andrei Alexandrescu Wrote:
 

 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.


 
 I must be missing something, but isn't this usually done by making the copy
constructor private?


Well one issue is that in D private has module granularity, which means 
that inside a given module you could still create objects. That has the 
advantage of obviating the need for "friend", but disables the private 
constructor idiom.

Andrei
Jan 15 2010
parent reply Clemens <eriatarka84 gmail.com> writes:
Andrei Alexandrescu Wrote:


 Clemens wrote:

 Andrei Alexandrescu Wrote:
 

 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.


 
 I must be missing something, but isn't this usually done by making the copy
constructor private?


 
 Well one issue is that in D private has module granularity, which means 
 that inside a given module you could still create objects. That has the 
 advantage of obviating the need for "friend", but disables the private 
 constructor idiom.
 
 Andrei


I thought about that, but it seemed to me that the D philosophy is that modules
can be trusted to "do the right thing" internally. Then again, I can see how,
due to its implicit nature, invoking a copy constructor "accidentally" may be
easier than invoking a private method, leading to subtle bugs.
Jan 15 2010
parent reply Leandro Lucarella <llucax gmail.com> writes:
Clemens, el 15 de enero a las 04:40 me escribiste:

 Andrei Alexandrescu Wrote:
 

 Clemens wrote:

 Andrei Alexandrescu Wrote:
 

 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.


 
 I must be missing something, but isn't this usually done by making the copy
constructor private?


 
 Well one issue is that in D private has module granularity, which means 
 that inside a given module you could still create objects. That has the 
 advantage of obviating the need for "friend", but disables the private 
 constructor idiom.
 
 Andrei


 
 I thought about that, but it seemed to me that the D philosophy is that
 modules can be trusted to "do the right thing" internally. Then again,
 I can see how, due to its implicit nature, invoking a copy constructor
 "accidentally" may be easier than invoking a private method, leading to
 subtle bugs.


Exactly, that seems like a contradiction: we are confident that the module
author know what he is doing giving him rights to access private data, but
we are not so sure about certain functions...

I know it could be useful to have more granularity, but maybe we need
a new visibility attribute, like "module" (making "private" really
private, and "module" what "private" actually does). Changing "private"
meaning is probably a bad idea though, maybe private can be left as is and
add a "delete" visibility attribute (which would have the same effect than
 disable, but is more close to the current way to do things).

class X {

	private this();

	delete this(X);

}

It would be even more familiar to people coming from C++0x (C++1x! =P)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
MP: Cómo está, estimado Bellini?   B: Muy bien, Mario, astrologando.
MP: Qué tengo?                     B: Un balcón-terraza.
MP: No, en mi mano, Bellini...     B: Un secarropas!
MP: No, escuche bien, eh. Tiene    B: El circo de Moscú.
    números.
MP: No Bellini. Toma medidas.      B: Un ministro.
MP: No Bellini, eh! Algunas son    B: Una modelo, Mario!
    de plástico y otras de madera.
MP: No, Bellini, no y no!
	-- El Gran Bellini (Mario Podestá con una regla)
Jan 15 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Leandro Lucarella wrote:


 It would be even more familiar to people coming from C++0x (C++1x! =P)


You may have missed that 0x is the hexadecimal prefix there. How about 
C++0xb to be specific. :)

Ali
Jan 15 2010
parent Leandro Lucarella <llucax gmail.com> writes:
Ali Çehreli, el 15 de enero a las 11:35 me escribiste:

 Leandro Lucarella wrote:
 

 It would be even more familiar to people coming from C++0x (C++1x! =P)


 
 You may have missed that 0x is the hexadecimal prefix there. How
 about C++0xb to be specific. :)


I would be even surprised if they achieve C++0xf!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
En ese preciso instante ella con un leve gemido nos dice: "Ponla, Tito!
Ponla!".
	-- Sidharta Kiwi
Jan 15 2010
prev sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
Andrei Alexandrescu wrote:

 The main idea is to allow creation of noncopyable types by marking 
 this(this) as  disable.
 
 Noncopyable types are pivotal for a number of idioms important in 
 concurrency and elsewhere.
 
 
 Andrei


IMHO, we could extend existing syntax instead of invent new one.
I really love the Scale style:

Excerpt from Scala reference. Page 59.
package outerpkg.innerpkg
class Outer
{
     class Inner
     {
         private[Outer] def f()
         private[innerpkg] def g()
         private[outerpkg] def h()
     }
}

http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf
Jan 15 2010
parent reply KennyTM~ <kennytm gmail.com> writes:
On Jan 16, 10 01:01, The Anh Tran wrote:

 Andrei Alexandrescu wrote:

 The main idea is to allow creation of noncopyable types by marking
 this(this) as  disable.

 Noncopyable types are pivotal for a number of idioms important in
 concurrency and elsewhere.


 Andrei


 IMHO, we could extend existing syntax instead of invent new one.
 I really love the Scale style:

 Excerpt from Scala reference. Page 59.
 package outerpkg.innerpkg
 class Outer
 {
 class Inner
 {
 private[Outer] def f()
 private[innerpkg] def g()
 private[outerpkg] def h()
 }
 }

 http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf


The  attribute syntax is designed to be used like this. (Although 
currently they're all keywords in the future you may be able to have 
 identifier_of_custom_attribute).
Jan 15 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 On Jan 16, 10 01:01, The Anh Tran wrote:

 Andrei Alexandrescu wrote:

 The main idea is to allow creation of noncopyable types by marking
 this(this) as  disable.

 Noncopyable types are pivotal for a number of idioms important in
 concurrency and elsewhere.


 Andrei


 IMHO, we could extend existing syntax instead of invent new one.
 I really love the Scale style:

 Excerpt from Scala reference. Page 59.
 package outerpkg.innerpkg
 class Outer
 {
 class Inner
 {
 private[Outer] def f()
 private[innerpkg] def g()
 private[outerpkg] def h()
 }
 }

 http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/file
/ScalaReference.pdf 


 
 The  attribute syntax is designed to be used like this. (Although 
 currently they're all keywords in the future you may be able to have 
  identifier_of_custom_attribute).


I'd also like to see other keywords (nothrow, pure, override come to 
mind) transferred into the attribute space.

Andrei
Jan 15 2010
parent reply Michal Minich <michal.minich gmail.com> writes:
On Sat, 16 Jan 2010 00:58:36 -0600, Andrei Alexandrescu wrote:


 I'd also like to see other keywords (nothrow, pure, override come to
 mind) transferred into the attribute space.


I'd welcome if that happens. My personal favorite is "align", it is 
common, hard to replace word when one works with text/graphics/forms/
layout stuff, and as D keyword, it is rarely used.

Some other candidates are at http://www.digitalmars.com/d/2.0/
attribute.html, maybe except "auto", it feels more like command to me 
than attribute.

What about immutable/const - are they  attributes?. Also function 
parameter attributes = in/inout/ref - will it be possible to apply 
attribute to fn parameters?

(It seems that what should be  attribute and what not is for big 
discussion.)
Jan 16 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michal Minich wrote:

 On Sat, 16 Jan 2010 00:58:36 -0600, Andrei Alexandrescu wrote:
 

 I'd also like to see other keywords (nothrow, pure, override come to
 mind) transferred into the attribute space.


 
 I'd welcome if that happens. My personal favorite is "align", it is 
 common, hard to replace word when one works with text/graphics/forms/
 layout stuff, and as D keyword, it is rarely used.
 
 Some other candidates are at http://www.digitalmars.com/d/2.0/
 attribute.html, maybe except "auto", it feels more like command to me 
 than attribute.
 
 What about immutable/const - are they  attributes?. Also function 
 parameter attributes = in/inout/ref - will it be possible to apply 
 attribute to fn parameters?


immutable and const are qualifiers. That doesn't necessarily preclude 
their usage with  , but it does make different from e.g.  pure.


 (It seems that what should be  attribute and what not is for big 
 discussion.)


I agree.


Andrei
Jan 16 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Michal Minich wrote:


 On Sat, 16 Jan 2010 00:58:36 -0600, Andrei Alexandrescu wrote:


 I'd also like to see other keywords (nothrow, pure, override come to
 mind) transferred into the attribute space.


 I'd welcome if that happens. My personal favorite is "align", it is 
 common, hard to replace word when one works with text/graphics/forms/
 layout stuff, and as D keyword, it is rarely used.

 Some other candidates are at http://www.digitalmars.com/d/2.0/
 attribute.html, maybe except "auto", it feels more like command to me 
 than attribute.

 What about immutable/const - are they  attributes?. Also function 
 parameter attributes = in/inout/ref - will it be possible to apply 
 attribute to fn parameters?

 (It seems that what should be  attribute and what not is for big 
 discussion.)


Don't forget that some suggestions are found in the DIP:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Personally I don't think it would be good for things like in, out,
ref... i.e. what you would find in a function parameter-list:

 pure int add( in int a,  in int b) {
         return a + b;
}

:P
Jan 16 2010
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Pelle MÃ¥nsson, el 14 de enero a las 19:30 me escribiste:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

What is  disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336

Thanks.


 #define STCdisable       0x2000000000LL // for functions that are
 not callable


Yes, I can read, but I wondered what's the point on making a function
non-callable. It's absolutely contradictory! :)

Now I see it's intended only for compiler generated methods, and I think
it's a seriously flawled feature.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Tired of lying in the sunshine staying home to watch the rain.
You are young and life is long and there is time to kill today.
And then one day you find ten years have got behind you.
No one told you when to run, you missed the starting gun.
Jan 14 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:

 Pelle MÃ¥nsson, el 14 de enero a las 19:30 me escribiste:

 On 01/14/2010 03:55 PM, Leandro Lucarella wrote:

 What is  disable supposed to be for?
 http://www.dsource.org/projects/dmd/changeset/336

 Thanks.


 #define STCdisable       0x2000000000LL // for functions that are
 not callable


 
 Yes, I can read, but I wondered what's the point on making a function
 non-callable. It's absolutely contradictory! :)
 
 Now I see it's intended only for compiler generated methods, and I think
 it's a seriously flawled feature.


Why?

Andrei
Jan 14 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 15/01/10 00:36, Leandro Lucarella wrote:

 Yes, I can read, but I wondered what's the point on making a function
 non-callable. It's absolutely contradictory! :)


Other than the no-copy idiom for structs, I'd find it useful in the 
following situation:

----
 disable void foo1() { }
int foo2( int a ) { return 1; }

void main()
{
     foo1();
}
----

When refactoring code I often find myself commenting out functions to 
check if I've got all the functions switched over, doing this saves that 
effort :) Of course I could mark them with deprecated and compile with 
-d, that means messing with my build script, something I'd rather avoid.


 Now I see it's intended only for compiler generated methods, and I think
 it's a seriously flawled feature.
Jan 16 2010