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
next sibling 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.

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.

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?


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
next sibling 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 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.

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
parent 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
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
john foo wrote:
 Walter Bright Wrote:
 


 Lawrence mentions several uses for it.

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

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
next sibling 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
next sibling 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 

 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 =?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.

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.

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 next sibling 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
not compiled with "-w") as in C#, to avoid other bugs. I can show an example of
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
 code is not compiled with "-w") as in C#, to avoid other bugs. I can show
 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 wasn't that way in the first place. Override was a very addition by the C# 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
is not compiled with "-w") as in C#, to avoid other bugs. I can show an example
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 syntax for type inference can be adopted, like the "var" of C# (1 char less), 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

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

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

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 =?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 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 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 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 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 :)

 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.

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
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 =?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
prev sibling next 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
is not compiled with "-w") as in C#, to avoid other bugs. I can show an example
of such possible bugs.

 Bye,
 bearophile

I don't like it. And I don't think the suggested alternatives make the situation any better. Using 'var' from C# has the benefit of making D look like C#, but I don't see it as less verbose (it also says to me 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 next sibling parent "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
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tue, Jan 19, 2010 at 10:51:11PM +0100, Pelle Mnsson 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 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 "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
 	-- Crnica TV

-- Adam D. Ruppe http://arsdnet.net
Jan 19 2010
prev sibling 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 :)

 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.

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 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
prev sibling next 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 parent 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
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.


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 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
prev sibling next sibling 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.

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 =?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
prev sibling next 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
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:
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 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
prev sibling 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.

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
prev sibling next sibling parent "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.



 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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.

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
prev sibling next 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 next sibling 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 next sibling parent 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
prev sibling next sibling 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 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