I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.
Sent from my iPhone On Sep 30, 2010, at 3:50 PM, Sean Kelly <[email protected]> wrote: > Here's the test case: > > auto e = new shared(Exception)("hi"); > writeln(e); > > and the error: > > std/format.d(1293): Error: function object.Throwable.toString () is not > callable using argument types () > > I'm guessing this is because toString() isn't a shared method. > Interestingly, also means that it isn't possible to put a shared class into a > Variant, since it provides a toString method. So I guess it's becoming > pretty important to sort out the qualifiers for Object methods. I'd > considered providing both a shared and unshared toString (and others), but > then child classes defining only one get compile errors about hiding the > method in question. It doesn't seem reasonable to expect people to supply > both, and I don't believe inout works for the hidden "this" parameter, so... > ideas? I don't know that we can provide only a shared version of these > methods because they may reference non-shared static data so I'm at a bit of > a loss for what to do. > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
