On Thursday, October 24, 2013 21:07:16 deadalnix wrote:
> 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.

Then what do you mean by valid?

- Jonathan M Davis

On Thursday, 24 October 2013 at 20:04:38 UTC, Jonathan M Davis wrote:
> On Thursday, October 24, 2013 21:07:16 deadalnix wrote:
>> 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.
>
> Then what do you mean by valid?
>

Code operating on the struct must handle that case. It is a valid state for the struct to be in.

On Friday, October 25, 2013 00:06:52 deadalnix wrote:
> On Thursday, 24 October 2013 at 20:04:38 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, October 24, 2013 21:07:16 deadalnix wrote:
> >> 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.
> > 
> > Then what do you mean by valid?
> 
> Code operating on the struct must handle that case. It is a valid state for the struct to be in.

As in all the functions will work on it without blowing up (e.g. segfault due to a null pointer)? That's definitely desirable, but it's definitely not required by the spec, and there are times that it can't be done without adding overhead to the struct in general.

For instance, SysTime.init will blow up on many of its function calls due to a null TimeZone. The only way that I could make that not blow up would be to put a lot of null checks in the code and then give the TimeZone a default value. The alternative is to do what I've done and make it so that you have to assign it a new value (or assign it a TimeZone) if you want to actually use it. Sometimes, that might be annoying, but no one has ever even reported it as a bug, and SysTime.init isn't a particularly useful value anyway, even if it had a valid TimeZone (since it's midnight January 1st, 1 A.D.). I could disable the init value, but that would make SysTime useless in a bunch of settings where it currently works just fine so long as you assign it a real value later.

I agree that ideally Foo.init wouldn't do things like segfault if you used it, but that's not really possible with all types, and IMHO not having an init is far worse than having a bad one in most cases, since there are so many things than need an init value but don't necessarily call any functions on it (e.g. allocating dynamic arrays). Regardless, the language spec makes no requirements that Foo.init do anything useful. It's basically just a default state that the compiler/runtime can assign to stuff when it needs a default value. It doesn't have to actually work, just be a consistent set of bits that don't include any pointers or references which refer to invalid memory.

- Jonathan M Davis

On Wednesday, 23 October 2013 at 15:19:46 UTC, Namespace wrote:
>> 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

What if D would support variable-sized stack-allocated arrays through syntax sugar?
----
int n = 128;
int[n] arr;
----
would be rewritten with:
----
int n = 128;
int* __tmpptr = Type!int[n];
scope(exit) Type!int.deallocate(__tmpptr);
int[] arr = __tmpptr[0 .. n];
----

Where 'Type' is a struct like that:
----
struct Type(T) {
	static {
		enum Limit = 4096;

		void[Limit] _buffer = void;
		size_t _bufferLength;
	}

	static void deallocate(ref T* ptr) {
		.free(ptr);
		ptr = null;
	}

	static T* opIndex(size_t N) {
		if ((this._bufferLength + N) <= Limit) {
			scope(exit) this._bufferLength += N;

			return cast(T*)(&this._buffer[this._bufferLength]);
		}

		return cast(T*) .malloc(N * T.sizeof);
	}
}
----
which could be placed in std.typecons.

I think this should be easy to implement. What do you think?