On Mon, 21 Sep 2009 14:28:09 -0400, Jeremie Pelletier <jerem...@gmail.com>
wrote:
Steven Schveighoffer wrote:
On Mon, 21 Sep 2009 12:23:46 -0400, Jeremie Pelletier
<jerem...@gmail.com> wrote:
'in' means 'const scope' in D2, which is using pass-by-value semantics.
Yes, you are right. I can't see the benefit to it, so I guess my
recommendation is not to ever use in (use const instead).
I disagree, I have different uses for both. I use 'in' when the
reference will not leave the function's scope and const when it does.
Both are immutable views on the data but with different usage semantics.
The different semantics aren't yet implemented in D2 but they are most
useful to determine whether I can, for example, decide whether to send a
slice (to in parameters) or a copy (to const parameters).
Yes, that would be useful if it was enforced. But it's not, so it's not
useful. Unless you trust the compiler in your head :)
I myself stay out of 'ref' and 'out' params since they do not yet
optimize and add quite a lot of overhead making temporary "safe"
copies of the data.
I understand the problem behind not optimizing (inline), but I'm not
sure what you mean by making temporary "safe" copies.
Right now the compiler makes a temporary copy of referenced parameters
on the stack, calls the function with a pointer to the stack copy, and
once the function returns copies the modified temporary back to its
original location. This is quite considerable overhead.
Are you sure this is true? I don't have a d2 compiler right now, but that
sounds like a *huge* step in the wrong direction. D1 does not do this
(tested dmd 1.046).
Also 'scope' params have a meaning, when a delegate parameter is
declared as scope, it allows a closure to use stack storage instead of
the usual heap storage.
yes, but in the context of an 'in' parameter, most of the time you are
not passing a delegate using in, so scope doesn't mean much there.
The implied 'scope' in 'in' has no effect yet due to a current compiler
bug. You have to explicitly use 'scope' when declaring delegate
parameters. Just like the 'in' vs 'const' have different semantics, 'in'
vs plain 'scope' also have different semantics, which should get fixed
soon.
Yes, I understand the reasoning for scope delegates. My point was that
1. scope for non-delegate parameters is currently a noop
2. const does not make any sense for a delegate.
So arguing that the 'scope' part of 'in' is useful for delegates is
currently a moot point. I guess you could use it as a quicker way to type
scope or const, but it currently doesn't have any different use than just
typing 'scope' (for delegates) or 'const' (for other types).
For example, consider the following:
void Foo(scope delegate() bar) { bar(); }
void Foo2(delegate() bar) { bar(); }
// This method uses stack storage, the implied scope in 'in' should also
work here, but is bugged right now so explicit 'scope' is needed
void Test() {
void Bar() {}
Foo(&Bar);
}
// This method uses heap storage allocated on the GC through
_d_allocmemory
// Notice how the only difference is the 'scope' qualifier of Foo2()
void Test2() {
void Bar() {}
Foo2(&Bar);
}
it's still incomplete. For example, this still allocates a closure on the
heap:
void Bar() {}
auto x = &Bar;
Foo2(x);
I think scope will have to become a type-modifier before it is a complete
solution.
-Steve
