Since COW is used so much in D, especially with strings, allowing
"abc".dup to be constant-folded would greatly increase the amount of existing code which could be used at compile-time.

Don Clugston Wrote:
> Since COW is used so much in D, especially with strings, allowing "abc".dup to be constant-folded would greatly increase the amount of existing code which could be used at compile-time.

What would the semantics be exactly?

Stewart.

Stewart Gordon wrote:
> Don Clugston Wrote:
>> Since COW is used so much in D, especially with strings, allowing "abc".dup to be constant-folded would greatly increase the amount of existing code which could be used at compile-time.
> 
> What would the semantics be exactly?

Just create a new const with the same value as the first one -- all compile-time consts have value semantics.

ie,
char [] a = "xyz";
char [] b = a.dup;

would be the same as
char [] a = "xyz";
char [] b = "xyz";

Don Clugston Wrote:
<snip>
> Just create a new const with the same value as the first one -- all compile-time consts have value semantics.
> 
> ie,
> char [] a = "xyz";
> char [] b = a.dup;
> 
> would be the same as
> char [] a = "xyz";
> char [] b = "xyz";

So it would behave as though the programmer typed this rather than

    char[] a = "xyz";
    char[] b = a;

?  There doesn't appear to be any difference.  As I try it (both with and without const), the two reference the same copy of the string data either way.

But it's probably not defined.  OTOH you could try defining .dup to force the new constant/variable to reference a new copy; however, there's an ambiguity or two in this definition.  If you're using .dup to define a struct or class member initialiser, should it copy only once, or should every instance of the struct or class contain a new copy?  And what about templates?

Stewart.

Don Clugston wrote:
> Stewart Gordon wrote:
>> Don Clugston Wrote:
>>> Since COW is used so much in D, especially with strings, allowing "abc".dup to be constant-folded would greatly increase the amount of existing code which could be used at compile-time.
>>
>> What would the semantics be exactly?
> 
> Just create a new const with the same value as the first one -- all compile-time consts have value semantics.
> 
> ie,
> char [] a = "xyz";
> char [] b = a.dup;
> 
> would be the same as
> char [] a = "xyz";
> char [] b = "xyz";

I see no problem with allowing this in compile-time functions. However, I can't think of any situation in which this would actually be useful. Since compile-time functions aren't allowed to use non-const arrays, they aren't allowed to modify elements of any arrays they have access to, right? So why would they need .dup?

Reply to Stewart,

> Don Clugston Wrote:
> <snip>
>> Just create a new const with the same value as the first one -- all
>> compile-time consts have value semantics.
>> 
>> ie,
>> char [] a = "xyz";
>> char [] b = a.dup;
>> would be the same as
>> char [] a = "xyz";
>> char [] b = "xyz";
> So it would behave as though the programmer typed this rather than
> 
> char[] a = "xyz";
> char[] b = a;
> ?  There doesn't appear to be any difference.  As I try it (both with
> and without const), the two reference the same copy of the string data
> either way.
> 
> But it's probably not defined.  OTOH you could try defining .dup to
> force the new constant/variable to reference a new copy; however,
> there's an ambiguity or two in this definition.  If you're using .dup
> to define a struct or class member initialiser, should it copy only
> once, or should every instance of the struct or class contain a new
> copy?  And what about templates?
> 
> Stewart.
> 

Might the issue be that some function would need the .dup at run time but can otherwise be used at compile time?

Frits van Bommel wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
>>> Don Clugston Wrote:
>>>> Since COW is used so much in D, especially with strings, allowing "abc".dup to be constant-folded would greatly increase the amount of existing code which could be used at compile-time.
>>>
>>> What would the semantics be exactly?
>>
>> Just create a new const with the same value as the first one -- all compile-time consts have value semantics.
>>
>> ie,
>> char [] a = "xyz";
>> char [] b = a.dup;
>>
>> would be the same as
>> char [] a = "xyz";
>> char [] b = "xyz";
> 
> I see no problem with allowing this in compile-time functions. However, I can't think of any situation in which this would actually be useful. Since compile-time functions aren't allowed to use non-const arrays, they aren't allowed to modify elements of any arrays they have access to, right? So why would they need .dup?

Yes, .dup is useless at compile time. But sometimes you have runtime code that contains things like:

char [] s;
:
return s.dup;

With .dup allowable, that existing code can be used at compile time.