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
