Summary: opOpAssign should be automatically visible for types.
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD

--- Comment #0 from Austin Hastings <> 2010-10-11 05:56:53 
PDT ---
This code:
module scratch;

class S( T ) {
    T contents;

    T opIndexOpAssign( string op )( T value, int index ) {
        return contents.opOpAssign!op( value );

unittest {
    auto s = new S!bool();

    s[ 1 ] |= true;
Produces these diagnostics:
$ dmd -c -unittest  scratch.d
scratch.d(7): Error: no property 'opOpAssign' for type 'bool'
scratch.d(7): Error: no property 'opOpAssign' for type 'bool'
scratch.d(7): Error: __error isn't a template
scratch.d(14): Error: template instance
scratch.S!(bool).S.opIndexOpAssign!("|") error instantiating

Defining the various binary ops as templates is a good idea, because it makes
them manageable as a group. But the whole family of indexOpAssign, indexAssign,
OpAssign, and assign functions will frequently wind up as a nest of snakes.

Being able to define some of these functions in terms of other functions is a
valuable feature. Presently, as in the example above, an attempt to reference
the template version of the |= operator produces an error.

For built-in types, and possibly others, it should be possible to use the
template op*!string syntax to generically invoke an operator, rather than
making an explicit template for |=, where the generic invocation will be
converted into an operator, which will be converted back into the generic
invocation behind the scenes...

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to