Great, thank you!

Walter Bright wrote:
> Johan Granberg wrote:
>> I don't think invariant here is such a great idea, consider the following
>> function.
>>
>> void foo(string s){}
>>
>> if string is const this can be called with both char[] and const(char)[] (if
>> not please correct me) but if my understanding is correct char[] would not
>> work if string is invariant. This will lead to an unessesary amount of
>> cast(invariant) when calling functions on local strings (as functions that
>> create strings will have to modify the when they are being built).
> 
> That's essentially my argument against it, too. The other side is that treating strings as if they are value types is common and effective in other languages. (For example, strings in Perl are invariant.)
> 
> One of the reasons for adding .idup is to reduce the need to cast to invariant.

I realize that string is, at it's base, an alias.  But thinking of string as a type, if string is a const, then there ought to be a word to allow the declaration of non-const strings.

I.e., if a type that is not inherently const is made const by the language, then there ought to be a modifier to remove the const'ness of it.  This is clumsy, so perhaps strings should not be const.

As for the way that other languages do things... I seem to recall that the justification for implementing const strings has usually been speed.  Would that apply in the case of D?

So my argument against const strings is basically shaped around symmetry.  If symmetry is broken by having strings be const, then to restore it one would need a type modifier meaning mutable

The potential argument in favor of const strings seems, to me, to be speed.  But I don't know whether it applies.

Reiner Pope wrote:
> This looks great!
> 
> But as it is, I can't find a difference between invariant(char)[] and invariant(char[]).

There isn't one for declarations, as the const/invariant doesn't apply to the declaration's value itself - only what the declaration refers to.


> And thirdly, I'm not sure about invariant and const as storage classes. They seem to be identical, saying "a compile-time constant", but also applying transitively to their types. But if I have a compile-time constant, how can it refer to data that can change?

There is no difference between:

	const int x = 3;

and:

	invariant int x = 3;

The difference between const and invariant shows up with references to other data.

In my world , nature is pessimistic and says "Do not trust the programmer"

Programmers even those top hackers could still make silly bugs , and several
other top hackers will spend dozens times effort on fixing it.

In my opinion , the language itself should be as much pessimistic as possible.
This could squeeze out the every possibilies of making mistakes by some error-
compromising compilers.

> Seems to me that D is going into the wrong direction.
> Are you really sure that strings should be inmutable by default?
> Not in my world. In my world an invariant string is the *Exeption*.
>
> I hate that feature because it s nature is /pessimistic/ and says "Do not trust the programmer".
>
> So please tell me what do we have to expect from D 2 ?
> More CPP like programming refined with syntactic sugar,or something that makes D comparable to Java s useablility ?
> Bjoern
>
>
>
> Walter Bright schrieb:
>> This is an alpha release to try out the const/final/invariant stuff.
>>  The current definition of string is:
>>      alias const(char)[] string;
>>  Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.
>>  The documentation isn't thorough, I don't want to spend too much time on it until I'm sure we've got the design right.
>>  Treat this as an alpha release. Although it passes its test suite, I'm sure there are plenty of bugs remaining. Phobos also has not been thoroughly gone through to put const/final in all the right places.
>>  See http://www.digitalmars.com/d/final-const-invariant.html
>>  http://www.digitalmars.com/d/changelog.html
>>  http://ftp.digitalmars.com/dmd.2.000.zip
>>  Expect changes to this. Much more to come! For stability, I recommend sticking with the 1.0 series, which I will maintain with bug fixes.



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

considering the 3 declarations
1) const(char)* p;
2) const(char*) p;
3) const char*  p;

i identify 3 entities in play here: the character *p, the address of it's memory cell p and the location where that address is stored &p. the language let's us change p and *p, &p is always invariant.
in 3) p and *p are const,
in 2) p is mutable and *p is const
and 1) is the same!?

what is const in 2) that is mutable in 1) ?

davidl wrote:
> In my world , nature is pessimistic and says "Do not trust the programmer"

Poor sod... :)

I my world, if you cannot trust the programmer, you can trust no one.

Regards, Frank

---

First they have forbidden typecasts, then they have abolished true pointers,
now everyone is coding in Java......

Jascha Wetzel wrote:
> considering the 3 declarations
> 1) const(char)* p;
> 2) const(char*) p;
> 3) const char*  p;
> 
> i identify 3 entities in play here: the character *p, the address of it's memory cell p and the location where that address is stored &p. the language let's us change p and *p, &p is always invariant.
> in 3) p and *p are const,
> in 2) p is mutable and *p is const
> and 1) is the same!?
> 
> what is const in 2) that is mutable in 1) ?

In this case, there is no difference between (1) and (2), because a const type for a declaration's value is ignored.

For (3), const is being used as a storage class, not a type modifier, and so p is not mutable.

Charles D Hixson wrote:
> The potential argument in favor of const strings seems, to me, to be speed.  But I don't know whether it applies.

The argument for const strings isn't speed, it's understandability. People tend to think of them as value types (like ints), and by making strings const (or invariant) it makes them behave like value types.

On Wed, 20 Jun 2007 19:55:47 -0700, Walter Bright wrote:

> Charles D Hixson wrote:
>> The potential argument in favor of const strings seems, to me, to be speed.  But I don't know whether it applies.
> 
> The argument for const strings isn't speed, it's understandability.

I thought it was about safety. About not accidentally changing stuff that was not indented to be changed.

> People tend to think of them as value types (like ints),

No problems with that so far ...

>  and by making
> strings const (or invariant) it makes them behave like value types.

This is where you lose me though. Your statement seems to only apply when talking about function parameters -- and then it really is about speed too.

For example, I can get the same effect as const even when not using const, but at a run-time cost.

Without CONST
   void func(char[] a) { ... }
   char str = "abc".dup;
   func(str.dup); // Now I don't care what 'func' does with my data.

With CONST
   void func(const (char)[] a) { ... }
   char str = "abc".dup;
   func(str); // I still don't care what 'func' does with my data.

The difference is that the CONST version is faster and gives the compiler a clue about the writer's intentions (and thus can issue appropriate error messages)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
21/06/2007 2:00:38 PM

Derek Parnell wrote:
> On Wed, 20 Jun 2007 19:55:47 -0700, Walter Bright wrote:
> 
>> Charles D Hixson wrote:
>>> The potential argument in favor of const strings seems, to me, to be speed.  But I don't know whether it applies.
>> The argument for const strings isn't speed, it's understandability. 
> 
> I thought it was about safety. About not accidentally changing stuff that
> was not indented to be changed.

The two are closely related.


>>  and by making strings const (or invariant) it makes them behave like value types.
> 
> This is where you lose me though. Your statement seems to only apply when
> talking about function parameters -- and then it really is about speed too.
> 
> For example, I can get the same effect as const even when not using const,
> but at a run-time cost.
> 
> Without CONST
>    void func(char[] a) { ... }
>    char str = "abc".dup;
>    func(str.dup); // Now I don't care what 'func' does with my data.
> 
> With CONST
>    void func(const (char)[] a) { ... }
>    char str = "abc".dup;
>    func(str); // I still don't care what 'func' does with my data.
> 
> The difference is that the CONST version is faster and gives the compiler a
> clue about the writer's intentions (and thus can issue appropriate error
> messages)

Value types work by making lots of copies. By making a reference type const, it can behave as a value type without the cost of making copies. In that context, yes, it is about speed.