October 11, 2010 [Issue 5040] New: opOpAssign should be automatically visible for types. | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=5040 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: nobody@puremagic.com ReportedBy: ah08010-d@yahoo.com --- Comment #0 from Austin Hastings <ah08010-d@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: ------- |
Copyright © 1999-2021 by the D Language Foundation