On 06/25/2012 04:08 PM, Steven Schveighoffer wrote:
...This is quite a long thread, and I didn't read everything, but here is my take on this: 1. The issue is that the context pointer of the delegate, even though it is stored as part of the struct data, is not affected by coloring the containing struct as 'const'. 2. The issue is simply with delegate implicit casting, which the compiler does just about nothing with today. Consider the following struct: struct S { int x; void foo() {++x;} void fooconst() const {} } Now, consider the following function: void callit(void delegate() dg) { dg(); } One of the *really* cool benefits of delegates is that you can pass both foo and fooconst to callit -- callit doesn't have to care what attributes are applied to the delegate's context pointer, it simply calls them. However, consider if we *want* to make sure dg doesn't modify its context pointer, how can we write dg's type? You could do this (if it worked): void callit(void delegate() const dg) { dg(); } What should this mean? In my interpretation, it should mean that only a delegate that uses a const context pointer should be able to be bound to dg. So &foo should *not* be able to be passed to callit.
It depends on what 'const' means. If 'const' means 'this reference cannot be used to change the data', then this is the only valid
interpretation.
If we can implement something like this, I think the problem would be solved. What would happen to your original code? oops would not compile, because you could not automatically convert a delegate to a const delegate (unless it was marked as const). And I think it would be possible to keep the nifty feature of not caring what the context parameter is marked as. -Steve
This is essentially the conclusion reached in the other parts of the discussion as well.
The issue is that implementing delegate context qualifiers correctly requires some changes, eg:
currently 'pure' for function literals means 'cannot access non-immutable free variables', while actually it should mean 'cannot access non-immutable static variables'. Last time I asked, Walter made clear that such a change is not planned.
