const as default for variables

[Zach the Mystic via Digitalmars-d]

On Wednesday, 18 March 2015 at 09:28:35 UTC, deadalnix wrote:
> 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.

So let's go through the steps. Question: What parts of borrowing 
are internally kept track of by the compiler, and what parts are 
made manifest in code? For what is made manifest, how do they 
appear -- as type qualifiers, i.e. `borrowed`, `owned` -- or 
built-in properties, e.g. `fun(x.borrowed)`? For things kept 
hidden, we need to find potential sources of ambiguity, and 
derive reliable algorithms to resolve them.

For me, a big issue is passing variables as arguments, because 
the compiler can't read into the function to see what it does, 
and the function can only tell the caller what the attribute 
system allows. What if the caller takes a wrapped type and you 
only have an unwrapped version, or a different wrapped version, 
to pass to it? Should there be any way to pass it transparently 
(i.e for the called type to automatically receive the passed type 
of the argument), or does it have to be created manually? (I was 
thinking about this when Andrei was trying to create smart 
pointers, and wondered what it would take to create a`Ref!` type 
to entirely replace the `ref` storage class.) This may or may not 
be related to a fully effective ownership system.

> 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.

I guess this will most often be accomplished with `alias this` 
when passing to an argument? I guess what you're suggesting is 
that if a function may delete a reference, you can detect this 
because it accepts only a fully RC'd type rather than the 
unwrapped version.

> Solid core constructs are much better that attribute 
> proliferation.

I totally agree, but at this point, we must figure out precisely 
which constructs to ask for, and then convince everyone else of 
their worth.

How did you become convinced of the value of built-in ownership? 
Is there a good article you could point me to? Secondly, what do 
you suggest it would look like in D? Type qualifiers, a storage 
class, function/parameter attributes? How much just takes place 
invisibly to the programmer?