Regan Heath wrote:
> Regan Heath Wrote:
>> Because classes and arrays are reference types and int is a value type I believe this code is legal and does not violate scope.
>  <snip typo!>
>  
>> void foo(A aa, char[] bb, int cc)
>> {
>>   aaa = aa;
>>   bbb = bb;
>>   ccc = cc;
>> }
> 
> Gah!  Sorry typo there, try these:
> 
> //variables in a higher scope A aaa;
> char[] bbb;
> int ccc;
> 
> Regan

Thanks Regan.

Makes more sense now.

Regards,

Myron.

On Mon, 28 May 2007 07:43:12 +1000, Reiner Pope wrote:


> In that case, we hope the compiler can give a nice error message. :)

And start another new trend? <G> I like it!

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

James Dennett wrote:
> Walter Bright wrote:
>> I think having to write:
>>
>>     mutable int x;
>>
>> instead of:
>>
>>     int x;
>>
>> just isn't going to please people.
>
> Maybe not.  It would please me; in C++ right now, I usually
> have to write "int const x = ...;" whereas if the default
> were the "safe" form I could write just "int x = ...;".
> (As usual, "int" is just an example, of course.)
>
> Writing
>
>   var int x;
>
> would be just fine by me; I find it more readable than
> using "mutable" (and the C++ community already has a
> similar-but-different meaning for mutable, as you know,
> so using a different term might be helpful).
>

James,

Having const default for all variable declarations would be problematic in that most variables are expected to be mutable. The whole point of variables is that they are variable :)

I think the one exception is strings in that the D implementation is an array but conceptually, there is a difference of opinion for whether strings are buffers or values. I am firmly on the "string is a value" bench and have my wet trout ready to go slap the "other" side when the mother of all wars begins :) (Actually, I have a nuke-lee-are trout that is const, non-static, and very final ;))


Walter Bright wrote:
> Regan Heath wrote:
>> Walter Bright Wrote:
>>>> Why can't we apply 'scope const final' to function parameters only?
>>> Because it knocks people for a loop - gives a bad first impression.
>>
>> Have these people tried using it, in the beta itself?
> 
> No. But you can't get people to try something they take an instant dislike to.

I am of the opinion that function parameters that are, by default, "scope const final" will improve code quality. When coding (even in Python and Java), I use that style.

My reasoning is that values passed in are part of the interface state and that rebinding, or modifying them can lead to confusion or errors. A quick example that actually happened to me:

Two people working on the same code need to modify a method. This method is quite long so when the other programmer added some code in the middle that modified the parameter value before I used it, on merge, there was a problem. The other person did not need to modify the actual parameter value but was too lazy to assign it to a temp variable thus the problem. (BTW, this is not how I work, it was the team leader's idea of "collaboration". We weren't even using CVS, the merge was manual). I have seen similar bugs on more than one occasion.

BTW, if I declare a class parameter to be const, what happens if I try to call a method that will change the class state?

Regards,

Myron.

Johan Granberg palsat
> Rioshin an'Harthen wrote:
> > (Basically, in and no specifier swap places compared to Walter's
> > suggestion.)
> I like this one, basically it's safe by default and saves typing in the most common case, it would also avoid the problem I see in c++ sometimes, that people don't write const because it's more typing. Walter please reconsider, const by default will be worth any initial hassle.

I agree -- as long as there's good documentation on the meaning of each, the worst I have to deal with is an occasional compiler warning and a quick look at the docs. It also makes everything very consistent in that no changes get propagated unless I specify that they should be.

I was one of the people getting confused, and that was mostly over the definitions of scope, const, and final. Once I have a compiler yelling at me, I can either find out with a quick test or, if the compiler warnings are good, just change the attributes as the warning says I should. Or I could just, y'know, read the documentation.

Myron Alexander wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> I think having to write:
>>>
>>>     mutable int x;
>>>
>>> instead of:
>>>
>>>     int x;
>>>
>>> just isn't going to please people.
>>
>> Maybe not.  It would please me; in C++ right now, I usually
>> have to write "int const x = ...;" whereas if the default
>> were the "safe" form I could write just "int x = ...;".
>> (As usual, "int" is just an example, of course.)
>>
>> Writing
>>
>>   var int x;
>>
>> would be just fine by me; I find it more readable than
>> using "mutable" (and the C++ community already has a
>> similar-but-different meaning for mutable, as you know,
>> so using a different term might be helpful).
>>
> 
> James,
> 
> Having const default for all variable declarations would be problematic in that most variables are expected to be mutable. The whole point of variables is that they are variable :)

I disagree!  Experience (from C++) has shown me that a
large proportion of "variables" are not changed after
their initialization.  I find that it's true of most
local variables (including function parameters), and
using immutable objects with reference semantics is
also fairly common.

The advantages in compiler checking mean that even if
there is a (sufficiently small) additional cost in
having the default be immutability, my experience
strongly suggests that it would be worthwhile.  As
I've said, I also find that the cost would be small,
given how many "variables" aren't variable in clean
code.  (Who knows, maybe this default could even
encourage people to use new variables when they have
a different value with a different meaning, rather
than reusing a "convenient" local variable which was
used for something else.  But now I'm dreaming.)

> I think the one exception is strings in that the D implementation is an array but conceptually, there is a difference of opinion for whether strings are buffers or values. I am firmly on the "string is a value" bench and have my wet trout ready to go slap the "other" side when the mother of all wars begins :) (Actually, I have a nuke-lee-are trout that is const, non-static, and very final ;))

