D const design rationale
Sean Kelly
sean at f4.ca
Sat Jun 23 20:32:35 PDT 2007
Derek Parnell wrote:
> On Sat, 23 Jun 2007 08:32:36 -0700, Sean Kelly wrote:
>
>> Will 'invariant' help to make my code more optimal?
>
> Yeah ... what he said.
>
> I'm with Sean on these points. There seems to be a false dichotomy being
> peddled here; that optimal run-time performance is mutually exclusive with
> source code that is cheap to write and maintain.
I am coming to feel that Walter's argument may just have been poorly
presented, and that this is actually not the case. But I'll admit some
lingering trepidation about the apparent complexity of the design.
> D is so close to given us both that I constantly scream at the ugly warts
> that is being instilled into this wonderful language.
Same here.
> I agree that the concepts behind 'const' and 'invariant' represent two
> different and valid concepts that need to be catered for. The problem is in
> their proposed implementation. The keywords chosen are a hinderence to D
> source maintenance because they both appear to mean either of these two
> concepts. Sure, they will be learned and distingushed in one's mind over
> time, I've no doubt of that, but that is the problem in itself. Instead,
> why not use different key words that actually reflect the differences in
> the two concepts.
Exactly. I think a lot of the confusion (now and in the future) may
stem from the semantic overlap of these two terms. The best alternative
I've been able to come up with, though, is 'view' in place of 'const'
and 'const' in place of 'invariant'. And I know this suggestion has
been shot down in the past. 'final' seems to fit the use to which it
has been put, however.
> A second issue I have is that by forcing 'const' to be explicitly coded in
> function parameter lists, you are reducing the ability of the compiler to
> help detect bugs.
Isn't this necessary though? Say the function declaration is available
to the compiler but the implementation is not. The compiler needs to
know what kind of data can legally be passed as parameters.
Sean
More information about the Digitalmars-d
mailing list