Jonathan Blow, Programming Language Demo #2:

https://www.youtube.com/watch?v=-UPFH0eWHEI

https://www.reddit.com/r/programming/comments/2oyg5e/jonathan_blow_dec_10_programming_language_demo_2/

------------------

He shows a way to not initialize a struct that has specified values. In D it could be:

struct Vec { float x = 1, y = 5, z = 9; }

auto v = new Vec(void);
auto av = new Vec[10] = void;
auto av2 = new Vec[10] = Vec(0, 0, 0);

------------------

He suggests a way to optionally specify the type of array indexes. In a D-like syntax it could be:

enum N = 10;
float[N : ushort] a1;
float[: ushort] a2;

My point of having this in D is to optionally increase strictness of the array indexes, to avoid some bugs when you handle many arrays.

------------------

He suggests something like a @noinline attribute.

Bye,
bearophile

On 12/11/2014 8:57 AM, bearophile wrote:
> He shows a way to not initialize a struct that has specified values. In D it
> could be:
>
> struct Vec { float x = 1, y = 5, z = 9; }
>
> auto v = new Vec(void);
> auto av = new Vec[10] = void;
> auto av2 = new Vec[10] = Vec(0, 0, 0);

D already does this. It's been said before, Jonathan is reinventing D, piece by piece :-)


> He suggests a way to optionally specify the type of array indexes. In a D-like
> syntax it could be:
>
> enum N = 10;
> float[N : ushort] a1;
> float[: ushort] a2;

I don't see any point to this.


> My point of having this in D is to optionally increase strictness of the array
> indexes, to avoid some bugs when you handle many arrays.

Doesn't make sense to me.


> He suggests something like a @noinline attribute.

It'll go into D in some form. It's an old suggestion.

Walter Bright:

>> struct Vec { float x = 1, y = 5, z = 9; }
>>
>> auto v = new Vec(void);
>> auto av = new Vec[10] = void;
>> auto av2 = new Vec[10] = Vec(0, 0, 0);
>
> D already does this.

D doesn't do that, not even one of those three :-) I'm willing to open one or two ERs later on those things.

At best in Phobos we have a workaround for the second of those three ideas:

auto av = minimallyInitializedArray(Vec, 10);


>> He suggests a way to optionally specify the type of array indexes. In a D-like
>> syntax it could be:
>>
>> enum N = 10;
>> float[N : ushort] a1;
>> float[: ushort] a2;
>
> I don't see any point to this.
>
>
>> My point of having this in D is to optionally increase strictness of the array
>> indexes, to avoid some bugs when you handle many arrays.
>
> Doesn't make sense to me.

