On Monday, 22 April 2013 at 12:22:14 UTC, Diggory wrote:
Why not simply make escaping a "ref" pointer an unsafe operation. The compiler should be able to detect this and report it without any changes to the syntax.
In other words, 'scope' would be the default and require no explicit attribute. The first thing about this is the question of how much code it would break. I don't know the answer. Maybe a mockup of this idea could be used to create a sense of how badly it breaks existing code. The second question is how desirable is it as a feature. I think it may be quite desirable to have all refs be 'scope' by default, because the most common case will be the default, that refs will not be assigned to globals. Since there is a difference between the safety of returning by ref and the safety of assigning to heap or global addresses, there may need to be a distinction made between these two types of 'escape'.
This should cover 99% of cases with no extra attributes required and no limitations on what you can do with a "ref" within the function. In the 1% of cases that a pointer needs to be escaped safely you can add an attribute (maybe "heap ref" or something, although perhaps some existing syntax could be used) that requires the input to have been allocated on the heap.
'@noscope ref' has also been suggested, since the reference in question would also need to include static global data.
In the case that a stack variable is passed as a "heap ref" parameter the compiler can automatically promote it where possible, or if that's not possible, such as the variable being marked "scope" (existing meaning) then it should complain.
This is interesting to me. The only drawback I can think of is the aversion people have to introducing code which could secretly allocate, since many people want to avoid the garbage collector. It would only be an issue if the automatic promotion looked so much like a normal function call that it was extraordinarily difficult to distinguish it.
As far as I'm aware the only real purpose for R-value references is to implement move semantics. This could already be done using "ref in" syntax, as that makes no guarantees that the value is not going to be destroyed, only says that the value should be initialised prior to it being passed in. The only change would be to allow passing temporaries as "ref in".
The only existing definition of 'in' is that it means 'const scope', so it already means scope. I don't know if that is a good definition or not. I think that there remains a significant fear in this community of introducing changes which will break existing code. I don't myself know how justified this fear is, but it is nonetheless something to take very seriously when proposing new ideas.
I realise I'm new here
I'm new too. I'm glad to be able to have this discussion with you despite both of our being new. :-)
