const as default for variables

[deadalnix via Digitalmars-d]

On Wednesday, 18 March 2015 at 06:24:38 UTC, Zach the Mystic 
wrote:
> I'm starting to think that refcounting is precisely the 
> opposite of ownership, useful only for when its *impossible* to 
> track ownership easily. Otherwise why would you need a refcount?
>

It is not the language's problem. If the language defines 
ownership, the you can define all kind of RC systems as library 
type by deferring the ownership of things to the RC library.

The good thing about it is that it doesn't limit the library 
solution to be ref counting, but it can be anything else, or any 
refcounting strategy.

Indeed, internally, the RC system have to play unsafe, but as 
long as it has to free, it has to play unsafe anyway. The 
important point is that it can provides a safe interface to the 
outside world.

The inc/dec elision problem is simply a copy optimization 
problem. Framing it as a refcounting problem is the wrong way to 
think about it. You would like to elide copy as much as possible.

The first element for this is borrowing. You can pass borrowed 
things around without needing to have copies.

The general problem of the assignation comes up when something is 
borrowed several time and assigned. const is obviously a 
situation where we can elide when borrowing, but that is not the 
only one.

In that situation, only borrowing the RC wrapper require a copy 
(borrowing the wrapped do not). Note that borrowing the wrapped 
is most likely what you want in the first place in most situation 
(so the code manipulating the borrowed do not need to rely on a 
specific memory management scheme, which allow for versatile 
libraries) so copy elision is what you'll in most situation as 
well.

Solid core constructs are much better that attribute 
proliferation.