.dup of const structs does not work

[dlangBugzillaToGithub]

monarchdodra reported this on 2014-04-03T02:39:36Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=12512

CC List

• Walter Bright (@WalterBright)
• Nick Treleaven (@ntrel)
• yebblies

Description

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.
}
//----

[dlangBugzillaToGithub]

yebblies commented on 2014-04-03T03:58:26Z

Shouldn't dup just give you const(T)[] when it can't manage T[] ?

[dlangBugzillaToGithub]

monarchdodra commented on 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.

[dlangBugzillaToGithub]

monarchdodra commented on 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...

[dlangBugzillaToGithub]

nick (@ntrel) commented on 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.

[dlangBugzillaToGithub]

bugzilla (@WalterBright) commented on 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

[dlangBugzillaToGithub]

monarchdodra commented on 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?

[dlangBugzillaToGithub]

bugzilla (@WalterBright) commented on 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.

[dlangBugzillaToGithub]

monarchdodra commented on 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.