> can't you remove the if(this.ptr is null) return; checks everywhere - how should that happen - without exception at creation time

Yes, this is somehow true. Here, the adjusted version.
http://dpaste.dzfl.pl/e4dcc2ea

On Wednesday, 23 October 2013 at 14:54:22 UTC, dennis luehring wrote:
> can't you remove the if(this.ptr is null) return; checks everywhere - how should that happen - without exception at creation time

Struct.init must be a valid state according to D specs, and it is pretty much unavoidable considering we have no default constructor for structs.

23.10.2013 1:05, Lionello Lunesu пишет:
> Careful! Alloca doesn't get cleaned up when used in loops!

And I don't use `alloca`.

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

On Wednesday, October 23, 2013 19:28:27 deadalnix wrote:
> On Wednesday, 23 October 2013 at 14:54:22 UTC, dennis luehring
> 
> wrote:
> > can't you remove the if(this.ptr is null) return; checks everywhere - how should that happen - without exception at creation time
> 
> Struct.init must be a valid state according to D specs, and it is pretty much unavoidable considering we have no default constructor for structs.

And what do you mean by valid? It's perfectly legal to have fields initialized to void so that the init state is effectively garbage. That can cause problems in some scenarios (particularly any case where something assumes that init is useable without calling a function which would make the state valid), but it's legal. And you can disable init if you want to - which also causes its own set of problems, but technically, you don't even have to have an init value (though it can certainly be restrictive if you don't - particularly when arrays get involved).

You also have cases where the struct's init is in a completely valid and yet unusable state. For instance, SysTime.init is useless unless you set its timezone and will segfault if you try and use it (since the timezone is null), but thanks to the limitations of CTFE, you _can't_ have a fully valid SysTime.init (though that's not invalid in the sense that part of the struct is garbage - just that it blows up when you use it).

I don't know why you think that the spec requires that a struct's init value be valid. It just causes issues with some uses of the struct if its init value isn't valid.

- Jonathan M Davis

On Tuesday, 22 October 2013 at 21:05:33 UTC, Lionello Lunesu wrote:
> Careful! Alloca doesn't get cleaned up when used in loops!

scope(exit) works in a loop, so you can automatically clean it up like that.

Destructors are also called on each iteration so RAII is an option.

On 10/23/13, 21:36, Denis Shelomovskij wrote:
> 23.10.2013 1:05, Lionello Lunesu пишет:
>> Careful! Alloca doesn't get cleaned up when used in loops!
>
> And I don't use `alloca`.
>

Ah, indeed. I got your post mixed up with the one using alloca.

'void' initialization means uninitialized. This applies to fields, as well, meaning that the .init value of an aggregate with void initializations will have unreliable values in those locations.

This is why 'void' initializers don't belong in safe code, and reading 'void' initialized data will get you implementation defined data.

On 10/23/13, 23:30, John Colvin wrote:
> On Tuesday, 22 October 2013 at 21:05:33 UTC, Lionello Lunesu wrote:
>> Careful! Alloca doesn't get cleaned up when used in loops!
>
> scope(exit) works in a loop, so you can automatically clean it up like
> that.
>
> Destructors are also called on each iteration so RAII is an option.

You can't clean up alloca'ed memory, AFAIK.

On Wednesday, October 23, 2013 22:40:55 Walter Bright wrote:
> 'void' initialization means uninitialized. This applies to fields, as well, meaning that the .init value of an aggregate with void initializations will have unreliable values in those locations.
> 
> This is why 'void' initializers don't belong in safe code, and reading 'void' initialized data will get you implementation defined data.

Agreed. But there's a significant difference between @system and illegal, and deadalnix was claiming that such init values were illegal per the language spec, which is what I was objecting to.

- Jonathan M Davis


P.S. Please quote at least _some_ of the message when replying. Without that, if the threading gets screwed up, or if someone doesn't use a threaded view, it's a guessing game as to which post you're replying to. Thanks.

On Thursday, 24 October 2013 at 18:22:49 UTC, Jonathan M Davis wrote:
> Agreed. But there's a significant difference between @system and illegal, and
> deadalnix was claiming that such init values were illegal per the language
> spec, which is what I was objecting to.
>
> - Jonathan M Davis
>

I never claimed that. I claimed that the init value, whatever it is, must be considered as valid. This is only loosly coupled with void as init value.