On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
> > Regardless, we need to better sort out how disabling init works. It was my understanding that the correct way to do it was to do
> > 
> > @disable this();
> > 
> > but apparently that's in dispute (at least, Kenji doesn't seem to think that that's supposed to disable the init property), and it doesn't actually work.
> My argue is simple: If your argument is proper behavior, you never move NonNull object.

What does disabling init have to do with moving? If you're moving an object, it already exists, so it doesn't need to be default initialized.

- Jonathan M Davis

2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
> On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
>> > Regardless, we need to better sort out how disabling init works. It was my understanding that the correct way to do it was to do
>> >
>> > @disable this();
>> >
>> > but apparently that's in dispute (at least, Kenji doesn't seem to think that that's supposed to disable the init property), and it doesn't actually work.
>> My argue is simple: If your argument is proper behavior, you never move NonNull object.
>
> What does disabling init have to do with moving? If you're moving an object, it already exists, so it doesn't need to be default initialized.

Oh, sorry. I've talked about std.algorithm.move, didn't about proper move in language semantics.

Kenji Hara

On Saturday, October 06, 2012 17:06:07 kenji hara wrote:
> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
> > On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
> >> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
> >> > Regardless, we need to better sort out how disabling init works. It was
> >> > my
> >> > understanding that the correct way to do it was to do
> >> > 
> >> > @disable this();
> >> > 
> >> > but apparently that's in dispute (at least, Kenji doesn't seem to think that that's supposed to disable the init property), and it doesn't actually work.
> >> 
> >> My argue is simple: If your argument is proper behavior, you never move NonNull object.
> > 
> > What does disabling init have to do with moving? If you're moving an object, it already exists, so it doesn't need to be default initialized.
> 
> Oh, sorry. I've talked about std.algorithm.move, didn't about proper move in language semantics.

Well, if you disable init, then naturally, anything which requires it won't work, but Andrei's suggestion of having a disabled init still work for static introspection but failing to link if used would catch that. Ideally, it would compile with the static introspection but fail if ever actually used in code, but that's probably too hard to do unfortunately,

- Jonathan M Davis

On Saturday, 6 October 2012 at 08:22:48 UTC, Jonathan M Davis wrote:
> On Saturday, October 06, 2012 17:06:07 kenji hara wrote:
>> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
>> > On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>> >> 2012/10/6 Jonathan M Davis <jmdavisProg@gmx.com>:
>> >> > Regardless, we need to better sort out how disabling init works. It was
>> >> > my
>> >> > understanding that the correct way to do it was to do
>> >> > 
>> >> > @disable this();
>> >> > 
>> >> > but apparently that's in dispute (at least, Kenji doesn't seem to think
>> >> > that that's supposed to disable the init property), and it doesn't
>> >> > actually work.
>> >> 
>> >> My argue is simple: If your argument is proper behavior, you never
>> >> move NonNull object.
>> > 
>> > What does disabling init have to do with moving? If you're moving an
>> > object, it already exists, so it doesn't need to be default initialized.
>> 
>> Oh, sorry. I've talked about std.algorithm.move, didn't about proper
>> move in language semantics.
>
> Well, if you disable init, then naturally, anything which requires it won't
> work, but Andrei's suggestion of having a disabled init still work for static
> introspection but failing to link if used would catch that. Ideally, it would
> compile with the static introspection but fail if ever actually used in code,
> but that's probably too hard to do unfortunately,
>
> - Jonathan M Davis

Well, "instanceOf!T" or "defaultInit" (can) do exactly that.

http://d.puremagic.com/issues/show_bug.cgi?id=8762

On Saturday, 6 October 2012 at 08:28:14 UTC, monarch_dodra wrote:
>
> Well, "instanceOf!T" or "defaultInit" (can) do exactly that.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8762

and "instanceOf!T" doesn't even require T.init at all!

On 10/6/12 4:06 AM, kenji hara wrote:
> 2012/10/6 Jonathan M Davis<jmdavisProg@gmx.com>:
>> On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>>> 2012/10/6 Jonathan M Davis<jmdavisProg@gmx.com>:
>>>> Regardless, we need to better sort out how disabling init works. It was my
>>>> understanding that the correct way to do it was to do
>>>>
>>>> @disable this();
>>>>
>>>> but apparently that's in dispute (at least, Kenji doesn't seem to think
>>>> that that's supposed to disable the init property), and it doesn't
>>>> actually work.
>>> My argue is simple: If your argument is proper behavior, you never
>>> move NonNull object.
>>
>> What does disabling init have to do with moving? If you're moving an object,
>> it already exists, so it doesn't need to be default initialized.
>
> Oh, sorry. I've talked about std.algorithm.move, didn't about proper
> move in language semantics.

