RFC: moving forward with @nogc Phobos

[Andrei Alexandrescu via Digitalmars-d]

On 9/29/14, 1:07 PM, Uranuz wrote:
> 1. As far as I understand allocation and memory management of
> entities like class (Object), dynamic arrays and associative
> arrays is part of language/ runtime. What is proposed here is
> *fix* to standart library. But that allocation and MM happening
> via GC is not *fault* of standart library but is predefined
> behaviour of D lang itself and it's runtime. The standard library
> becomes a `hostage` of runtime library in this situation. Do you
> really sure that we should "fix" standart library in that way?
> For me it looks like implementing struts for standard lib (which
> is not broken yet ;) ) in order to compensate behaviour of
> runtime lib.

The change will be to both the runtime and the standard library.

> 2. Second question is slightly oftopic, but I still want put it
> there. What I dislike about ranges and standart library is that
> it's hard to understand what is the returned value of library
> function. I have some *pedals* (front, popFront) to push and do
> some magic. Of course it was made for purpose of making universal
> algorithms. But the mor I use ranges, *auto* then less I believe
> that I use static-typed language. What is wanted to make code
> clear is having distinct variable declaration with specification
> of it's type. With all of these auto's logic of programme becomes
> unclear, because data structures are unclear. So I came to the
> question: is the memory management or allocation policy
> syntacticaly part of declaration or is it a inner implementation
> detail that should not be shown in decl?

Sadly this is the way things are going (not only in D, but other 
languages such as C++, Haskell, Scala, etc). Type proliferation has 
costs, but also a ton of benefits.

Most often the memory management policy will be part of function 
signatures because it affects data type definitions.

> Should rc and gc string look simillar or not?
>
> string str1 = makeGCString("test");
> string str2 = makeRCString("test");
>
> // --- vs ---
>
> GCString str1 = "test";
> RCString str2 = "test";
>
> // --- or ---
>
> String!GC str1 = "test";
> String!RC str2 = "test";
>
> // --- or even ---
> @gc string str1 = "test";
> @rc string str2 = "test";
>
> As far as I understand currently we will have:
> string str1 = "test";
> RCString str2 = "test";

Per Sean's idea things would go GC.string vs. RC.string, where GC and RC 
are two memory management policies (simple structs defining aliases and 
probably a few primitives).

> So another question is why the same object "string" is
> implemented as different types. Array and struct (class)?

A reference counted string has a different layout than immutable(char)[].

> 3. Should algorithms based on range interface care about
> allocation? Range is about iteration and access to elements but
> not about allocation and memory mangement.

Most don't.

> I would like to have attributes @rc, @gc (or like these) to
> switch MM-policy versus *String!RC* or *RCString* but we cannot
> apply attributes to literal. Passing to allgorithm something like
> this:
>
> find( @rc "test", @rc "t" )
>
> is syntactically incorrect. But we can use this form:
>
> find( RCString("test"), RCString("t") )
>
> But above form is more verbose. As continuation of this question
> I have next question.

If language changes are necessary, we will make language changes. I'm 
trying first to explore solutions within the language.

> 4. How to deal with literals? How to make them ref-counted?

I don't know yet.

> I ask this because even when writing RCString("test")
> syntactically expression "test" is still GC-managed literal. I
> pass GC-managed literal into struct to make it RC-managed. Why
> just not make it RC from the start?
>
> Adding some additional template parameter to algrorithm wil not
> fix this. It is a problem of D itself and it's runtime library.

I understand. The problem is actually worse with array literals, which 
are silently dynamically allocated on the garbage-collected heap:

auto s = "hello"; // at least there's no allocation
auto a = [1, 2, 3]; // dynamic allocation

A language-based solution would change array literal syntax. A 
library-based solution would leave array literals with today's syntax 
and semantics and offer a controlled alternative a la:

auto a = MyMemPolicy.array(1, 2, 3); // cool

> So I assume that std lib is not broken this way and we should not
> try to fix it this way. Thanks for attention.

And thanks for your great points.


Andrei