Walter Bright Wrote:
> Frank Benoit wrote:
> > Perhaps we look at it from the wrong side.
> > 
> > If we want to change the D language to make it more const, the keywords 'const', 'invariant'... are probably the wrong choice.
> > 
> > How about restricting keywords and add their opposites: 'mutable', 'once' (write once) and then make every variable declaration const by default? Each variable/parameter needs to be made modifyable with modifiers if needed.
> 
> I think having to write:
> 
> 	mutable int x;
> 
> instead of:
> 
> 	int x;
> 
> just isn't going to please people.

Ahhh, I think I see what you're concerned about.  As in this example?

mutable int gx;
void foo(int y) {  //y is scope const final
  mutable int z;
}

where the global and local scope ints 'gx' and 'z' are not supposed to be const scope final.

Why can't we apply 'scope const final' to function parameters only?

In fact, that's what I was proposing when I said implicit 'in' should be 'const scope final'.  Global and local scope variables are not 'in' therefore are not 'const scope final'.

Regan Heath

Myron Alexander Wrote:
> janderson wrote:
> > Walter Bright wrote:
> >> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
> > 
> > On this point, couldn't it be something like, if you define const, final or scope then the default "const final scope" is removed?
> > 
> > [snip]
> 
> I agree with this suggestion. I always insist on the most restrictions possible and relaxing restrictions on a case-by-case basis. This is what I call tight code :)
> 
> I understand scope within the function body but I do not understand scope for parameters. How does scope affect class references, arrays, and primitives (like int)?

It's my understanding that if you have:

Class A { int a; }
void foo(A aa, char[] bb, int cc) {}
void main()
{
  A a = new A();
  char[] b = "b";
  int c = 1;
  foo(a,b,c);
}

when you call 'foo' you get a copy of a, b, and c called aa, bb, and cc.  These copies are naturally 'scope' because they only exist in the function scope, after which they vanish;  because they are copies on the stack.

Therefore having a foo like this would be illegal:


//variables in a higher scope
A* pa;
char[]* pb;
int *pc;

void foo(A aa, char[] bb, int cc)
{
  pa = &aa;
  pb = &bb;
  pc = &cc;
}

you would be violating 'scope' and should get errors.  Likewise returning the address of one of these would be illegal:

A* foo(A aa) {  return &aa; }

Because classes and arrays are reference types and int is a value type I believe this code is legal and does not violate scope.

//variables in a higher scope
A* aaa;
char[]* bbb;
int *ccc;

void foo(A aa, char[] bb, int cc)
{
  aaa = aa;
  bbb = bb;
  ccc = cc;
}

I think I may have muddied the waters with bad examples prior to this point.

Regan Heath

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

Regan Heath wrote:
> Ahhh, I think I see what you're concerned about.  As in this example?
> 
> mutable int gx;
> void foo(int y) {  //y is scope const final
>   mutable int z;
> }

Yes. Even I wouldn't use such a language :-(

> Why can't we apply 'scope const final' to function parameters only?

Because it knocks people for a loop - gives a bad first impression.

Walter Bright Wrote:
> Regan Heath wrote:
> > Ahhh, I think I see what you're concerned about.  As in this example?
> > 
> > mutable int gx;
> > void foo(int y) {  //y is scope const final
> >   mutable int z;
> > }
> 
> Yes. Even I wouldn't use such a language :-(

I agree.

> > Why can't we apply 'scope const final' to function parameters only?
> 
> Because it knocks people for a loop - gives a bad first impression.

Really?  Have these people tried using it, in the beta itself?  Or have you just explained it to them?  I would hope that once someone actually uses it, it would come quite naturally.

The hope is that these automatic restrictions will prevent bad programming practices, assuming they do that it must mean these people like to use bad programming practices?  or maybe we're preventing things which aren't bad programming practices?  if so, what?

As this is going to be a 'beta' can we just give it a go anyway?  I mean, once people start using it we can get concrete examples of where it doesn't work, or is a hindrance, or whatever.

I know "having things work the way you'd expect them to" is something you want for D, but surely there are ingrained but 'bad' expectations which exist, those which we should really contradict in as definate a fashion as possible in order to evolve.

Regan Heath

