September 13

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:

>
struct Test
{
    int test;
}

struct Data
{
    Test[8] test;
}

void add(Data data)
{
}

extern(C) void main()
{
    add( Data(test: [ {test: 1}] ) );
}

You are passing a struct literal to add. A struct literal is an expression:
https://dlang.org/spec/struct.html#struct-literal

>

A struct literal consists of the name of the struct followed by a parenthesized named argument list

So [ {test: 1}] is parsed as an array literal (because it is an expression), not an array intializer. {test: 1} in expression context is parsed as an invalid function literal (because there's no semi-colon).

September 13

On Friday, 13 September 2024 at 10:55:11 UTC, Nick Treleaven wrote:

>

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:

>
struct Test
{
    int test;
}

struct Data
{
    Test[8] test;
}

void add(Data data)
{
}

extern(C) void main()
{
    add( Data(test: [ {test: 1}] ) );
}

You are passing a struct literal to add. A struct literal is an expression:
https://dlang.org/spec/struct.html#struct-literal

>

A struct literal consists of the name of the struct followed by a parenthesized named argument list

So [ {test: 1}] is parsed as an array literal (because it is an expression), not an array intializer. {test: 1} in expression context is parsed as an invalid function literal (because there's no semi-colon).

This should be allowed, another DIP idea, if anyone still care about improving the language

October 21
https://x.com/SebAaltonen/status/1848311998376738892/

https://x.com/FlohOfWoe/status/1848357742240518436

https://x.com/SebAaltonen/status/1848336276308554192

https://x.com/FlohOfWoe/status/1848355671554535764

If you want to attract talents, you have to provide them with the tools to be at least as productive and efficient as with C

I read, learn and get inspiration from these kind of people

I get rewarded as a result, relatively fast code (i'm still improving as i learn), ~0.4s clean build, and 300kb WASM file



October 26

On Friday, 13 September 2024 at 14:18:28 UTC, ryuukk_ wrote:

>

This should be allowed, another DIP idea, if anyone still care about improving the language

I care but is there not enough development? I claim that D is a better language than C pluck pluck :)

Isn't the following enough for you?

import std.typecons;

struct Vector3i { uint x, y, z; }

void main()
{
  //Vector3i vector = {z: 3, x: 1, y: 2};/*
  auto vector = Vector3i(
    z: 3,
    x: 1,
    y: 2
  );//*/

  // ...

On Monday, 21 October 2024 at 14:02:20 UTC, ryuukk_ wrote:

>

https://x.com/SebAaltonen/status/1848311998376738892/

I took implemented the code written by the people you modeled without getting lazy:

Kod

Is the following still not enough? Same code:

  // ...
  ResourceMaker rm;
  auto data = new ubyte[vertexSize];

  auto vertexBuffer = rm.createBuffer(
       debugName: "cube",
       byteSize: vertexSize * vertexAmo,
       usage: Usage.vertex,
       memory: Memory.GPU_CPU
  );

  auto texture = rm.createTexture(
       debugName: "lion.png",
       dimensions: Vector3i(256, 256, 1),
       format: Format.RGBA8_SRGB,
       initialData: cast(ubyte[])data[0..dataSize]
  );

  auto uniforms = vertexBuffer;
  auto material = BindGroup(
       debugName: "Car Paint",
       layout: "materialBindingsLayout",
       textures: ["albedo", "normal", "properties"],
       buffers: [tuple!("buffer", "byteOffset")(uniforms, 64)]
  );
}

enum : uint
{
       dataSize = 128,
       vertexSize = 1024,
       vertexAmo = 8,
}

enum Format { RGBA8_SRGB, RGBA16_FLOAT }
enum Usage { vertex, uniform }
enum Memory { CPU, GPU_CPU }

struct BufferDesc
{
       string debugName = null;
       uint byteSize;
       Usage usage = Usage.uniform;
       Memory memory = Memory.CPU;
       ubyte[] initialData;
}

struct BindGroup
{
       string debugName = null;
       string layout;
       string[] textures;
       Tuple!(BufferDesc, "buffer", int, "byteOffset")[] buffers;
}

struct Texture
{
       string debugName = null;
       Vector3i dimensions;
       Format format = Format.RGBA8_SRGB;
       ubyte[] initialData;
}

struct ResourceMaker
{
  auto createBuffer(uint byteSize, string debugName, Memory memory, Usage usage, ubyte[] initialData = [])
    => BufferDesc(debugName, byteSize, usage, memory, initialData);

  auto createTexture(string debugName, Vector3i dimensions, Format format, ubyte[] initialData = [])
    => Texture(debugName, dimensions, format, initialData);
}

SDB@79

October 30

On Saturday, 26 October 2024 at 00:55:36 UTC, Salih Dincer wrote:

>

On Friday, 13 September 2024 at 14:18:28 UTC, ryuukk_ wrote:

>

This should be allowed, another DIP idea, if anyone still care about improving the language

I care but is there not enough development? I claim that D is a better language than C pluck pluck :)

Isn't the following enough for you?

import std.typecons;

struct Vector3i { uint x, y, z; }

void main()
{
  //Vector3i vector = {z: 3, x: 1, y: 2};/*
  auto vector = Vector3i(
    z: 3,
    x: 1,
    y: 2
  );//*/

  // ...

On Monday, 21 October 2024 at 14:02:20 UTC, ryuukk_ wrote:

>

https://x.com/SebAaltonen/status/1848311998376738892/

I took implemented the code written by the people you modeled without getting lazy:

Kod

Is the following still not enough? Same code:

  // ...
  ResourceMaker rm;
  auto data = new ubyte[vertexSize];

  auto vertexBuffer = rm.createBuffer(
       debugName: "cube",
       byteSize: vertexSize * vertexAmo,
       usage: Usage.vertex,
       memory: Memory.GPU_CPU
  );

  auto texture = rm.createTexture(
       debugName: "lion.png",
       dimensions: Vector3i(256, 256, 1),
       format: Format.RGBA8_SRGB,
       initialData: cast(ubyte[])data[0..dataSize]
  );

  auto uniforms = vertexBuffer;
  auto material = BindGroup(
       debugName: "Car Paint",
       layout: "materialBindingsLayout",
       textures: ["albedo", "normal", "properties"],
       buffers: [tuple!("buffer", "byteOffset")(uniforms, 64)]
  );
}

enum : uint
{
       dataSize = 128,
       vertexSize = 1024,
       vertexAmo = 8,
}

enum Format { RGBA8_SRGB, RGBA16_FLOAT }
enum Usage { vertex, uniform }
enum Memory { CPU, GPU_CPU }

struct BufferDesc
{
       string debugName = null;
       uint byteSize;
       Usage usage = Usage.uniform;
       Memory memory = Memory.CPU;
       ubyte[] initialData;
}

struct BindGroup
{
       string debugName = null;
       string layout;
       string[] textures;
       Tuple!(BufferDesc, "buffer", int, "byteOffset")[] buffers;
}

struct Texture
{
       string debugName = null;
       Vector3i dimensions;
       Format format = Format.RGBA8_SRGB;
       ubyte[] initialData;
}

struct ResourceMaker
{
  auto createBuffer(uint byteSize, string debugName, Memory memory, Usage usage, ubyte[] initialData = [])
    => BufferDesc(debugName, byteSize, usage, memory, initialData);

  auto createTexture(string debugName, Vector3i dimensions, Format format, ubyte[] initialData = [])
    => Texture(debugName, dimensions, format, initialData);
}

SDB@79

No this is not the same thing

this is function arguments, it limits what you can do and you quickly reach its limits when you want to initialize a struct that contains a struct

I already made a forum post about it to complain about how stupid this is

I ask for simplicity, i have a struct and i want to construct it, no function, no parameters, just simple struct that i can copy around

D can do it, it just needs to stop limiting people on purpose, again, if it wants to attract the C crowd, it needs to offer better, not worse, otherwise people snub D

October 31
On Wednesday, 30 October 2024 at 17:02:24 UTC, ryuukk_ wrote:
> 
> D can do it, it just needs to stop limiting people on purpose, again, if it wants to attract the C crowd, it needs to offer better, not worse, otherwise people snub D

I don't think like you. Already with ImportC, D has achieved a great superiority. I mean, it's not like you said, because they're coming in droves :) This video was a harbinger of this, and 2 years have passed and the D language has matured a lot. I can't even think about 2 years from now. Wonderful

https://youtu.be/2ImfbGm0fls?si=_IZDi5bxfwLoMNBv

SDB@79
November 01

On Thursday, 31 October 2024 at 06:24:44 UTC, Salih Dincer wrote:

>

On Wednesday, 30 October 2024 at 17:02:24 UTC, ryuukk_ wrote:

>

D can do it, it just needs to stop limiting people on purpose, again, if it wants to attract the C crowd, it needs to offer better, not worse, otherwise people snub D

I don't think like you. Already with ImportC, D has achieved a great superiority. I mean, it's not like you said, because they're coming in droves :) This video was a harbinger of this, and 2 years have passed and the D language has matured a lot. I can't even think about 2 years from now. Wonderful

https://youtu.be/2ImfbGm0fls?si=_IZDi5bxfwLoMNBv

SDB@79

Ok let's try it this way:

struct Other
{
    int a;
}

struct Data
{
    Other other;
}

void pass(Data data)
{
}
void main()
{

    // THIS OK
    Data data = {
        other: { a: 42 }
    };

    // THIS OK
    pass( Data(other: Other(a: 42)));


    // WHY THIS NOT OK??
    // pass( Data { other: {a: 42} } );

    // WHY THIS NOT OK??
    //pass( Data(other: {a: 42}));
}

Why limit for no reason what you can do with D

Why force people to repeat themselves other: Other(a: 42)?

This is the thing D does worse than all of the competition that aim to replace C, even C3 does better... C3...


struct Other
{
    int value;
}

struct Data
{
    Other[] other;
}

fn void pass(Data data)
{
}

fn void main()
{
    pass( { .other = { {.value=42} } } );
}

This builds

This also build:

enum State
{
    IDLE,
    RUN,
    ATTACK,
}


fn void main()
{
    State state = IDLE;
    if (state == RUN) {
        // run
    }
}

D needs to to better

November 01

On Friday, 30 August 2024 at 16:03:27 UTC, ryuukk_ wrote:

>

And in a perfect world:

my_fun( { c: 1 } );

this is perhaps c# syntax that allows ease of typing.

which is good to have for d to be modern language.

but the most urgent is perhaps coroutine,
it is only at first draft.

and we have 3 compiler that is not sharp enough. other language has only ONE that great. IMHO

November 02

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:

>

Today i tried this:



struct Test
{
    int test;
}

struct Data
{
    Test[8] test;
}

void add(Data data)
{
}

extern(C) void main()
{
    add( Data(test: [ {test: 1}] ) );
}

it refuses to compile:

onlineapp.d(19): Error: found `}` when expecting `;` following expression
onlineapp.d(19):        expression: `1`
onlineapp.d(19): Error: found `]` instead of statement
onlineapp.d(21): Error: found `End of File` when expecting `,`
onlineapp.d(19): Error: found `End of File` when expecting `]`
onlineapp.d(21): Error: found `End of File` when expecting `)`
onlineapp.d(21): Error: found `End of File` when expecting `)`
onlineapp.d(21): Error: found `End of File` when expecting `;` following expression
onlineapp.d(19):        expression: `add(Data(test: [()
{
test:
1;
__error__
}
]))`
onlineapp.d(21): Error: matching `}` expected following compound statement, not `End of File`
onlineapp.d(18):        unmatched `{`

D worse than C with these stupid RAII, give me proper way to initialize a struct instead of giving me a broken constructor i'm not even using

The struct static initialiser syntax (using {}) is basically a barebones C-compatibility feature, and it only works when initialising a variable. Stop expecting it to have any sort of type-inference—Walter thinks type-inference is The Devil! It would be nice if we did have type inference, and my suggestion was writing the type name for a constructor wouldn't be required if the type can be inferred from its context (e.g. add(%(test: [%(test: 1)])), but doing this for arrays is very messy because they infer their type from their contents, not from where they're being sent. If we had the aforementioned constructor type inference, then I wouldn't mind even sending the static initialiser syntax to the deprecation graveyard, even though I use it heavily in my libraries because it predates named parameters.

November 02

On Friday, 1 November 2024 at 12:26:25 UTC, ryuukk_ wrote:

>

This is the thing D does worse than all of the competition that aim to replace C

Nope, not even close. That medal has to go to integer promotion.

short x = 127;
short y = x / 2 + 1; //Error: integer promotion screwed you over again!
//ugh take two:
short y = cast(byte)(x / 2 + 1);

Heaven forbid you work with short or byte on a regular basis.