http://d.puremagic.com/issues/show_bug.cgi?id=5354
--- Comment #14 from Rob Jacques <[email protected]> 2011-01-23 17:54:37 PST --- (In reply to comment #12) > It's true that there's a danger of accidental conformance to inputRange. But > at > this point the input range troika is about as widespread as toString, so I > don't think that's a major risk. It's not a major risk in _hand-written_ code, but in generic code it's a major risk due to opDispatch. See comment 11. Reading over Nick's suggestions (comment 2), he predicates point 2 on the assumption that programmer intent is unclear in the case of classes, due to inheritance of toString from Object and then argues that structs, which do have clear programmer intent should behave like class for uniformity. However, in D2 it is trivial to determine if a programmer of a class has actually implemented a custom toString routine or not (see the code listing below). Therefore, I'd recommend formatValue to prioritize the use of custom toString routines when they exist. bool hasCustomToStringHelper(T)() { foreach(type; TypeTuple!(T,TransitiveBaseTypeTuple!T) ) { if(is(Unqual!type == Object)) return false; foreach(member;__traits(derivedMembers,type)) { if(member == "toString") return true; } } return false; } template hasCustomToString(T) { static if( __traits(hasMember,T,"toString") ) { static if( is(T==class) ) { enum hasCustomToString = hasCustomToStringHelper!T; } else { // structs, etc enum hasCustomToString = true; } } else { enum hasCustomToString = false; } } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