I understand. Clearly we have a problem here, and it's tricky (C++ dedicates a fair amount of machinery to it).

I hope we find a simpler solution that disallowing 'T x;' but requiring 'T x = T.init;' for noncopyable objects. It's subtle and difficult to be explained and accepted by newcomers.


Andrei

Le 06/10/2012 08:54, Andrei Alexandrescu a écrit :
> On 10/4/12 7:33 AM, kenji hara wrote:
>> But, I also agree that T.init _sometimes_ *unsafe*.
>> 1) If T has @disable this(), T.init will returns an object which just
>> initialized (== the value itself is never undefined), but not
>> constructed (might be logically invalid object).
>> 2) If T is nested struct, it's frame pointer is always null. It might
>> cause access violation by its member function call.
>>
>> I came up with just now: The use of such unsafe T.init should be
>> allowed only inside @system/@trusted functions.
>> I think it is acceptable limitation.
>>
>> Thoughts?
>
> I think we should go back to the rationale for introducing @disable. The
> most important motivating examples were:
>
> 1. Defining NonNull references
>
> 2. Defining objects that are movable but not copyable
>
> For NonNull references, the existence of an usable T.init would be a
> definite problem because it would suddenly allow the existence of, well,
> a null reference.
>
> For (2) there may also be breakage, although more subtle: uncopyable
> objects are often associated with carefully-guarded resources (e.g.
> mutex locks) and shouldn't exist without special creation.
>
> However, T.init is good to have as an always available value inside
> static code that tests e.g. for capabilities.
>
> (There's been a long-standing similar problem in C++ as well.)
>
> A possible solution is to allow T.init for uncopyable types as an
> unresolved reference: code can use it symbolically, but if it tries to
> actually do things with it at runtime that would be a link-time error.
>
> Another solution would be to define T.init for uncopyable types as
> function that just throws if ever called.
>
> Thoughts?
>
>
> Andrei

.init is needed .

It is what the struct is initialized to before any constructor is called. It may be an invalid state (it is for chars, it is for float, it is for many classes, so why can't it be for structs ?).

That property can be made unsafe to use.

And the compiler must ensure that the struct is initialized. IE:

struct S { @disable this(); }

S s; // OK
foo(s); // Error, s is not initialized.
s = S.init; // Error in @safe code.
foo(s); // OK is @system code.
s = S(); // Error no default constructor (or may be we should allow argument-less constructor).

Le 06/10/2012 15:21, Andrei Alexandrescu a écrit :
> On 10/6/12 4:06 AM, kenji hara wrote:
>> 2012/10/6 Jonathan M Davis<jmdavisProg@gmx.com>:
>>> On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>>>> 2012/10/6 Jonathan M Davis<jmdavisProg@gmx.com>:
>>>>> Regardless, we need to better sort out how disabling init works. It
>>>>> was my
>>>>> understanding that the correct way to do it was to do
>>>>>
>>>>> @disable this();
>>>>>
>>>>> but apparently that's in dispute (at least, Kenji doesn't seem to
>>>>> think
>>>>> that that's supposed to disable the init property), and it doesn't
>>>>> actually work.
>>>> My argue is simple: If your argument is proper behavior, you never
>>>> move NonNull object.
>>>
>>> What does disabling init have to do with moving? If you're moving an
>>> object,
>>> it already exists, so it doesn't need to be default initialized.
>>
>> Oh, sorry. I've talked about std.algorithm.move, didn't about proper
>> move in language semantics.
>
> I understand. Clearly we have a problem here, and it's tricky (C++
> dedicates a fair amount of machinery to it).
>
> I hope we find a simpler solution that disallowing 'T x;' but requiring
> 'T x = T.init;' for noncopyable objects. It's subtle and difficult to be
> explained and accepted by newcomers.
>

I think the compiler should prevent anything using a moved object with @disable this(); before it has been reinitialized.

The compiler will be able to do so if it is able to do it for the first initialization. This isn't more complicated.

It require language support, but no more than what is planned to be implemented anyway.