[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5354



--- Comment #14 from Rob Jacques <sandford at jhu.edu> 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: -------