May 10, 2007
renoX wrote:
> Walter Bright a écrit :
>> 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.
> 
> If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer.  And most uses will be close to the left margin I suspect.  And even if invariant is the most interesting, I think const will still be the most used.

--bb
May 10, 2007
Bill Baxter wrote:
> renoX wrote:
>> Walter Bright a écrit :
>>> 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.
>>
>> If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..
> 
> But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer.  And most uses will be close to the left margin I suspect.  And even if invariant is the most interesting, I think const will still be the most used.

I still can't keep all these straight in my head--the words are all synonyms.  Hopefully that will change after I've used them a bit.


Sean
May 11, 2007
Sean Kelly wrote:
> Bill Baxter wrote:
>> renoX wrote:
>>> Walter Bright a écrit :
>>>> 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.
>>>
>>> If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..
>>
>> But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer.  And most uses will be close to the left margin I suspect.  And even if invariant is the most interesting, I think const will still be the most used.
> 
> I still can't keep all these straight in my head--the words are all synonyms.  Hopefully that will change after I've used them a bit.
> 
> 
> Sean

I think I've just about gotten my head around it, but also feel it will come moreso with use.  I think of the word invariant as a "stronger" word than const(ant) -- the latter being a more common term, and the former more... formal -- so that's how I deal with it; ie, that 'invariant' is a "stronger contract" than 'const' is.  At least my time with Java semi-prepared me for 'final'.

-- Chris Nicholson-Sauls
May 11, 2007
Chris Nicholson-Sauls wrote:
> Sean Kelly wrote:
>> Bill Baxter wrote:
>>> renoX wrote:
>>>> Walter Bright a écrit :
>>>>> 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.
>>>>
>>>> If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..
>>>
>>> But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer.  And most uses will be close to the left margin I suspect.  And even if invariant is the most interesting, I think const will still be the most used.
>>
>> I still can't keep all these straight in my head--the words are all synonyms.  Hopefully that will change after I've used them a bit.
>>
>>
>> Sean
> 
> I think I've just about gotten my head around it, but also feel it will come moreso with use.  I think of the word invariant as a "stronger" word than const(ant) -- the latter being a more common term, and the former more... formal -- so that's how I deal with it; ie, that 'invariant' is a "stronger contract" than 'const' is.  At least my time with Java semi-prepared me for 'final'.
> 
> -- Chris Nicholson-Sauls

Mentally, I can cope with const if I view it as abbreviation of 'constrained' (if you think of it as 'constant', IMHO it gets horribly nonintuitive). It's obvious that 'invariant' is an extreme case of 'constrained'.
May 11, 2007
Don Clugston wrote:
> Mentally, I can cope with const if I view it as abbreviation of 'constrained' (if you think of it as 'constant', IMHO it gets horribly nonintuitive). It's obvious that 'invariant' is an extreme case of 'constrained'.

That's a great way to remember it.  That plus Chris's "more letters means more strength than const", and there's no way I'll ever forget again.

--bb
May 11, 2007
Bill Baxter a écrit :
> Don Clugston wrote:
>> Mentally, I can cope with const if I view it as abbreviation of 'constrained' (if you think of it as 'constant', IMHO it gets horribly nonintuitive). It's obvious that 'invariant' is an extreme case of 'constrained'.
> 
> That's a great way to remember it.  That plus Chris's "more letters means more strength than const", and there's no way I'll ever forget again.
> 
> --bb

While this makes it easy to remember, I can't help but thinking about all these people who claims that functional programming is better..

If they're right then it should be totally the opposite:
invariants by default and if we want to have a variable then we have to precise it..

renoX

May 12, 2007
I really like this idea; this is one of the "lateral" changes I've been wanting. By that I mean changes that take a step sideways and change the way things are currently done, rather than moving forward with new features etc.

A couple of the others that I'd love to see:

- Phobos in a public repo
- Decoupling of the D compiler from Phobos (and maybe division of Phobos into separate libs) to avoid all the hacks people need to employ to use alternatives such as Tango

There are others I can't think of now, but I'd be interested in knowing what other changes people have been hoping for that fall into that category. (Eep, scope creep in my message; maybe this should be a separate thread? :P) They seem like the sort of changes to be considered as soon as possible, to make moving forward later easier and cleaner.

Cheers
Jeff :)
May 12, 2007
renoX wrote:
> While this makes it easy to remember, I can't help but thinking about all these people who claims that functional programming is better..
> 
> If they're right then it should be totally the opposite:
> invariants by default and if we want to have a variable then we have to
> precise it..
> 

Walter said once that he should have made const the default (this is before this
const/final/invariant stuff, so just replace const with "any constant
qualifier"). See the following Google Groups link, near the bottom of the post:
http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3#doc_3ff8dedacef55e17

FWIW, I think it's still not too late, especially with the 2.0 fork there can't possibly be "[t]oo much water under the bridge". If the whole const system is being rewritten anyway, might as well bring in const by default.

-- 
Remove ".doesnotlike.spam" from the mail address.
May 12, 2007
Deewiant wrote:

> renoX wrote:
>> While this makes it easy to remember, I can't help but thinking about all these people who claims that functional programming is better..
>> 
>> If they're right then it should be totally the opposite:
>> invariants by default and if we want to have a variable then we have to
>> precise it..
>> 
> 
> Walter said once that he should have made const the default (this is before this const/final/invariant stuff, so just replace const with "any constant qualifier"). See the following Google Groups link, near the bottom of the post:
>
http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3#doc_3ff8dedacef55e17
> 
> FWIW, I think it's still not too late, especially with the 2.0 fork there can't possibly be "[t]oo much water under the bridge". If the whole const system is being rewritten anyway, might as well bring in const by default.
> 

Yes, if we got immutability as a default it could catch a number of common bugs.
May 12, 2007
Jeff, el 12 de mayo a las 15:58 me escribiste:
> I really like this idea; this is one of the "lateral" changes I've been wanting. By that I mean changes that take a step sideways and change the way things are currently done, rather than moving forward with new features etc.
> 
> A couple of the others that I'd love to see:
> 
> - Phobos in a public repo
    and comunity driven (maybe with Walter as BDFL).
> - Decoupling of the D compiler from Phobos (and maybe division of Phobos into separate libs) to avoid all the hacks people need to employ to use alternatives such as Tango
  - Versioned specification, so D can be a language specification rather a
    compiler implementation (this will help compiler developers).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
 .------------------------------------------------------------------------,
  \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
   '--------------------------------------------------------------------'
Home, home again.
I like to be here when I can.
When I come home cold and tired
It's good to warm my bones beside the fire.