July 19, 2022

On Tuesday, 19 July 2022 at 11:00:58 UTC, Hipreme wrote:

>
void setUniform(string uniformName, float[2] vec);
void setUniform(string uniformName, float[3] vec);
void setUniform(string uniformName, float[4] vec);

What happens if I do:

void setupRenderer() @nogc
{
    setUniform("Test", [1, 2]);
    setUniform("Test", [1, 2, 3]);
    setUniform("Test", [1, 2, 3, 4]);
}

Then what it happens?
Error: @nogc function setupRenderer cannot call non-@nogc function renderer.setUniform
Error: @nogc function setupRenderer cannot call non-@nogc function renderer.setUniform
Error: @nogc function setupRenderer cannot call non-@nogc function renderer.setUniform

Note how this is not complaining about the allocation of the array in setupRenderer, it's complaining about setUniform

if setUniform is truly @nogc, properly add the attribute and it will work.

-Steve

July 19, 2022

On Tuesday, 19 July 2022 at 14:04:09 UTC, Quirin Schroll wrote:

>

On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

>

It is misleading, nobody expect this to be GC allocated

It should be equal to:

int[3] arr = [1, 2, 3]

Also why it is GC allocated without requiring new?

Because it’s useful to more people than if it were the opposite. If you find that staticArray too verbose, there’s a single-keystroke way to get pseudo-literals for static arrays:

struct s
{
    static typeof([ Ts.init ][0])[Ts.length] opIndex(Ts...)(auto ref Ts args)
    {
        import std.functional : forward;
        return [ forward!args ];
    }
}

Usage:

void main()
{
    auto empty = s[];
    static assert(is(typeof(empty) == void[0]));

    auto xs = s[1,cast(byte)2,3];
    static assert(is(typeof(xs) == int[3]));

    static struct NoCopy { @disable this(this); }
    auto noCopies = s[NoCopy(), NoCopy()];
}

You’re free to choose any name (except keywords). If you name it stackalloc, it almost looks like taken from C#.

That's not the point..

The difference between:

  • having to write the helper code
  • having to tap into the std
  • having then to import this helper module everywhere
  • having to spend time doing all of the above and carry that file in all my projects

vs

Having to just type stackalloc in the C# example, or _ in some other languages

For something as basic as wanting an inferred fixed static array length

So the language can help me so i don't have to manually count how many elements are in there: auto arr = [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1];

Let's stick with C then, why bother coming up with a better language?

Same with Tagged Union, same with Tuple, same with Nullable

And then it always end up in these endless discussion where one has to constantly remind people this simple fact, and then he feels demotivated, and then withdraw his suggestion, and then gets interested in an other language instead

I'm not a compiler/language developer, i am a language user, little things like that makes the difference

July 19, 2022
On Tuesday, 19 July 2022 at 15:27:57 UTC, ryuukk_ wrote:
> - having to write the helper code
> - having to tap into the std
> - having then to import this helper module everywhere
> - having to spend time doing all of the above and carry that file in all my projects
...
> For something as basic as wanting an inferred fixed static array length

"This is basic" isn't that persuasive, and realistically the solution isn't all of that but just "import the improved template and then use it".

Try these:

- D should be at *least* as convenient as C. Here, it is clearly worse.

- D should retain an advantage of fast compilation. Microbenchmarks easily show that compilation is slower with this template (and results in larger objects--larger with each different length and type of array).

- Do you really want someone to think about a choice like this? Between tediously counting the members of static arrays, or having faster and slimmer builds? Do you want to see a D style guide with such a suggestion in it?
July 19, 2022
On Tuesday, 19 July 2022 at 16:25:03 UTC, jfondren wrote:
> On Tuesday, 19 July 2022 at 15:27:57 UTC, ryuukk_ wrote:
>> - having to write the helper code
>> - having to tap into the std
>> - having then to import this helper module everywhere
>> - having to spend time doing all of the above and carry that file in all my projects
> ...
>> For something as basic as wanting an inferred fixed static array length
>
> "This is basic" isn't that persuasive, and realistically the solution isn't all of that but just "import the improved template and then use it".
>
> Try these:
>
> - D should be at *least* as convenient as C. Here, it is clearly worse.
>
> - D should retain an advantage of fast compilation. Microbenchmarks easily show that compilation is slower with this template (and results in larger objects--larger with each different length and type of array).
>
> - Do you really want someone to think about a choice like this? Between tediously counting the members of static arrays, or having faster and slimmer builds? Do you want to see a D style guide with such a suggestion in it?

