Request for "cdup". Because some const types just can't be cast to either mutable or immutable.
//----
struct S{int*p;}
void main()
{
const(S)[] s;
s.dup; //Nope
s.idup; //Nope
s.cdup; //I'd like this.
}
//----
Comment #1 by yebblies — 2014-04-03T03:58:26Z
Shouldn't dup just give you const(T)[] when it can't manage T[] ?
Comment #2 by monarchdodra — 2014-04-03T04:09:21Z
(In reply to comment #1)
> Shouldn't dup just give you const(T)[] when it can't manage T[] ?
That would also work for me I guess.
Comment #3 by monarchdodra — 2014-04-13T11:30:14Z
(In reply to monarchdodra from comment #2)
> (In reply to comment #1)
> > Shouldn't dup just give you const(T)[] when it can't manage T[] ?
>
> That would also work for me I guess.
Just to be clear, my need is:
Given a type T (which may be qualified), I need a function that can do this:
//----
T[] output = intput.someDup();
//----
Currently, this is not possible in generic code, even with static ifs to switch between dup/idup.
The current workaround right now, is to use `array` instead. It works, but isn't as efficient for arrays (it's specialized for RA only). That said, I could just improve the implementation for arrays...
Comment #4 by nick — 2014-04-13T11:47:43Z
(In reply to monarchdodra from comment #3)
> Just to be clear, my need is:
> Given a type T (which may be qualified), I need a function that can do this:
>
> //----
> T[] output = intput.someDup();
> //----
You can just use dup:
int[] ma = [1, 2, 3];
immutable(int)[] ia = ma.dup;
I think current dmd can do this because it knows ma.dup is unique, so it can safely convert to immutable.
Comment #5 by bugzilla — 2014-04-13T17:17:15Z
The s.dup should work. Marking this as a bug, not an enhancement.
Note that:
const(int*)[] s;
s.dup;
does work.
Not going to do a .cdup
Comment #6 by monarchdodra — 2014-04-13T17:26:42Z
(In reply to Walter Bright from comment #5)
> The s.dup should work. Marking this as a bug, not an enhancement.
It's NOT a bug!
> Note that:
>
> const(int*)[] s;
> s.dup;
>
> does work.
That's *still* a type where "const(T) : T": "Unqual!(const(int*))" is "const(int)*".
dup simply *can't* work for certain types. For example, something as trivial as classes:
//----
class A{}
void main()
{
const(A)[] a;
a.dup;
}
//----
Error: cannot implicitly convert element type const(A) to mutable in a.dup
//----
> Not going to do a .cdup
Fine. Could we then allow "dup" to return "const(T)[]" for the cases where it can't return a mutable then?
Comment #7 by bugzilla — 2014-04-14T04:40:36Z
(In reply to monarchdodra from comment #6)
> That's *still* a type where "const(T) : T": "Unqual!(const(int*))" is
> "const(int)*".
Ah, you're right.
> > Not going to do a .cdup
>
> Fine.
Because where does it stop? .sdup for shared dup? .csdup for const shared dup? At some point, it starts looking ridiculous.
> Could we then allow "dup" to return "const(T)[]" for the cases where
> it can't return a mutable then?
I suspect that would be considered surprising behavior.
Comment #8 by monarchdodra — 2014-04-14T16:20:35Z
(In reply to Walter Bright from comment #7)
> (In reply to monarchdodra from comment #6)
> > Could we then allow "dup" to return "const(T)[]" for the cases where
> > it can't return a mutable then?
>
> I suspect that would be considered surprising behavior.
I guess it depends on how you consider "dup" to operate. Arguably, it could just be
"duplicates the array. Strips the qualifiers it can, for convenience".
Under such circumstance, it keeps its existing semantics, but is expanded to support more types than before.
Comment #9 by robert.schadek — 2024-12-13T18:19:17Z