On 24/08/14 15:14, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> In the "Opportunities for D" thread, Walter again mentioned the topics
> ref counting, GC, uniqueness, and borrowing, from which a lively
> discussion developed [1]. I took this thread as an opportunity to write
> down some ideas about these topics. The result is a rather extensive
> proposal for the implementation of borrowing, and its implementations:
>
> http://wiki.dlang.org/User:Schuetzm/scope

I assume with this proposal it should be safe to do more stack allocations and have the compiler verify references don't escape the scope. Would there be a good idea to and a new function, besides the destructor, that will be called for variables declared as "scope" when they go out of scope.

The problem with destructors are that they can be called both when an object is deleted by the GC and when an object goes of out scope.

-- 
/Jacob Carlborg

On Thursday, 28 August 2014 at 06:52:31 UTC, Jacob Carlborg wrote:
> On 24/08/14 15:14, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> In the "Opportunities for D" thread, Walter again mentioned the topics
>> ref counting, GC, uniqueness, and borrowing, from which a lively
>> discussion developed [1]. I took this thread as an opportunity to write
>> down some ideas about these topics. The result is a rather extensive
>> proposal for the implementation of borrowing, and its implementations:
>>
>> http://wiki.dlang.org/User:Schuetzm/scope
>
> I assume with this proposal it should be safe to do more stack allocations and have the compiler verify references don't escape the scope. Would there be a good idea to and a new function, besides the destructor, that will be called for variables declared as "scope" when they go out of scope.
>
> The problem with destructors are that they can be called both when an object is deleted by the GC and when an object goes of out scope.

I'd rather introduce a special method that is called only by the GC. Cleaning up after an object that goes out of scope has always been the task of the regular destructor, it's undeterministic destruction that needs special treatment.

On 2014-08-28 11:16, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> I'd rather introduce a special method that is called only by the GC.
> Cleaning up after an object that goes out of scope has always been the
> task of the regular destructor, it's undeterministic destruction that
> needs special treatment.

I was think about not breaking code. But introducing a new function that is called by the GC which also calls the regular destructor might work.

-- 
/Jacob Carlborg

On Thursday, 28 August 2014 at 18:53:25 UTC, Jacob Carlborg wrote:
> On 2014-08-28 11:16, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>
>> I'd rather introduce a special method that is called only by the GC.
>> Cleaning up after an object that goes out of scope has always been the
>> task of the regular destructor, it's undeterministic destruction that
>> needs special treatment.
>
> I was think about not breaking code. But introducing a new function that is called by the GC which also calls the regular destructor might work.

The other way round would be safer: A destructor automatically calls as its first step a finalizer (let's use that term for a destructor called by the GC) if present, but a finalizer doesn't call the destructor. Remember that the things that are forbidden in a finalizer are usually fine in normal destructors. By calling the destructor from inside the finalizer, you bring all the problems back that you wanted to get rid of by introducing a special finalizer, right?

And this would be backwards-compatible: There is already today no guarantee that a destructor gets called by the GC, so never calling it doesn't break any valid code, strictly speaking. Then you could place "safe" cleanup actions (like closing a file) into the finalizer, and "unsafe" ones (like removing yourself from a linked list) into the destructor, and you don't need to duplicate the actions from the finalizer in the destructor. The compiler might then even detect unsafe operations in the finalizer and refuse to compile them.

On 28/08/14 21:27, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> The other way round would be safer: A destructor automatically calls as
> its first step a finalizer (let's use that term for a destructor called
> by the GC) if present, but a finalizer doesn't call the destructor.
> Remember that the things that are forbidden in a finalizer are usually
> fine in normal destructors. By calling the destructor from inside the
> finalizer, you bring all the problems back that you wanted to get rid of
> by introducing a special finalizer, right?
>
> And this would be backwards-compatible: There is already today no
> guarantee that a destructor gets called by the GC, so never calling it
> doesn't break any valid code, strictly speaking. Then you could place
> "safe" cleanup actions (like closing a file) into the finalizer, and
> "unsafe" ones (like removing yourself from a linked list) into the
> destructor, and you don't need to duplicate the actions from the
> finalizer in the destructor. The compiler might then even detect unsafe
> operations in the finalizer and refuse to compile them.

Yeah, you're probably right. I got it all backwards.

-- 
/Jacob Carlborg

PING

Now that there are again several GC related topics being discussed, I thought I'd bump this thread.

Would be nice if Walter and/or Andrei could have a look and share there opinions. Is this something worth pursuing further? Are there fundamental objections against it?

On Sunday, 24 August 2014 at 13:14:45 UTC, Marc Schütz wrote:
> In the "Opportunities for D" thread, Walter again mentioned the topics ref counting, GC, uniqueness, and borrowing, from which a lively discussion developed [1]. I took this thread as an opportunity to write down some ideas about these topics. The result is a rather extensive proposal for the implementation of borrowing, and its implementations:
>
> http://wiki.dlang.org/User:Schuetzm/scope
>
> This is not a real DIP, but before I put more work into formalizing it, I'd like to hear some thoughts from the languages gurus here:
>
> * Is this the general direction we want to go? Is it acceptable in general?
> * Is the proposal internally consistent?
> * How big would the effort to implement it be? (I suspect it's a large amount of work, but relatively straightforward.)
>
> [1] http://forum.dlang.org/thread/lphnen$1ml7$1@digitalmars.com

Marc Schütz:

> Now that there are again several GC related topics being discussed, I thought I'd bump this thread.
>
> Would be nice if Walter and/or Andrei could have a look and share there opinions. Is this something worth pursuing further? Are there fundamental objections against it?

At the moment the focus seems to be:
1) C++ interoperability
2) GC (in theory).