I explained the topic here (note this not exactly the same thing discussed by Jonathan Blow:
http://forum.dlang.org/thread/qilkslpfwvkbqlradhit@forum.dlang.org

Bye,
bearophile

Walter Bright:

>> struct Vec { float x = 1, y = 5, z = 9; }
>>
>> auto v = new Vec(void);
>> auto av = new Vec[10] = void;
>> auto av2 = new Vec[10] = Vec(0, 0, 0);
>
> D already does this.

D doesn't do that, not even one of those three :-) I'm willing to
open one or two ERs later on those things.

At best in Phobos we have a workaround for the second of those
three ideas:

auto av = minimallyInitializedArray(Vec, 10);


>> He suggests a way to optionally specify the type of array indexes. In a D-like
>> syntax it could be:
>>
>> enum N = 10;
>> float[N : ushort] a1;
>> float[: ushort] a2;
>
> I don't see any point to this.
>
>
>> My point of having this in D is to optionally increase strictness of the array
>> indexes, to avoid some bugs when you handle many arrays.
>
> Doesn't make sense to me.

I explained the topic here (note this not exactly the same thing
discussed by Jonathan Blow:
http://forum.dlang.org/thread/qilkslpfwvkbqlradhit@forum.dlang.org

Bye,
bearophile

On 12/11/2014 1:49 PM, bearophile wrote:
> Walter Bright:
>
>>> struct Vec { float x = 1, y = 5, z = 9; }
>>>
>>> auto v = new Vec(void);
>>> auto av = new Vec[10] = void;
>>> auto av2 = new Vec[10] = Vec(0, 0, 0);
>>
>> D already does this.
>
> D doesn't do that, not even one of those three :-)

I beg to differ:


struct Vec { float x = 1, y = 5, z = 9; }

void main()
{
  {
    Vec v;
    assert(v.x == 1 && v.y == 5 && v.z == 9);
  }
  {
    auto v = new Vec();
    assert(v.x == 1 && v.y == 5 && v.z == 9);
  }
  {
    auto v = cast(Vec*)malloc(Vec.sizeof * 10)[0..10];
  }
  {
    auto v = new Vec[10];
    v[] = Vec(0,0,0);
    assert(v[1].x == 0 && v[1].y == 0 && v[1].z == 0);
  }
}

On 12/11/2014 1:49 PM, bearophile wrote:
>>> He suggests a way to optionally specify the type of array indexes. In a D-like
>>> syntax it could be:
>>>
>>> enum N = 10;
>>> float[N : ushort] a1;
>>> float[: ushort] a2;
>>
>> I don't see any point to this.
>>
>>
>>> My point of having this in D is to optionally increase strictness of the array
>>> indexes, to avoid some bugs when you handle many arrays.
>>
>> Doesn't make sense to me.
>
> I explained the topic here (note this not exactly the same thing
> discussed by Jonathan Blow:
> http://forum.dlang.org/thread/qilkslpfwvkbqlradhit@forum.dlang.org

I don't see support for the notion of a ushort index.

Walter Bright:

> On 12/11/2014 1:49 PM, bearophile wrote:
>> Walter Bright:
>>
>>>> struct Vec { float x = 1, y = 5, z = 9; }
>>>>
>>>> auto v = new Vec(void);
>>>> auto av = new Vec[10] = void;
>>>> auto av2 = new Vec[10] = Vec(0, 0, 0);
>>>
>>> D already does this.
>>
>> D doesn't do that, not even one of those three :-)
>
> I beg to differ:
>
>
> struct Vec { float x = 1, y = 5, z = 9; }
>
> void main()
> {
>   {
>     Vec v;
>     assert(v.x == 1 && v.y == 5 && v.z == 9);
>   }

This is not relevant in this discussion.


>   {
>     auto v = new Vec();
>     assert(v.x == 1 && v.y == 5 && v.z == 9);
>   }

This misses the point.

This code:
struct Vec { float x = 1, y = 5, z = 9; }
auto v = new Vec(void);

Means having defined a struct with explicitly statically defined fields, and then allocate one of it on the heap without initializing its fields.
It's equivalent to:

auto v = cast(Vec*)malloc(Vec.sizeof);

Also written like this if you have written a little function (missing in Phobos) that makes your code more DRY and hides the cast in a probably @trusted function:

auto v = cMalloc!Vec;

Similar code can be written if you want to use the GC heap.


>   {
>     auto v = cast(Vec*)malloc(Vec.sizeof * 10)[0..10];
>   }

This is right, but in D it's often better to use std.array.uninitializedArray to do that.


>   {
>     auto v = new Vec[10];
>     v[] = Vec(0,0,0);
>     assert(v[1].x == 0 && v[1].y == 0 && v[1].z == 0);
>   }
> }

This causes double initialization of the array, and I can't be sure the optimizer removes the first one (dmd doesn't remove it, and until now ldc2 doesn't remove it).

To solve this problem with Phobos code it can be added another std.array function like:

auto av2 = initializedArray!(Vec[])(10, Vec(0, 0, 0));

Beside constants, initializedArray also should accept a pure function that takes as input the index (this request is in Bugzilla).

So all three patterns can be realized using functions, so there's no need to change the D language to do all three things.

But are some of those patterns common enough to deserve to be supported by the language?

Bye,
bearophile

Walter Bright:

> I don't see support for the notion of a ushort index.

A ushort index is not useful, I agree. That's why I have said my proposal is a little different from Jonathan Blow idea.

My point was to optionally define built-in arrays with a strongly typed indexing (where the strongly typed index can be defined with a better version of Typedef!()), as I've tried to explain in that post.

If you have questions please ask and I'll try to explain again (at worst Monday).

Bye,
bearophile

On 12/12/2014 10:54 AM, bearophile wrote:
> This code:
> struct Vec { float x = 1, y = 5, z = 9; }
> auto v = new Vec(void);
>
> Means having defined a struct with explicitly statically defined fields,
> and then allocate one of it on the heap without initializing its fields.
> It's equivalent to:
>
> auto v = cast(Vec*)malloc(Vec.sizeof);

D is a language with C-like syntax and static typing. It pragmatically combines efficiency, control, and modeling power, with ~~~>safety<~~ and programmer productivity.

Unsafe stuff shouldn't be simple to type and why would you need language support for a 1-liner?

ref T uninitializedAlloc(T)() @system pure nothrow
{
    return *cast(T*)GC.malloc(T.sizeof);
}

The only argument I can see is the asymmetry to
    Vec v = void;

Martin Nowak:

OK, I think that it will be enough to add a Phobos function like this (what's the right Phobos module to put it?) (why isn't this @trusted?) (why isn't this returning a T*?):


> ref T uninitializedAlloc(T)() @system pure nothrow
> {
>     return *cast(T*)GC.malloc(T.sizeof);
> }


Plus these one of two Phobos functions:
https://d.puremagic.com/issues/show_bug.cgi?id=8280

(But the request about optionally strongly typed array indexes is still active).

Bye,
bearophile