Update: The approach sketched earlier does not work out because it is
possible for a function to take a parameterized type without the
caller knowing that it does. (For example, a fnT(x: fn(T)), when
given a function fn(int), will call it with the argument given by
reference, since it sees it as
On 9/9/11 9:14 AM, Marijn Haverbeke wrote:
Update: The approach sketched earlier does not work out because it is
possible for a function to take a parameterized type without the
caller knowing that it does. (For example, a fnT(x: fn(T)), when
given a function fn(int), will call it with the
Now that structural types are always passed by reference, we can pass
all values conceptually by alias (i.e., without doing a take/drop on
them). The current alias analysis can be used to insert a refcount
bump or explicit copy on the caller side in those cases where it can't
prove the aliasing is
While this is attractive from the perspective of having the
right defaults, it also makes the semantics of the code at a glance more
subtle.
The semantics are not effected at all -- both with 'structurally
immutable' and with immediate values, it is not observable whether the
parameter was
On 09/07/2011 07:18 AM, Marijn Haverbeke wrote:
While this is attractive from the perspective of having the
right defaults, it also makes the semantics of the code at a glance more
subtle.
The semantics are not effected at all -- both with 'structurally
immutable' and with immediate values, it
These concerns are why I advanced
the suggestion earlier: make no sigil mean immutable alias semantics, but
the compiler may choose to promote to value if the value is immutable and
small, but have an explicit copy sigil mean always copy.
I see. This is what I meant when I said we can
On 11-09-07 07:18 AM, Marijn Haverbeke wrote:
But if you ignore the actual binary calling convention, you can think
of this proposal as passing everything by reference. Immediates will
in fact be passed by value, since this is more efficient, but the
difference is not observable in regular,
A mystery-heuristic that programmers can't depend on is much less
attractive. Users are going to write unsafe code that occasionally observes
the distinction. I don't want to be hiding this.
The only point where I suggested a heuristic was for when to emit
warning for implicit copying. The