Bye,
bearophile

I am in no way a language guru, but here are a few things that bother me in your proposal. Thought I'd share.

1. AFAIK, all current D type modifiers can be safely removed from the topmost level (i.e. it is OK to assign immutable(int[]) to immutable(int)[]), because they currently apply to particular variable, so there's no good reason to impose same restrictions on its copy. Situation seems different with scope: it is absolutely not safe to cast away and it applies to a *value*, not a variable holding it.

This is not only inconsistent, but may also cause trouble with interaction with existing features. For example, what should be std.traits.Unqual!(scope(int*)) ?

2. Consider findSubstring from your examples. What should be typeof(findSubstring("", ""))? Is the following code legal?

	scope(string) a = ..., b = ...;
	...
	typeof(findSubstring("", "")) c = findSubstring(a, b);

This is a bit troublesome, because this is how things like std.range.ElementType work currently, so they may break. For example,
what would be ElementType!ByLineImpl (from the "scope(const...)" section)?

This troubles me the most, because currently return type of a function may depend only on types of its arguments, and there is a lot of templated code written in that assumption. With the current proposal it ALL could break. Maybe there's no way around it if we want a solid lifetime management system, but I think this is definitely a problem to be aware of.

3. I believe it was mentioned before, but shouldn't scope propagate *outwards*? This would not only make perfect sense, since the aggregate obviously "holds the reference" just as well as its member does, it would also make various range-wrappers and alike automatically scope-aware, in that the wrapper would automatically become scoped if the wrapped range is scoped.

11.09.2014 15:58, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" пишет:
> PING
>
> Now that there are again several GC related topics being discussed, I
> thought I'd bump this thread.
>
> Would be nice if Walter and/or Andrei could have a look and share there
> opinions. Is this something worth pursuing further? Are there
> fundamental objections against it?
>
> On Sunday, 24 August 2014 at 13:14:45 UTC, Marc Schütz wrote:
>> In the "Opportunities for D" thread, Walter again mentioned the topics
>> ref counting, GC, uniqueness, and borrowing, from which a lively
>> discussion developed [1]. I took this thread as an opportunity to
>> write down some ideas about these topics. The result is a rather
>> extensive proposal for the implementation of borrowing, and its
>> implementations:
>>
>> http://wiki.dlang.org/User:Schuetzm/scope
>>
>> This is not a real DIP, but before I put more work into formalizing
>> it, I'd like to hear some thoughts from the languages gurus here:
>>
>> * Is this the general direction we want to go? Is it acceptable in
>> general?
>> * Is the proposal internally consistent?
>> * How big would the effort to implement it be? (I suspect it's a large
>> amount of work, but relatively straightforward.)
>>
>> [1] http://forum.dlang.org/thread/lphnen$1ml7$1@digitalmars.com
>

Am Thu, 11 Sep 2014 13:58:38 +0000
schrieb "Marc Schütz" <schuetzm@gmx.net>:

> PING
> 
> Now that there are again several GC related topics being discussed, I thought I'd bump this thread.
> 
> Would be nice if Walter and/or Andrei could have a look and share there opinions. Is this something worth pursuing further? Are there fundamental objections against it?

I just needed this again for a stack based allocator. It would make such idioms safer where you return a pointer into an RAII struct and need to make sure it doesn't outlive the struct. It got me a nasty overwritten stack. I cannot comment on the implementation, just that I have long felt it is missing.

-- 
Marco

On 9/11/14, 7:06 AM, bearophile wrote:
> Marc Schütz:
>
>> Now that there are again several GC related topics being discussed, I
>> thought I'd bump this thread.
>>
>> Would be nice if Walter and/or Andrei could have a look and share
>> there opinions. Is this something worth pursuing further? Are there
>> fundamental objections against it?
>
> At the moment the focus seems to be:
> 1) C++ interoperability
> 2) GC (in theory).

scope is GC-related so looking at it is appropriate. -- Andrei