Extended Type Design.
Andrei Alexandrescu (See Website For Email)
SeeWebsiteForEmail at erdani.org
Fri Mar 16 16:43:35 PDT 2007
Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> Benji Smith wrote:
>>>>> I should also add that, in my opinion, any design where "const"
>>>>> means something other than "value resolved at compile time and
>>>>> immutable at runtime" would be a mistake.
>>>>
>>>> I hear you. I've always disliked C++'s mutable const.
>>>>
>>>> The most important thing at this stage is not the keyword, however,
>>>> but getting the design right. Andrei, myself and Bartosz have been
>>>> to hell and back several times over this over the last few months,
>>>> and have filled about two notebooks with scribblings. It's a
>>>> difficult problem.
>>>
>>> I very much agree. But with little information about how these new
>>> flavors of const will work, it seems we're mostly stuck debating how
>>> they will look :-) I'd welcome discussing the former issue, but I
>>> suspect that anything which is said here will have already been
>>> discussed between you three.
>>>
>>>> There are 3 distinct, and very different, flavors of constant:
>>>>
>>>> 1) rebinding of a value to a name
>>>> 2) a read-only view of a data structure
>>>> 3) a value that never changes
>>>
>>> It seems like #1 is only useful for reference types, which currently
>>> means pointers and class handles.
>>
>> #1 is essential for expressing numeric constants.
>
> Could you please provide an example?
final int x = 42;
>>> Further, I don't think I've ever found a need for this particular
>>> class of immutability in C++. How often does it really matter
>>> whether someone can reassign a pointer?
>>
>> Very important. Often you want to bind a pointer to something and make
>> sure nothing can change that.
>
> Perhaps this should be rewritten as "often one wants to..." I just said
> that I have never felt a need for this :-) Of the times where I've used
> this feature in C/C++, I think every single time has been simply out of
> diligence rather than because there was any risk of the pointer actually
> being reassigned. A pertinent point to me is that D uses pass-by-value
> so the chance of a reference being silently reassigned "somewhere in the
> program" is typically almost nil. About the only place where this is a
> real risk is with global variables, and since free functions support the
> property syntax, the programmer has a ready option to prevent such a
> reassignment from happening. Besides, free globals are bad programming
> style anyway.
I think "final" is mostly useful in class and struct members.
>>> As for the other two, it seems like #3 is a storage class
>>
>> No, because the value may embed pointers that you want to pass to
>> functions. Sorry for sounding dismissive, but we've been all of these
>> dead alleys for so long, it's all green codes: I can see the damn
>> Matrix now. Blonde, brunette, const, final...
>
> That's fine. You may have been down all these roads before, but I
> haven't. I'm mostly asking to gain a better understanding of some of
> the background.
>
>>> while #2 is an attribute on the variable itself. So #3 implies #2.
>>
>> No. #3 implies #2. If a value is super const, then it can be seen as
>> const. Essentially "const" loses a little of the precision that "super
>> const" has.
>
> I'm confused. I said "so #3 imples #2" and you replied "no, #3 implies
> #2." What does the "no" signify?
Sorry, I misread your sentence as #2 implies #3.
>>> I haven't given this much thought, but is it truly necessary to have
>>> two separate keywords for #2 and #3?
>>
>> It's not! That's what I tried to do all along...
>
> (see below)
>
>>> Is this to aid the compiler in optimizing, or is there a perceived
>>> value here from a user perspective?
>>
>> It will be absolutely essential for the well-definedness of
>> functional-style threads.
>
> Okay, that's what I figured, though this seems to contradict what you
> said above. So in essence, "super const" is actually necessary in some
> situations to indicate to the programmer that the data he is
> manipulating is truly immutable. I almost feel like this feature should
> exist separately from the type mechanism, so there was a way to test for
> this instead.
Then you can't prove correctness statically.
>>> And is it necessary to distinguish all three by separate keywords?
>>
>> It's not necessary :o).
>
> So it sounds like it truly isn't necessary to separately distinguish #2
> and #3 via type qualifiers. Is this correct? I can appreciate the need
> for both, but I very much do not want all of this to become a confusing
> mess when applied to actual code.
Much anything else would become a mess when applied to actual code. I
think we discussed about two dozens of schemes. They all looked great on
paper, at least at first blush. They all did miserably during a test drive.
Andrei
More information about the Digitalmars-d
mailing list