eao197 wrote:
> On Fri, 16 Mar 2007 12:43:19 +0300, Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Yes, that's part of the plan. Moreover, you'll likely have the ability to define const-transporting methods (methods that look identical but only need to pass the const of the object out to the return value) only once. This has been a source of annoyance in certain C++ idioms.
> 
> Thanks, I'm glad to hear that!
> 
> It seems that D with this storage classes and const-transporting methods will be almost different D, may be D 2.0 :)

Actually, this is exactly true. D 2.0.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Don Clugston wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Bruno Medeiros wrote:
>>>> What is the status of the experimental designs for the "storage classes" manipulation that Andrei and others where thinking of for D. The last I heard from it was Andrei's max suggestion from his max design challenge, however, I think that suggestion may suffer from some problems in regards to the "maxtype" requirement, plus it is wholly incomplete in regards to how storage classes interact between each other. Like Andrei said, what is a "const inout lazy const char[]", if valid at all? Is there any news here? Is there a working(aka complete) design?
>>>
>>> We have talked about a design. In short, the intent is to define three flavors of immutability:
>>>
>>> a) final - a simple storage class controlling the immutability of the bits allocated for the symbol per se;
>>>
>>> b) const - type qualifier meaning an immutable view of an otherwise modifiable data. const does not control the bits of the object, only the storage addressed indirectly by it (transitively);
>>>
>>> c) "superconst" - denoted as "const!" or "super const": type qualifier meaning that the data is genuinely unmodifiable.
>>
>> Does this last category include some of the current use of D const -- a value which is not modifiable, *even in theory*, and may not even have any run-time existence at all -- the C equivalent being a #defined constant.
> 
> Yes.
> 
>> IMHO (b) should be 'readonly' and (c) should be 'const'.
>> But this may be because I'm a physicist, and for me a constant is something like the speed of light, and C++'s const_cast always seemed utterly nonsensical.
>>
>> void alabama() {  // Actually compiles! Someone should be shot for this.
>>    const double PI = 3.14159265358;
>>    *const_cast<double *>(&PI) = 4.0;
>> }
>>
>> Whereas 'readonly' seems to be a much better match for (b). Although it's an extra keyword, it seems to me that the concept discussed here is sufficiently fundamental to justify an extra keyword. Especially if we have a chance to rid of 'lazy'.
> 
> If we get rid of lazy, I'll sacrifice a lamb :o).
> 
> We've shoved keywords like "readonly" and "view" for a while, and they just added more confusion than cleared, at a high cost. If (as I suspect) super const appears relatively infrequently, it might be fine to just encode it as the mildly verbose "super const". In fact, it's shorter than "keepyourgrubbyhandsoff". :o)
> 
> Andrei

My problem is, I don't see any connection between "don't touch" and "constant" except that C++ got them confused. In every other other context outside of C++,  "constant" means "it will not change".

Mathematically, you can "hold something constant" (even though it is actually a variable), but as long as it is being held constant, it can't change.

Suppose in a function, you have 'const' access to a global variable.
Another thread with write-access to that variable can change it, while the function is executing.

It makes sense for a function to have read-only access to a variable, and need to obtain a mutex when it wants to obtain the current value.
But that's not a constant in any reasonable sense of the word.

Don.

eao197 wrote:

> It seems that D with this storage classes and const-transporting methods  will be almost different D, may be D 2.0 :)

Or perhaps it should be called D++ ?

--anders

On Fri, 16 Mar 2007 02:25:24 -0700, Andrei Alexandrescu (See Website For
Email) wrote:

> Derek Parnell wrote:
>>>> int a;
>>>> const! int* p = &a; // error! cannot convert int* to const! int*
>>>> final int b = 42;
>>>> const! int* p1 = &b; // yah, b is truly immutable
>>>> const! int* p2 = new const! int; // yah
>> 
>> I'm not sure about that last one. Does this mean that p2 points to an int that cannot change and p2 itself can no longer be changed? And what is the value in the int that p2 points to?
> 
> Good point.

<G> But you didn't answer my question? What is the value of the int to which p2 is pointing?

> There is a little exception here.

Oh no ... alarms start to sound when I see 'exceptions'. Is it not possible to eliminate this exception?

> People expect that when they write:
> 
> const char[] str = "Hi!";
> 
> they can't modify str nor its characters. So they expect str to be final as well. We then arrange that if const appears in a data definition, that data is automatically made final as well. So the above is equivalent to:
> 
> final const char[] str = "Hi!";

Are you saying "People expect that when they write ... and so that's what we are going to have D do for them."?

Let's see if I got this ...

  const char[] str = "Hi!";  // Neither 'str' nor it contents can
                             // be changed.
  final const char[] str2 = "Hi again"; // Means the same as above syntax.

  const char*  chr = "Hi!";  // 'chr' can be changed but the chars
                             // it points to cannot be changed.

  final const char*  chr2 = "Hi!";  // 'chr2' can be not be changed
                               // and neither can its chars.

I hope I got this wrong because that is a easy bug maker.

> If you don't want str to be final, do this:
> 
> const(char[]) str = "Hi!";

You have got to be kidding! This is starting to get unreadable again. As a simple person, if I didn't want something to be 'final', I wouldn't use the 'final' keyword. But you are saying that if I don't want 'final', I not only have to avoid using 'final', I also have to put some of the phrase (and I know I'll never remember which parts) in parenthesis. But wait ... there's more. If I do want it to be 'final' all I have to do is not use the 'final' keyword.  Am I getting this right?

Is it not possible to make reading code simple?

>> Hmmmm... does "const char[] X" mean that X.ptr can change, X.length can never change and the data pointed to by X.ptr can never change? Or is "can never" too strong? Is it more that code within the scope of the declaration is not allowed to change those things?
> 
> See the exception above.

