February 11, 2006 Re: To mutate or not to mutate? | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | "pragma" <pragma_member@pathlink.com> wrote in message news:dskoas$1u2n$1@digitaldaemon.com... > In article <dsk7ch$qmm$1@digitaldaemon.com>, Andrew Fedoniouk says... >> >>> >>> I'd also like to see 'readonly' used in favor of 'const'. A 'writable' >>> modifier >>> would also make template programming easier, due to its symmetry (see >>> below) >>> >>>> // to summarize the above: >>>> >>>> readonly char[] x = "hello world"; >>>> char[] y = cast(char[])x; // Explicit cast from readonly triggers COW >>>> idiom >>>> >>>> y[0..$] = "byebye world"; // legal (working with a copy of x) >>>> x[0..$] = "byebye world"; // illegal (readonly) >>>> >>>> readonly Foobar a = new Foobar(); // illegal: readonly not applicable >>>> to >>>> classes >>>> >>>> // example of using 'writable' (spoof of the ol' const-cast) >>>> template(writable T) const_cast{ >>>> T foobar(readonly T arg){ >>>> return cast(writable)arg; >>>> } >>>> } >>> >> >>Exactly. >> >>Thought about decorations: >> >>In phrase 'readonly char[]' readonly is in fact a part of array type >>modifier ([]) >>so semanticly speaking it should look like 'char readonly []' - >>in short : "char #[]" where '#' means exactly "no-assignment allowed". >> >>Second one about "Explicit cast from readonly triggers COW idiom" >> >>I think that cast should be a cast as it is now. >>dup is already there for that purposes. No? > > I disagree. Readonly means more than "don't assign to me". It should > also > mean, "the data I point to is protected". Sure, you could emulate this > with a > dup but its much cleaner if it is an assumed operation when casting to and > from > readonly*. > > One of the pitfalls of the C's const design was that the best that could > possibly be accomplished by the complier is a static cast. In D, we have > a > garbage collector, so we can automatically enforce the readonly integrity > of the > original const data by performing a copy on cast. This will lead to fewer > errors and make things more failsafe by strictly maintaining readonly and > writable sets of data.** > Ideally yes, but practically you *will* have situations when you need to remove 'constness' from particular readonly data chunk - for example - passing string to some external API and libraries. The whole idea of having readonly arrays/pointers - provide declarative readonliness but keep implementation effective as it is. So instead of: readonly char[] x = "hello world"; char[] y = cast(char[])x; // Explicit cast from readonly triggers COW you will write: readonly char[] x = "hello world"; char[] y = x.dup; // Explicit copy - more clear I believe. > Also, the '#' symbol is reserved by the lexer for compiler directives. > Using it > in the way you suggest makes D's syntax context-sensitive; something that > Walter > has been quite adamant about avoiding. For instance, how would you expect > the > following to compile? > >> char >> #[] foobar; > > IMO, we're better off using no-nonsense modifiers like 'readonly' and > 'writeable' as there's zero room to debate what they actually mean, or how > to > parse them. #* and #[ are single tokens with one character lookahead. D tokenizer is already doing this stuff everywhere. ! and != , < and <=, + and ++, etc. > > * Casting from writable to readonly should also copy as to ensure that > writable > and readable data remain distinct and protected. I'd anticipate that .dup > on > array operations would also inherit the parent's readonly/writable > attributes, > so slices would have to be cast in a similar way. This would ensure that > aliases to readonly data would in themselves be readonly. Runtime and compiler has no way to enforce "data remain distinct and protected" in 100%. The *only* thing what compiler can verify and enforce is that: particular readonly pointer has no operartion "l-value dereferencing" The same apply to readonly arrays. It is a task of the same complexity for compiler as to determine if class Foo has method Bar - not more. Other meanings of const and readonly, is a pitty, but just dreams. > > ** Of course you can always throw caution to the wind by casting through > void*, > which would avoid any copying by not explicitly casting to/from readonly. > Andrew. |
Copyright © 1999-2021 by the D Language Foundation