On Friday, 25 October 2013 at 14:09:55 UTC, Jakob Ovrum wrote:
On Friday, 25 October 2013 at 12:07:30 UTC, Namespace wrote:
On Friday, 25 October 2013 at 11:21:55 UTC, Jakob Ovrum wrote:
On Friday, 25 October 2013 at 10:02:08 UTC, Namespace wrote:
On Friday, 25 October 2013 at 09:51:40 UTC, Maxim Fomin
wrote:
On Friday, 25 October 2013 at 09:37:23 UTC, Namespace wrote:
We would have then the possibility to manage our memory by
ourself. One of D's promises is, that the GC can be
disabled. Yes, it can, but then we have many many things
which do not work. For example built-in arrays.
Not only arrays, but classes, throwables, scope exits, new
operator, nested structs, etc.
Thats right.
But I often use temporary arrays, but I still don't like
them because they are always consume so much GC memory. But
with allocators that would end.
Let us hope that Walter has the right intention and that
Andrei design the allocators for this purpose.
Why does it have to be the opaque druntime dynamic array? Why
can't you use the hypothetical (planned, rather)
std.container.Array that supports custom allocators, or a
type of your own design?
Because Array!int looks a lot more ugly than such a nice thing
as int[].
If the template syntax is too ugly then we've really failed at
designing an extensible development platform. Even so, with
type inference and aliases, the need to write down involved
names is all but eliminated (not that I think Array!int is a
particularly involved name).
Not everything belongs in the core language. Conflating slices
with garbage collected dynamic arrays is a mistake we have to
live with, but let's not make the situation even more
complicated.
I don't get your problem.
And if it is possible to change the allocator for some arrays,
why shouldn't we implement it?
Because it has a significant cost.
Which cost?
The default allocator would stay the GC allocator. So if you
don't want to swap the allocator of your arrays, don't do it.
That's fine as long as you only use the array locally and don't
pass it to any code that depends on infinite lifetime
semantics. It also enables circumvention of SafeD unless some
language rules are changed.
The language cannot protect you from every mistake you can do.
You should know what you do. If you don't, don't use such a
feature. It's very simple.