The EXCEPTION (alarms still ringing) seems to be saying that 'const char[] X' means that X.ptr, X.length and the data in X's RAM cannot be changed.

> But now consider a function:
> 
> void say(const char[] data)
> {
>    ...
> }
> 
> The bits of data are a private copy of say, so they can be changed discretionarily (if that's a word). But the bits pointed to by data do not belong to say, so they can't be written.
> 
> If say wants to be fancy, it can look like this:
> 
> void say(final const char[] data)
> {
>    ...
> }

That didn't help. I'm even more confused now. Can I try? ...

  void say (const char[] data)
  {
     data[0] = 'a'; // Allowed but not passed back to caller.
     data = "ABC";  // Not allowed.
  }

> Then data can't be even rebound. The "final" being a storage class, it doesn't appear in the function signature (e.g., in the interface file).

Hmmmm ... won't that cause problems for library writers who provide a library and ".di" files?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

On Fri, 16 Mar 2007 15:12:09 +0300, Anders F Björklund <afb@algonet.se> wrote:

>> It seems that D with this storage classes and const-transporting methods  will be almost different D, may be D 2.0 :)
>
> Or perhaps it should be called D++ ?

No, at first there must be 'D with macros' (like 'C with classes') and only then -- D++ :))

-- 
Regards,
Yauheni Akhotnikau

Am 16.03.2007, 10:19 Uhr, schrieb Andrei Alexandrescu (See Website For Email) <SeeWebsiteForEmail@erdani.org>:

> You can use "super const". We should be really really careful about adding new keywords; D already has tons, and I have a feeling we don't want it to become Cobol or dBase.
>
> If there are ways to stay away from new keywords, we'll do so. I do realize that no matter the syntax, there will be people who won't like it. But avoiding adding keywords liberally is an overriding desideratum.
>
>
> Andrei

Why not "const final" or "final const"?

(a) .. final
(b) .. const
(c) .. const final / final const

"super" is for calling constructors and that should be the only use for this keyword.

-mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

> No, at first there must be 'D with macros' (like 'C with classes') and only then -- D++ :))

*shudder*

D already has templates.  it shouldn't have a separate macro language.  Having one indicates that the language itself somehow fails.  Templates *should* be sufficient.

Using the ++ notation for the language is dangerous.  It allows you to only upgrade once.  You can't have a D, D++, D 2.0 etc, it just doesn't fit, 'causing the language to completely stagnate.  Then someone else has to come along and invent a language E.

I think if we properly use 'const' to define something as 'not moving', and 'final' to define something as being 'unchangeable' then you can declare final const x and be done with it.

The simpler the language is, the better.

Sincerely,
Dan

mike wrote:
> Why not "const final" or "final const"?
> 
> (a) .. final
> (b) .. const
> (c) .. const final / final const
> 
> "super" is for calling constructors and that should be the only use for  this keyword.

Wouldn't a "final const" or "const final" pointer be like using const for both the pointer and the value in C?

// D
int x = 5;
const final int* p = &x;

// C
int x = 5;
const int * const p = &x;

Andrei Alexandrescu (See Website For Email) wrote:
> We've shoved keywords like "readonly" and "view" for a while, and they just added more confusion than cleared, at a high cost. If (as I suspect) super const appears relatively infrequently, it might be fine to just encode it as the mildly verbose "super const". In fact, it's shorter than "keepyourgrubbyhandsoff". :o)
> 
> Andrei

Really? I'd think super const would be used all the time. Anywhere a class has some invariant field, it'll probably be expressed as super const (if I'm understanding correctly that super const is the equivalent of #define constants in C++ or static final constants in Java).

Let me join the ranks of those who hate both versions of the new syntax.  const! looks either like a template or like "not const". You guys may think you're saving a keyword, and that might be technically correct from the perspective of the parser. But, for the perspective of the D developer, it still looks like you've introduced a new keyword, but it's a keyword that's A) nearly identical to another keyword, and B) contains a symbol. Ugh. I really. Really. Really. Hate it.

Using "super const" is also annoying because all of the other storage classes use a single keyword. Now we've got this weird case that uses two keywords. And the word "super" is now overloaded in two completely unrelated concepts.

(By the way, I don't like "static if" either. I think the right choice would have been #if, #foreach, etc. And I think C++ made a mistake by defining "long long" and "double double" types as well. Presumably, that saved some keywords, but we'd all have been better off if the types were defined as int8, int16, int32, int64, float32, float64, etc).

I vote for "readonly" and "const". Anything else seems like a mistake.

--benji

Benji Smith wrote:
> And the word "super" is now overloaded in two completely unrelated concepts.
> 

Which isn't that rare, see the following link: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

I find the following examples: auto, in, is, mixin, scope, static.

I have come to abhor the keyword "static" largely due to the above. Too bad its various uses are unavoidably useful. <g>

But I do agree with you, in a way. After writing the following I find my explanation somewhat unclear even to myself, but bear with me.

The problem with "super const" is that "super" modifies the other keyword, "const", instead of saying something about the expression/statement/whatever (in this case, the type). Even "static", in all its horror, can be seen as specifying one of "module-level" or "compile-time". The other keywords mentioned above use their English meaning as such an explanation, and so can be understood without too much thought. "super const" would make "super" another "static": lacking context, you can't be sure about about even the general meaning, let alone the one in a specific instance.

Upon reflection it may be moot, since one probably rarely cares about keywords' meanings without context, but I'm sure some psychologist could come up with something about intuitiveness which affects coding speed, or whatever.

I'd be happiest to just get the feature as soon as possible; worrying about keyword semantics can come later. Just like the abominations beginning with "on_scope_". <g>

-- 
Remove ".doesnotlike.spam" from the mail address.