Stepping back and looking at constness from another angle.

[Robert Fraser]

I agree, though for a slightly different reason (now that I'm 99% sure of the scope of these changes). I believe const/final/scope is an implementation detail. If a function makes a change to a parameter, it better have a damn good reason, but I expect whomever coded it to know that. A lot of functions I write simply pass object references around without ever actually looking at them, so going six levels up the hierarchy to remove a "const" doesn't appeal to me.

The data doesn't "belong" to the caller or anyone else - when explicit memory management is an issue, it's important to track the "owner" of a memory location, but with garbage collection, I consider the owner of a piece of mutable data to be either the thread it was created in or the thread that currently holds the lock on it. I rarely craft "functions" in the pure mathematical/FP sense, they almost all somehow change state. If the data passed in is changed somewhere in those functions, that's part of how that function works and not something the caller of the function should need to care about in most cases (encapsulating a lot of functionality in structurally sound objects with preconditions/postconditions/invariants helps a lot with this, too).

As far as needing const for large-scale enterprise development, that's utter hogwash. I work on a team of 30-40 developers (okay; they work and I post on the D newsgroup...) on a mature codebase that's probably had over 100 people working on it at some time or another, not mentioning architects, testers, and everyone else. The code is 95% Java, and the rest in Perl, neither language which has a true "const" (Java has final as an implementation detail, but it is not inherited, not transitive, and completely transparent to the caller - i.e. even though the "final" appears in the method definition, it's not part of the method signature).

But, whatever... Walter's post convinced me that this can't be too bad, and hopefully some automated tool will come around that inserts all the "in"s.

That said, I do agree that a little time off from implementing syntax changes, and rather polishing/fixing/adding non-breaking features (reflection, getting rid of forward reference problems, etc.) might do D some good.

All the best,
Fraser

Jarrett Billingsley Wrote:

> I won't lie, I'm not fond of the changes that are being developed.  Now that 
> even my dear, sweet dynamic arrays are having their syntax changed to 
> something like int[new], I figured I'd voice my concerns over it.
> 
> I feel (and this coming from someone who has never truly learned 
> const-correctness, this may not mean much) that all the new const stuff is 
> doing is the same thing that C and C++ do.  Yes, there's more granularity by 
> having const, scope, final, and invariant, and even with a new type of 
> unresizeable array.  But it doesn't feel like a D solution for it.
> 
> As an example, I'll give the C preprocessor.  D didn't inherit it; instead, 
> it stepped back, looked at what it was used for, and designed the most 
> common features into the language, giving them first-class benefits that the 
> CPP can never give.  We have version statements, debug statements, constants 
> and enums, a proper module system, templates, mixins (templates and string), 
> and soon even AST-based macros, all of which blow the CPP out of the water 
> in terms of parsing and features.
> 
> What I'm asking you more seasoned programmers, and those more experienced 
> with const-correctness to do, is to do something similar here.  Step back, 
> and have a look at what constness is for.  What problems does it solve?  Is 
> it necessarily the best way to solve them?  More importantly, what problems 
> does it introduce?  Remember, how the language _looks_ is just as important 
> as the features it has.  After all, what do you want to look at for hours on 
> end each day if you use it at your job?
> 
> I realize that this is late in the game.  I feel like Walter and company 
> have probably already ironed out most of the issues and semantics of the new 
> syntaxes, if not begun to work on them.  I don't want to discredit all 
> they've done at all.  I'm just wondering if it's the best thing for the 
> language.
> 
> (And one final concern is -- what if this is implemented and it's a mess?  A 
> total disaster?  Will Walter just say "sorry guys, we messed up" and take it 
> out?  Or will he, having put in so much time and effort, just say "well 
> you're stuck with it"?  This is a huge feature.  This isn't regex match 
> expressions.  If it gets put into the language, it might not be taken back 
> out.  Especially since this is pretty much _the_ D 2.0 feature.) 
> 
>