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

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).

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

struct Test
{
    int test;
}

struct Data
{
    Test[8] test;
}

void add(Data data)
{
}

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

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

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

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:

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

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

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

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
  );//*/

  // ...

  // ...
  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);
}

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

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

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

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

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

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}] ) );
}

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 `{`

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.

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

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.