http://d.puremagic.com/issues/show_bug.cgi?id=6857
David Piepgrass <qwertie...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qwertie...@gmail.com --- Comment #70 from David Piepgrass <qwertie...@gmail.com> 2012-07-08 14:27:53 PDT --- I must say, I would be entirely opposed to fixing this "bug". As far as I can see, the arguments of Timon and deadalnix have been entirely theoretical, whereas it's not that hard to envision a situation where the user would fully desire and expect the wider contract of B to apply even though the static type is A. Suppose that D did check *only* A's contract when calling into an A (that might be a B). I bet that if contracts were widely and exactingly used, cases where this causes trouble would pop up frequently. The main problem, I think, are low-level "deputies" that provide functionality for higher-level clients. For example, consider a collection that only allows items that match certain constraints, but the constraints are eliminated in B: // BTW I wanted to use an interface here, but I get // "missing body { ... } after in or out" // and then if I add a body, D complains that it is not abstract! class A { abstract void add(Item item) in { assert(item.x > 0); } body {} } class B : A { override void add(Item item) in {} body {} } struct Item { int x; } Now suppose I write a function that helpfully adds a series of items to an A: void addAll(A set, Item[] arr...) { foreach(Item x; arr) set.add(x); } Finally, a client creates a B and tries to add some items to it. That should be okay, since B has no restrictions on the items: B b = new B(); b.addAll(Item(-1), Item(-2), Item(-3)); Very few developers would consider this code to be in error. And if there is an error, where is it? P.S. Besides which, the implementation difficulties mentioned by Walter in comment 58 are really big difficulties, that don't seem worth it for what appears to be a minor behavior tweak. P.P.S. in http://dlang.org/function.html, surely the syntax described in "D-style Variadic Functions" is not the preferred technique since it isn't even mentioned in TDPL book. Ergo, the "Typesafe Variadic Functions" section should be first, and one of the two sections should explain to us why there are two entirely different syntaxes! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------