http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #10 from timon.g...@gmx.ch 2011-11-10 13:12:29 PST --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > I think this issue is an enhancement. > > > > I strongly disagree. What qualifies it as an enhancement for you? > > It *is* an enhancement, because the common type can just as easily be const, > and the code is still valid. You are asking for an incremental change to how > inout works. > > > I am not saying that this has an enormous priority, but it definitely is a > > bug > > in my eyes. The inout qualifier has failed if there are cases where it could > > work but does not. > > inout's primary focus is transferring the type modifier from the arguments to > the return type. Merging it with a possible external immutable type is > secondary. > > I think inout(const(T)) should resolve as we've discussed. The enhancement is > that immutable(T) and inout(T) should be implicitly castable to > inout(const(T)). See specification of inout: http://d-programming-language.org/function.html "The inout forms a wildcard that stands in for any of mutable, const or immutable. When the function is called, the inout of the return type is changed to whatever the mutable, const, or immutable status of the argument type to the parameter inout was." If inout(const(T)) is parsed as const(T) then the inout does not form a wildcard that can stand for immutable. Contradiction with the language specification. That is a bug. (The specification does not mention any odd special cases!) > Those aspects were not envisioned when the feature was > created, so it works as designed (provided the resolution of inout(const(T)) > > is fixed). s/created/implemented/g You are arguing that DMD is sorta the language specification. It is not. It is a buggy implementation of the language specification and cannot be relied upon. When inout was created there was only the spec. The implementation does not live up to the spec. It does not matter whether or not the issue was known while writing the spec for deciding whether or not a particular implementation implements the specification. As an analogy, consider this function: Tour TSP(Graph g); It's specification says: This function solves the traveling salesman problem in polynomial time. Now comes the poor guy who implements the function: Tour TSP(Graph g){ /* approximate the optimal solution */ } The guy who wrote the specification did not think about the fact that solving TSP in polynomial time is hard. Does that make the approximate solution correct? It does not. Do you agree? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