Of course, that is why i referred to "template soup" when talking about std.sumtype instead of built in tagged union, in the other post

But i am afraid of pointing out too many things will make me sound too negative and just getting ignored as a result, it is tiring to constantly have to remind everything, so i tend to just rush unfortunately
July 19, 2022
On 7/18/2022 5:13 AM, FeepingCreature wrote:
> Stack allocation without extremely reliable escape analysis is an express ride to corruptiontown. And D does not have extremely reliable escape analysis.

I have submitted open PRs to fix the known problems with it.
July 20, 2022

On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

>

It is misleading, nobody expect this to be GC allocated

It should be equal to:

int[3] arr = [1, 2, 3]

Also why it is GC allocated without requiring new?

It is not always GC allocated. LDC optimizer can remove GC allocation in the following code (unless such optimization is disabled by --disable-gc2stack option):

auto foo()
{
    auto arr = [1, 2, 3];
    return arr[0] + arr[1];
}

https://godbolt.org/z/PWTzEbsW8

July 20, 2022

On Thursday, 14 July 2022 at 15:13:07 UTC, jfondren wrote:

>

Static arrays are still very nice in D, especially their array ops https://dlang.org/spec/arrays.html#array-operations , but they require extra care in more ways than this.

I think the topic is conclude... Criticisms were made and requests received. In the specs, the 12.12 Static Array title says:

>

5.3.Because static arrays are passed to functions by value, a larger array can consume a lot of stack space. Use dynamic arrays instead.

Is it necessary to open a new topic but I need more explanation?

SDB@79

July 20, 2022

On Tuesday, 19 July 2022 at 17:44:29 UTC, Walter Bright wrote:

>

On 7/18/2022 5:13 AM, FeepingCreature wrote:

>

Stack allocation without extremely reliable escape analysis is an express ride to corruptiontown. And D does not have extremely reliable escape analysis.

I have submitted open PRs to fix the known problems with it.

No yes, I know, and I'm not complaining per se. I'm just saying that I, personally, writing for a corporate usecase, would very gladly sacrifice a bit of performance for having confidence that I won't update the compiler and suddenly instead of version 1.0 a service sometimes chooses to report its version as -376789630.0. (To pick an example that was luckily caught in testing.)

New, even false, compiler errors and breaking libraries is completely fine with me. Deprecations: completely fine. Regression miscompilations, however, are the stuff that nightmares are made of. After all, compiler errors annoy developers; with a bit of bad luck, miscompilations annoy customers.

July 23, 2022
Personally, I hope Walter ignores this conversation. I think the current syntactic distinction (presence or absence of a constant length) between static and dynamic arrays is fine and whether a dynamic array is gc-allocated or stack-allocated seems to me to be a compiler optimization issue. I would think that if the compiler can prove that the array doesn't need to be re-allocated due to expansion and if allocation on the stack provides a sufficient lifetime, then it can stack allocate. And we should only care whether dmd does this optimization if it becomes clear that it is important in a lot of use cases, which I doubt.

And regarding that optimization, as hardware has gotten faster and faster (remember the Cray 1 "supercomputer"? It had an 80 mhz clock frequency), we have become more and more guilty of premature optimization. The flip side of that is that is the amount of software we all use daily that is written in languages like Python, Javascript or PHP that are perhaps 2 orders of magnitude slower than D and still provide adequate performance even on our phones.

My opinion.

/Don

July 23, 2022
On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:
> Personally, I hope Walter ignores this conversation. I think the current syntactic distinction (presence or absence of a constant length) between static and dynamic arrays is fine and whether a dynamic array is gc-allocated or stack-allocated seems to me to be a compiler optimization issue. I would think that if the compiler can prove that the array doesn't need to be re-allocated due to expansion  [...]

I think Walter will give us a satisfactory explanation on this.

SDB@79