www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7318] New: Cannot concatenate arrays of super- and subtype

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318

           Summary: Cannot concatenate arrays of super- and subtype
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timon.gehr gmx.ch



The recent fixes regarding array covariance had some side-effects:

void main(){
    auto a = [new Object()];
    auto b = [new Exception("")];
    auto y = a~b; // error
}

This code should still work, even though Exception[] does not implicitly
convert to Object[] anymore. (the code works if a is declared const)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |INVALID



02:19:55 PST ---
To make it work would require an implicit conversion, and that implicit
conversion is not valid.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



It is valid. Exception implicitly converts to Object. Since the resulting array
from the concatenation is unique, there is no chance mutable aliasing occurs
(which is the only reason covariant arrays are unsound in general).

To further back up my point, this compiles, and it is not a bug:

void main(){
    auto a = [new Object()];
    auto b = [new Exception("")];
    a~=b;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com
           Severity|regression                  |enhancement



12:01:56 PST ---
More general: a ~= b for arrays is valid if element type of b implicitly
converts to element type of a.

This is an addition to the language. A good one, but a net addition. It used to
work because of a related bug. Let's keep this open for now and think more
about it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy yahoo.com



15:05:30 PST ---

 To further back up my point, this compiles, and it is not a bug:
 
 void main(){
     auto a = [new Object()];
     auto b = [new Exception("")];
     a~=b;
 }
It only is not a bug because of the special case of arrays. That is, even though the array function takes two mutable arguments, the compiler can deduce that neither array will be molested (same for concatenation). The same is not true for normal functions, you could not write the append function in user code that accepted a derived array type without applying const/inout to the second argument. I agree it's not a bug, but is an enhancement. It would also be a good brainstorming session to figure out how to employ the same assumptions on normal functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318






 To further back up my point, this compiles, and it is not a bug:
 
 void main(){
     auto a = [new Object()];
     auto b = [new Exception("")];
     a~=b;
 }
It only is not a bug because of the special case of arrays. That is, even though the array function takes two mutable arguments, the compiler can deduce that neither array will be molested (same for concatenation). The same is not true for normal functions, you could not write the append function in user code that accepted a derived array type without applying const/inout to the second argument.
I could use a template to do the job: ref A[] append(A,B)(ref A[] x, B[] y) if(is(B:A)) { foreach(e; y){ x.length++; x[$-1] = e; } return x; } (it is more general than built-in append, but that could be fixed with a better constraint)
 
 I agree it's not a bug, but is an enhancement.  It would also be a good
 brainstorming session to figure out how to employ the same assumptions on
 normal functions.
Actually it is quite simple. If final means head-const, then final(T)[] is covariant. The second argument to append is conceptually final(T)[] as are both arguments to concat. With templates, those semantics can be emulated in user code, therefore the language can be fixed consistently without introducing another qualifier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318




07:43:29 PST ---
 I could use a template to do the job:
 
 ref A[] append(A,B)(ref A[] x, B[] y) if(is(B:A)) {
     foreach(e; y){
         x.length++;
         x[$-1] = e;
     }
     return x;
 }
 
 (it is more general than built-in append, but that could be fixed with a better
 constraint)
This suggests that the compiler should simply translate e1 ~= e2 into .object.append(e1, e2) and let druntime take care of the rest. One up for moving decisions from the compiler to the runtime. In case of compile-time operation, the compiler should continue doing what it now does. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7318




07:50:06 PST ---

 I could use a template to do the job:
 
 ref A[] append(A,B)(ref A[] x, B[] y) if(is(B:A)) {
     foreach(e; y){
         x.length++;
         x[$-1] = e;
     }
     return x;
 }
 
 (it is more general than built-in append, but that could be fixed with a better
 constraint)
This suggests that the compiler should simply translate e1 ~= e2 into .object.append(e1, e2) and let druntime take care of the rest. One up for moving decisions from the compiler to the runtime.
This would also solve the problem, but would possibly generate unnecessary template bloat. However, inlining should take care of that problem. I'm all for the compiler translating things into expressions that can be hooked instead of functions that can be hooked. It makes things much more upgradable/flexible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2012