View mode: basic / threaded / horizontal-split · Log in · Help
May 09, 2007
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
== 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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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)
1 2 3 4 5
Top | Discussion index | About this forum | D home