My understanding is that in D, arrays (almost) have
reference semantics.  It's a shame, IMO, but languages
have to make choices and there's no way one language
is going to make them all the way I would unless I
design it myself (and I don't believe that I could
successfully bring a language to a mass audience as
Walter is attempting to do).

-- James

Walter Bright wrote:
> janderson wrote:
>> On this point, couldn't it be something like, if you define const, final or scope then the default "const final scope" is removed?
> 
> That was my thought, too, but that just confused things for others even more.

"in" seems reasonable to me.  Imagine you could require either "in?, or const, final scope in the definition or the compiler would complain.

-Joel

James Dennett wrote:
> Myron Alexander wrote:
> [...]
>> I think the one exception is strings in that the D implementation is an
>> array but conceptually, there is a difference of opinion for whether
>> strings are buffers or values. I am firmly on the "string is a value"
>> bench and have my wet trout ready to go slap the "other" side when the
>> mother of all wars begins :) (Actually, I have a nuke-lee-are trout that
>> is const, non-static, and very final ;))
> 
> My understanding is that in D, arrays (almost) have
> reference semantics.  It's a shame, IMO, but languages
> have to make choices and there's no way one language
> is going to make them all the way I would unless I
> design it myself (and I don't believe that I could
> successfully bring a language to a mass audience as
> Walter is attempting to do).

Actually, the intent is for string literals to be invariant arrays, which mean that they will be values implemented as reference types. ;) Hey, Java does it and it works just fine!  Walter chose to make D's arrays be references for performance reasons.  It is still possible to create C-style arrays with value semantics using pointers and structs (almost, as soon as structs get fixed).  However, since D relies heavily on arrays, it was important to make them fast by default (and passing arrays more than about 16 bytes large is almost certainly faster by value than by reference).  I've seen plenty of C++ noobs (and experienced coders) passing around std::vector<> by value out of laziness or ignorance or both.  At least users can't make that mistake in D.

Dave

James Dennett wrote:
> 
> I disagree!  Experience (from C++) has shown me that a
> large proportion of "variables" are not changed after
> their initialization.  I find that it's true of most
> local variables (including function parameters), and
> using immutable objects with reference semantics is
> also fairly common.
> 

Would you please post some example. My experience in C, C++, and Java is different from yours. I'm not saying you are exactly wrong, I understand where you are coming from, especially with class instance references but my way of coding has more mutable variables than constants. I think it is a matter of program style and I don't mind writing "final Xx x = new Xx ();" which I do often in Java.

> The advantages in compiler checking mean that even if
> there is a (sufficiently small) additional cost in
> having the default be immutability, my experience
> strongly suggests that it would be worthwhile.  As
> I've said, I also find that the cost would be small,
> given how many "variables" aren't variable in clean
> code.  (Who knows, maybe this default could even
> encourage people to use new variables when they have
> a different value with a different meaning, rather
> than reusing a "convenient" local variable which was
> used for something else.  But now I'm dreaming.)

Once again, please post an example. I am curious to see your code style, maybe I can learn from it.

Regards,

Myron.

On Mon, 28 May 2007 13:05:47 +0200, Myron Alexander wrote:


> Once again, please post an example. I am curious to see your code style, maybe I can learn from it.

I have a style which has the program gathers a lot of it's "literals" from optional data supplied to it at run time. In other words, I prefer to write highly user-customisable applications. This has the effect that a lot of variables are set to default values then overridden as nominated by the user running the program. This makes using 'final' and 'invariant' problematic, I think.

I might have to change my style to something like ...

  string[string] UserOptions;
  UserOptions = CollectUserOptions();

  // Move them to final vars for performance reasons.
  final string OptionOne = UserOption["One"].dup;
  final string OptionTwo = UserOption["Two"].dup;

  UserOptions = null; // get rid of mutable stuff.
   . . .
   // From here on the options can't be changed.


  string[string] CollectUserOptions()
  {
    string[string] temp;

    // Set default values.
    temp["One"] = "aaaa";
    temp["Two"] = "bbbb";

    // Who knows where these are collected from
    // as it doesn't matter for this example
    if (<option one supplied>)
       temp["One"] = <suppliedvalue>;

    if (<option two supplied>)
       temp["Two"] = <suppliedvalue>;

    return temp;
  }

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

> Would you please post some example. My experience in C, C++, and Java is different from yours. I'm not saying you are exactly wrong, I understand where you are coming from, especially with class instance references but my way of coding has more mutable variables than constants. I think it is a matter of program style and I don't mind writing "final Xx x = new Xx ();" which I do often in Java.
> 

The idea of a save default is, that if you don't care, the compiler raises an error if you change the value after the initial assignment. The compiler can only detect a missing "mutable" (or call it 'var'), but there is no way the compiler can detect a missing "const". And that is the advantage of const by default.

So i think it is not a matter of "I use more const than non-const" or vice versa, it is a issue of making mutable things explicitely.

an example i see here:

foreach( m; myCollection ){
  C c = m.getC();
  c.doA();
  c.doB();
  C c2 = m.getTheOtherC();
}

m is const, because its live cycle starts and ends with each iteration. Most of my object references are initialized once. I omit to reuse reference variables.

Object member variables, that are not initialized in the ctor, are worth to be marked as mutable, because they are the complicated states in the object, which need special care.