http://d.puremagic.com/issues/show_bug.cgi?id=6519
Don <clugd...@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[CTFE] Problem with inout |Problem with inout and type |and enum type inference |inference of polysemous | |types --- Comment #2 from Don <clugd...@yahoo.com.au> 2011-08-18 00:54:22 PDT --- Here's an example which doesn't involve CTFE at all. inout(int) foo(inout int data) { return 7; } void main() { pragma(msg, typeof(foo(7)).stringof); // ---> inout(int) } The problem may be in expression.c, functionParameters(). If at parameter matches an inout parameter with implicit conversion, the inout stays unresolved. That's necessary to allow things like: foo(A, B)(inout(A) a, inout(B) b) when B is int; it should work when A is immutable, and also when it is mutable. But... array literals are a problem. You can write: int[] a = [1,2,3]; and also immutable(int)[] b = [1,2,3]; In the first case, a sort of implicit .dup gets added. Suppose we define inout(int[]) foo(inout(int[]) x) { return x; } Should the following compile? int[] x = foo([1,2,3]); immutable(int[]) y = foo([1,2,3]); const(int[]) z = foo([1,2,3]); Currently only z compiles. The others say you cannot convert from inout(int[]) to int[]. One solution might be to say that if _all_ inout parameters are polysemous value types, so that the return constness remains ambiguous, a tie-breaking rule is applied to all of the parameters. There are two reasonable options: (a) always mutable. This would mean that x would compile, but z would stop working in existing code. y would continue to be rejected. That is, the type of foo([1,2,3]) would be typeof([1,2,3]). (b) always const. No change to what compiles. This gives more efficient code, since array literals don't need to be duped. A third option would be that the return type propagates to the parameters. Then, x, y, and z would all work, and we'd have perfect forwarding. Implicit conversion of the return type of a call to such a function, would mean implicit conversion of all the ambiguous parameters to such a function. Note that this is recursive: a parameter of an inout function could itself be the return value of another inout function. This would be optimally efficient; there would never be an unnecessary implicit .dup of array literals. It's a bit scary though -- I worry that that there might be unintended consequences of such an idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------