Regan Heath wrote:
> Walter Bright Wrote:
>> Frank Benoit wrote:
>>> Perhaps we look at it from the wrong side.
>>>
>>> If we want to change the D language to make it more const, the keywords
>>> 'const', 'invariant'... are probably the wrong choice.
>>>
>>> How about restricting keywords and add their opposites: 'mutable',
>>> 'once' (write once) and then make every variable declaration const by
>>> default? Each variable/parameter needs to be made modifyable with
>>> modifiers if needed.
>> I think having to write:
>>
>> 	mutable int x;
>>
>> instead of:
>>
>> 	int x;
>>
>> just isn't going to please people.
> 
> Ahhh, I think I see what you're concerned about.  As in this example?
> 
> mutable int gx;
> void foo(int y) {  //y is scope const final
>   mutable int z;
> }
> 
> where the global and local scope ints 'gx' and 'z' are not supposed to be const scope final.
> 
> Why can't we apply 'scope const final' to function parameters only?

Because he said "that seems to throw people for a loop."  I'm guessing the qualm is that in this:

int* gx;
void foo(int* y) {
  int* z;
}

all three of those declarations sure look the same to an uninitiated C++ (or current D) user.  So I think by "throws people for a loop", Walter means "isn't obvious to C++ converts".  But well... all I have to say to that is why would you expect any form of const by default to look natural to a C++ user?  It's just not going to.  But the hope is they'll thank you for it in the long run.

--bb

Jarrett Billingsley wrote:
> "Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:f3b74k$bbk$2@digitalmars.com...
>> Or maybe something like:
>> alias const( char)[] utf8  ; // or even u8string
>> alias const(wchar)[] utf16 ; // or even u16string
>> alias const(dchar)[] utf32 ; // or even u32string
>>
> 
> Yes, I really like those :)
> 
> 

Sort of a newb question; Why put stuff like this in the core "language".
Phobos can have one, tango can have another, other runtime libs can have
 what-ever suits. Ignore this if that's what is being proposed and I
misunderstood.

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.

Yes please! An explanation page for those of us that haven't been following this for the last year, or don't code in D yet.


Jason House wrote:
> For those of us who haven't read all the threads on this stuff... Is there a page I can go to and read about the planned changes to D for this stuff?
> 
> I guess I wonder which combinations of qualifiers would make sense as in, out, and inout parameters.  I'd then try to figure out how one would write out any of the variations and try to make the most common ones as short and understandable as possible.
> 
> 
> Walter Bright wrote:
>> It looks like making "const final scope" be the default for function parameters is going to be infeasible. The troubles are that:
>>
>> 1) It seems to knock a lot of people for a loop, who will be assuming that an undecorated name would be like an undecorated name for a local or global variable.
>>
>> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
>>
>> However, making "in" be equivalent to "const final scope" does seem to work fine, requires no new keywords, and doesn't seem to confuse anyone.
>>
>> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.

Bill Baxter wrote:
> Regan Heath wrote:
>> Walter Bright Wrote:
>>> Frank Benoit wrote:
>>>> Perhaps we look at it from the wrong side.
>>>>
>>>> If we want to change the D language to make it more const, the keywords
>>>> 'const', 'invariant'... are probably the wrong choice.
>>>>
>>>> How about restricting keywords and add their opposites: 'mutable',
>>>> 'once' (write once) and then make every variable declaration const by
>>>> default? Each variable/parameter needs to be made modifyable with
>>>> modifiers if needed.
>>> I think having to write:
>>>
>>>     mutable int x;
>>>
>>> instead of:
>>>
>>>     int x;
>>>
>>> just isn't going to please people.
>>
>> Ahhh, I think I see what you're concerned about.  As in this example?
>>
>> mutable int gx;
>> void foo(int y) {  //y is scope const final
>>   mutable int z;
>> }
>>
>> where the global and local scope ints 'gx' and 'z' are not supposed to be const scope final.
>>
>> Why can't we apply 'scope const final' to function parameters only?
> 
> Because he said "that seems to throw people for a loop."  I'm guessing the qualm is that in this:
> 
> int* gx;
> void foo(int* y) {
>   int* z;
> }
> 
> all three of those declarations sure look the same to an uninitiated C++ (or current D) user.  So I think by "throws people for a loop", Walter means "isn't obvious to C++ converts".  But well... all I have to say to that is why would you expect any form of const by default to look natural to a C++ user?  It's just not going to.  But the hope is they'll thank you for it in the long run.
> 
> --bb
> 
I don't think it's a rule you're likely to forget, either, because it makes sense and can be concisely phrased: "because the safest and most common way to deal with function parameters is by not modifying or retaining them outside the function scope, function parameters default to 'const scope final'"

Also, const won't affect the behaviour of your code, so the only place you will run into difficulties is when trying to compile bad code. In that case, we hope the compiler can give a nice error message. :)


  -- Reiner