opEquals/opCmp returning other types

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Mar 21 09:44:33 PDT 2012


On Wed, Mar 21, 2012 at 03:29:21PM +0100, Brian Palmer wrote:
> On Wednesday, 21 March 2012 at 11:05:41 UTC, Don Clugston wrote:
> 
> >I don't think this is EVER what you really want.
> >I believe that if you think you want this feature, 100% of the
> >time, what you really want is a syntax tree of the entire
> >expression. That is, either you want ">" to be a comparison, and
> >"+" to be an addition, OR you want a syntax tree.
> 
> Well yes, the whole point is to build up a syntax tree that can be
> manipulated before being outputted as a raw sql string. The operator
> overloading is a convenient way to do that, that has turned out to
> be intuitive and easy for developers to use in many other DSLs. To
> say that's not EVER what you really want seems a bit silly,
> considering all the libraries in other languages that utilize this
> technique.
> 
> That said, if this isn't the D way, it's not the D way, I'm
> certainly not going to try and shoe-horn it in based on undefined
> behavior or something.

The "D way" is to use strings for DSELs which get evaluated at
compile-time, or a custom set of methods that you can build expressions
out of. Operator overloading really should be limited to arithmetic
types (for numerical classes) and built-in operations like array lookups
and stuff.

Trying to shoehorn language-level operators to do something they weren't
intended to do only leads to problems. (C++'s overloading of << and >>
for I/O is a very bad design decision IMO.)


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl


More information about the Digitalmars-d mailing list