[D-runtime] dup attributes?

[Steve Schveighoffer]

----- Original Message ----
> From: Fawzi Mohamed <fawzi at gmx.ch>

> >  http://d.puremagic.com/issues/show_bug.cgi?id=4572
> 
> also tango has this  problem, and I had discussed about it with kris exactly 
>because
> I was worried  about the NO_SCAN bits would be wrong, and so I found ubyte[] a  
>better
> choice.
> But it turns out that (at least in tango) void[] is almost  only used to pass 
>in a buffer where one then
> either reads or writes, and  never resized, so it was almost never a problem.
> So the fact that one can  cast to void[] any array easily it makes it a better 
>choice than  ubyte[].
> 
> Still load and get methods that load a whole file have this  problem, and 
>should allocate their
> buffers as ubyte[] (something read by a  file should *not* contain pointers).

Yes, this is somewhat equivalent to allocating via gc_malloc with the correct 
bits set.

> Not sure if the return type of those  methods should be ubyte[] after all (I 
>lean a bit on yes
> because calling  those methods you will need to cast the void[] away, not cast 
>to void[]
>  as  all other cases), but for sure the internal allocation should be of an  
>ubyte[].

I proposed that you be able to specify the type of the return array via a 
template.  a la std.file.read!ubyte()  And have this statically disable allowing 
types that contain pointers.

The thing about ubyte is that you still need to cast it if ubyte is not what you 
are looking for.  For example, if I expect a file is a utf-8, I want to read it 
as char[].  At least void[] makes no assumptions as to the type.  I like it in 
the pure sense that it does the Right Thing.  But ubyte is probably the more 
practical thing to do.

Thankfully, the template solution makes all this moot since you can simply 
choose the type you want the function to return ;)

> > OK, I'll go about making the  change for dup.
> ok great, it seems that sometime it is possible to reach a  conclusion to a 
>discussion quickly,
> somehow refreshing  :)

hehe :)  Often times, people start "discussing" with the expected conclusion in 
mind, and cannot seem to release that goal.  I try to keep an open mind but I'm 
certainly guilty of explaining how it will be vs. discussing what it should be.

-Steve