18.04.2013 18:21, deadalnix пишет:
> On Thursday, 18 April 2013 at 13:25:32 UTC, Denis Shelomovskij wrote:
>>>  - What is the fundamental problem.
>>
>> When a delegate is created information about it's outer scope is lost
>> instead of being stored in it's ptr.
>>
>
> That doesn't mean anything. No information is stored into a ptr except
> an address in memory.

A joke? Of course I mean "stored into a memory ptr point to".

>
>>>  - Why this fundamental problem is a language issue and not a lib one.
> ...
> I don't care about the cost. You have made no point in 3 pages in favor
> of the change you propose. Not even an invalid point I can disagree on.
>
>> As everything I have written above is known, I still don't understand
>> why you are telling about signal fixing as a main problem as it is
>> just an example of problems that occurs when we throw away outer scope
>> information without any practical reason, IMO.
>
> It is an example of a library interface issue (very real). To propose a
> language change, you must show that this limitation is in fact a symptom
> of a deeper cause, which it at language level (so that must be fixed at
> language level).

Another try to describe the problem:

When I get a delegate, I'd like to use it unless it become invalid.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
> Another try to describe the problem:
>
> When I get a delegate, I'd like to use it unless it become invalid.

How does using an object solve that ?

19.04.2013 11:45, deadalnix пишет:
> On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
>> Another try to describe the problem:
>>
>> When I get a delegate, I'd like to use it unless it become invalid.
>
> How does using an object solve that ?

Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.):
---
T delegate(A) del = ...;
rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed);
---

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:
> 19.04.2013 11:45, deadalnix пишет:
>> On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
>>> Another try to describe the problem:
>>>
>>> When I get a delegate, I'd like to use it unless it become invalid.
>>
>> How does using an object solve that ?
>
> Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.):
> ---
> T delegate(A) del = ...;
> rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed);
> ---

I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object.

24.04.2013 12:47, deadalnix пишет:
> On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote:
>> 19.04.2013 11:45, deadalnix пишет:
>>> On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote:
>>>> Another try to describe the problem:
>>>>
>>>> When I get a delegate, I'd like to use it unless it become invalid.
>>>
>>> How does using an object solve that ?
>>
>> Unless this is a struct-member delegate (which is not often used
>> anyway and can be marked as dangerous e.g.):
>> ---
>> T delegate(A) del = ...;
>> rt_attachDisposeEvent(_d_toObject(del.ptr), &onDelegateDisposed);
>> ---
>
> I still see many possibilities without changing the language. For
> instance, allowing to attach dispose event to something else than an
> object.

Thus making that "something else" almost class but not class and I don't see why not just use class instead of creating a new entity.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij