[Dlang-study] [rcstring] Defining rcstring

[Andrei Alexandrescu]

On 02/02/2016 11:46 PM, Михаил Страшун wrote:
> Not sure what you mean about "no need to return them by reference"
> though. Does that apply only to byX ranges or you want to make the whole
> string effectively unmodifiable? In other words, how the idiom of
> mutable reusable buffer will look like?

Characters in a string may be modifiable by means of opAssign, 
opOpAssign etc.

> When it comes to encoding, there is also issue of how lacking is current
> support of non-UTF encodings in Phobos.

D uses UTF for strings. Vivid anecdotes aside, we really can't be 
everything to everyone. Your friend could have written a translator to 
UTF in a few lines. The DNA optimization points at performance bugs in 
phobos that far as I know have been fixed or are fixable by rote. I 
think this non-UTF requirement would just stretch things too far and 
smacks of solving the wrong problem.

>> * Immutable does not play well with reference counting. I'm of a mind
>> to reject immutable rcstring for now and figure out later how to go
>> about it. Then const rcstring is okay because we always consider const
>> a view on mutable strings (even though they're gone). We'll cast const
>> away when manipulating the refcount.
>
> This one is the toughest in my opinion. Putting aside my own opinion and
> preferences, you should have answers on several points if pursuing this way:
>
> * What are cases for const if one wants to prohibit immutable for a
> given a type?

Const is a non-modifiable view on data that may otherwise be mutable.

> Being a wildcard for mutable/immutable is main idea behind
> const.

No, the "view" aspect is. Const is good for passing things to functions 
that only want to look at them.

> Everything else is just making compiler happy when it forces
> const on you (like `this` pointer within in/out contracts).
> * As a consequence, how will compiler ensure in/out contracts won't
> affect refcounting state for `this` if it becomes legal to cast const
> away and mutate?

I am sorry but I don't understand this question. To the extent I do I do 
not have an answer for the time being.

> * How do you envision efficient cross-thread sharing of rcstring if
> immutability is out of the question?

Initially no sharing will be allowed. Following the initial 
implementation we may add implementation for the "shared" qualifier for 
rcstring.

> * If one can't support immutability for something relatively simple and
> specialized like char array, doesn't it effectively kill the concept or
> immutable containers important for multi-threading?

Back to basics: immutability in D has always been in intent "real" 
immutability. That means the bytes of an immutable object are 
effectively read-only after initialization. Composition implies that all 
bytes of all members of an immutable object are immutable.

The advantage of this is because we can share with minimal barriers 
(only need to make sure data is not shared before initialization has 
finished). The disadvantage is that reference counting is not compatible 
with immutable objects.

We can't deliver two contradictory guarantees at the same time.

> Right now I am of opinion that issues with immutability highlight issues
> of your desired approach to const and should not be discarded that
> easily.

What is my desired approach to const?



Andrei