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.

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...

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" ;)

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

== 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

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

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.

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.

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)