const, final, scope function parameters

[Robert Fraser]

Heh; this is quite the interesting thread, though I seem to feel quite different than most of you. I agree most function parameters should be final, but const, and especially scope, just seem very wrong to me to be a default. Maybe it's my Java background, but there are quite a few times I want users to pass in reference to classes that implement a particular interface, or otherwise have some sort of "setter" function for reference types, and having to rewrite all my existing code to somehow allow that just seems like a total waste.

Also, think about all the copying that would have to be made if scope was the default - if I was passing in references to big objects into a collection, I sure as hell wouldn't want a copy of each one made... one of D's advantages is runtime performance. I know that scope could be turned off, but if on was the default, a lot of coders would be more likely to use it, so I'd be much more worried about using someone else's code for a performance-critical task.

In an ideal wold, most functions would indeed be "pure" functions, and if your code has a lot of math going on or something, I can surely see that being the case. However, real code is ugly, and programmers do break rules, usually knowing full-well what we're doing. Reassigning a parameter does occasionally introduce bugs, but it's a useful feature that we've come to accept and use when it should be used, and avoid when it shouldn't be. I'm willing to put "in" on API functions, and functions I expect others to use, but for private methods and internal functions, let me code it how I want, and how I expect it to work, without having to think about what I'm going to do with every parameter.

Eek, on re-reading, that came off a bit combative.... Sorry... I'll retreat to my Virtual-Machine-managed world, and let you systems-level coders duke this one out.

All the best,
Fraser

Walter Bright Wrote:

> It looks like making "const final scope" be the default for function 
> parameters is going to be infeasible. The troubles are that:
> 
> 1) It seems to knock a lot of people for a loop, who will be assuming 
> that an undecorated name would be like an undecorated name for a local 
> or global variable.
> 
> 2) Having to turn off one of the const, final, or scope, introduces the 
> need for some sort of "not" keyword, like mutable, !const, !final, etc. 
> It comes off looking bizarre.
> 
> However, making "in" be equivalent to "const final scope" does seem to 
> work fine, requires no new keywords, and doesn't seem to confuse anyone.
> 
> On a related note, "cstring" has received universal condemnation <g>, so 
>    I'll just have to make "string" work.