Robert Jacques Wrote: > On Wed, 29 Apr 2009 08:53:16 -0400, Jason House > <[email protected]> wrote: > > > Robert Jacques Wrote: > > > >> On Tue, 28 Apr 2009 22:12:41 -0400, Daniel Keep > >> <[email protected]> wrote: > >> > >> > > >> > > >> > Andrei Alexandrescu wrote: > >> >> Robert Jacques wrote: > >> >>> Repost in ascii, since utf-8 has been causing some issues. > >> >> > >> >> You should know that posting a long, serious proposal here has less > >> >> chances than the paper -> bottle -> ocean route. A month from now it > >> >> will be forgotten. > >> >> > >> >> Please post in a wiki/blog/webpage. > >> >> > >> >> > >> >> Andrei > >> > > >> > Mostly because this teeny tiny window I read NG postings through > >> doesn't > >> > work for long posts. Plus, Thunderbird doesn't support my > >> > Text-to-speech addon. > >> > > >> > Why not whack it up on the D wiki? > >> > > >> > -- Daniel > >> > >> I just did. :) > >> http://www.prowiki.org/wiki4d/wiki.cgi?OwnershipTypesInD > > > > A link to an overview of GRFJ would be helpful. > > > > The largest issue I see is using scope as any kind of output parameter. > > If I pass a variable in as a ref scope parameter, all type information I > > had must be erased. Any assignment to the head of the scope variable > > could be an incorrect type. For example, a local variable could be > > transformed into a shared variable. (both are scope inside the function > > call). This leads to a cascade of issues I have with the proposal, so > > I'll stop here and get your thoughts. Const scope isnot an issue, but I > > think you aim to handle more than that. > > I've adding a link to Bartosz's GRFJ summary: > http://bartoszmilewski.wordpress.com/2009/03/30/generic-types-for-concurrency/ > > Indeed I intend to handle more than that. The simple answer is that you > can not assign to a scope variable except at declaration. This is scope > rule 2. But this basically prevents output parameters (for exactly the > reasons you mentioned). However, I think you are referencing to the > section on the relaxation of rule two, which allows limited use of output > parameters. This relaxation works by recognizing that the head of scope > variables _must_ exist on the stack. Thus it is safe (with a few > exceptions, see scope rule 6) to swap them. However, assigning to anywhere > off the stack could result in the escape you mentioned and hence is > illegal: > scope Node ln = myLocalNode; > scope Node sn = mySharedNode; > swap(sn,ln); // Okay, were are only swapping the local scope > references that exist on the stack > swap(sn, ln.next); // Error: Cannot take the reference of a scope tail
My gut reaction is that this is too restrictive of a limitation. If someone can't call swap(n.a, n.b) for an arbitrary non-const type n, they will complain.
