Advertising

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
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings <ah0801...@yahoo.com> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------