May 09, 2007
Chris Nicholson-Sauls wrote:
> Actually, that'll be 'final'.  The new 'invariant' will mean "this *data* absolute does not change", and the new 'const' will mean "this is an *immutable view* into data owned by other code, which *may* change".  (If I'm remembering/understanding right.)

You're right.
May 10, 2007
Walter Bright wrote:
> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
> 
> The first few iterations of const support probably will have lots of problems before it gets usable.
> 
> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.

Do you intend that 2.x would add features to handle multi-processor systems?  (Please?)  I don't have anything definite to propose, though of course Java's "synchronized" comes to mind.

Well, I suppose that should first be "Do you have a proposed feature list?" of stuff that's been held back...

May 10, 2007
On Wed, 09 May 2007 14:56:14 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
>
> The first few iterations of const support probably will have lots of problems before it gets usable.
>
> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.


Well, hooray...

But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)
May 10, 2007
Chris Miller wrote:
> On Wed, 09 May 2007 14:56:14 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
>>
>> The first few iterations of const support probably will have lots of problems before it gets usable.
>>
>> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.
> 
> 
> Well, hooray...
> 
> But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)


That't the observation that leads one to start thinking about making const the default in places where it makes sense.  Like on reference parameters to functions.  Rather than having to explicitly declare "hey I'm not going to modify this data" you only have to explicitly declare the "hey I AM going to modify this data" case.

I really don't know if it would end up being a net gain.  But it seems appealing.  The nice thing is that with C++ const arguments, if you write a function foo() that doesn't modify its arguments, but forget to mark the args as const, it's often some OTHER programmer who discovers that fact, because you might never try to call foo with a const param in your program.  But the poor other programmer who discovers it has to figure out whether to modify your code, or try to get you to fix it, or submit a patch or whatever, or const cast.

But with const default, if you forget to specify foo's arguments as mutable and you start trying to modify them in the function you're going to find out right away, when you're writing foo, not some time later when you try to call foo.

--bb
May 10, 2007
Walter Bright wrote:
> Chris Nicholson-Sauls wrote:
>> Actually, that'll be 'final'.  The new 'invariant' will mean "this *data* absolute does not change", and the new 'const' will mean "this is an *immutable view* into data owned by other code, which *may* change".  (If I'm remembering/understanding right.)
> 
> You're right.

Which gets me to thinking: will const parameters be implicitly passed by referance?  Given something like (contrived):

<code>
import std.stdio;

void main () {
  int i = 0;

  void inc () { ++i; }

  void foo (const int x) {
    write(x);
    inc();
    write(x);
  }

  foo(i);
}
</code>

Should I expect to see it output 01 or 00?

-- Chris Nicholson-Sauls
May 10, 2007
== Quote from Charles D Hixson (charleshixsn@earthlink.net)'s
article
> Do you intend that 2.x would add features to handle multi-processor systems?  (Please?)  I don't have anything definite to propose, though of course Java's "synchronized" comes to mind.

"synchronized" has been in D for as long as I can remember.  Or am I missing something?


Sean
May 10, 2007
I'm not sure if anyone has asked yet, but will there be a predefined version identifier for 1.0 vs. 2.0?  To migrate gradually, it might be useful if there were a way to make code cross-compilable.


Sean
May 10, 2007
Bill Baxter wrote:
> Chris Miller wrote:
>> On Wed, 09 May 2007 14:56:14 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
>>>
>>> The first few iterations of const support probably will have lots of problems before it gets usable.
>>>
>>> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.
>>
>>
>> Well, hooray...
>>
>> But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)
> 
> 
> That't the observation that leads one to start thinking about making const the default in places where it makes sense.  Like on reference parameters to functions.  Rather than having to explicitly declare "hey I'm not going to modify this data" you only have to explicitly declare the "hey I AM going to modify this data" case.
> 
> I really don't know if it would end up being a net gain.  But it seems appealing.  The nice thing is that with C++ const arguments, if you write a function foo() that doesn't modify its arguments, but forget to mark the args as const, it's often some OTHER programmer who discovers that fact, because you might never try to call foo with a const param in your program.  But the poor other programmer who discovers it has to figure out whether to modify your code, or try to get you to fix it, or submit a patch or whatever, or const cast.
> 
> But with const default, if you forget to specify foo's arguments as mutable and you start trying to modify them in the function you're going to find out right away, when you're writing foo, not some time later when you try to call foo.
> 
> --bb

I think that's a good idea.
May 10, 2007
Sean Kelly wrote:
> == Quote from Charles D Hixson (charleshixsn@earthlink.net)'s
> article
>> Do you intend that 2.x would add features to handle
>> multi-processor systems?  (Please?)  I don't have anything
>> definite to propose, though of course Java's "synchronized"
>> comes to mind.
> 
> "synchronized" has been in D for as long as I can remember.  Or am
> I missing something?
> 
> 
> Sean
More likely I am.  It looks like I need to dig through the manual a bit more carefully.
May 10, 2007
Walter Bright pisze:
> I'm currently working on implementing const/invariant. It's becoming clear that this is a pervasive change, and will cause binary incompatibility with existing code. I'm trying to minimize any source incompatibilities.
> 
> The first few iterations of const support probably will have lots of problems before it gets usable.
> 
> This means that dmd will have to fork into a 1.x maintenance version and a 2.x beta.

Any chances to get these branches in the form of open SVN repository accessible from D main page? It would be really big step forward IMHO...

BR
Marcin Kuszczak
(aarti_pl)