const issues and more!

Matti Niemenmaa see_signature at for.real.address
Mon Jan 14 06:03:46 PST 2008


Neil Vice wrote:
>> How about:
>>
>> char[] text = "text".dup;
>>
>> .dup creates a mutable copy. There's also .idup, for an immutable copy, 
>> but I don't know its semantics.
> 
> You are of course correct, however it seems a tad unnecessarily verbose 
> IMHO.

The advantage lies in optimization, as it's (more?) common to not want to modify 
a string literal, but only to output it or a part of it. I don't find it that 
verbose, but I don't think I've ever used it in code other than such examples. :-P

>> char[] foo = "foo";
>> foreach (c; foo)
>> c = 'x';
>> assert (foo == "foo"); // passes
> 
> I had overlooked that. I don't see the utility of having a modifiable local 
> copy however and it strikes me as a litle confusing and error-prone. I would 
> expect that the common case is to want a const reference, which ends up 
> being the most verbose declaration unfortunately.

Yep. A while back ( 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=54361 
) practically everybody wanted to try const by default on function parameters 
(by extension, it should probably apply to foreach as well though I don't think 
it was discussed). We got no response from Walter though and it doesn't seem 
like it'll happen.

Regarding 'most verbose', 'in' should still work for the parameter case, unless 
I've missed something:

void foo(in int n) {
	n = n+1; // error, n is "const scope"
}

"in" used to mean "final const scope": IIRC "final" has been dropped but the 
other two remain. I may be wrong due to not having coded with the new const.

>> If 'ref const' does work it's probably one or the other. DMD has a habit 
>> of accepting contradictory attributes:
> 
> From browsing other posts I get the impression that it is a way of passing 
> structs as readonly refernces, however I would have expected just const to 
> function the same.

That would make sense, but I don't think it's implemented yet. Once again, I may 
be wrong, though.

>> public private protected int x; /+ quiz: what is the protection level of 
>> x? +/
> 
> My guess would be protected but the fact that it compiles seems ridiculous.

I agree, but not all do. Walter, for one, doesn't, and he's the one that counts. 
One thing where it admittedly makes sense is in something like:

public:
/+ lots of declarations +/
private int foo;

The declaration of 'foo' wouldn't be allowed if the above were disallowed, since 
that's the equivalent of writing "public private int foo;".

Although I don't see why writing attributes all together ("public private") 
can't be treated differently from the style of applying the attribute to all 
following declarations ("public: private").

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi



More information about the Digitalmars-d mailing list