On Saturday, 2 July 2022 at 16:15:13 UTC, Ola Fosheim Grøstad wrote:

struct S{}

void f();
void f(S s);

f({}); // which gets called?

So in D we would need a new type for a constructor parameter list. We already have parameter lists which have a type, but we can't use that because it would call f(), not f(S).

On Saturday, 2 July 2022 at 16:37:55 UTC, Nick Treleaven wrote:

struct S{}

void f();
void f(S s);

f({}); // which gets called?

It could also be ambiguous in the above case.

On Saturday, 2 July 2022 at 16:42:20 UTC, Stefan Koch wrote:

In what way? f() doesn't take any parameters. An empty list is more than nothing.

On Friday, 1 July 2022 at 21:01:43 UTC, Paul Backus wrote:

That would be this issue: https://issues.dlang.org/show_bug.cgi?id=15692.

Rephrasing the example from the second comment:

auto img = createImage(device, VkImageCreateInfo {
	imageType: VkImageType.VK_IMAGE_TYPE_2D,
	format: VkFormat.VK_FORMAT_R8G8B8A8_UNORM,
	extent: image.size,
	mipLevels: image.mipLevels,
	arrayLayers: image.layers,
	samples: VkSampleCountFlagBits.VK_SAMPLE_COUNT_1_BIT,
	tiling: VkImageTiling.VK_IMAGE_TILING_LINEAR, //VK_IMAGE_TILING_OPTIMAL,
	usage: VkImageUsageFlagBits.VK_IMAGE_USAGE_TRANSFER_SRC_BIT | VkImageUsageFlagBits.VK_IMAGE_USAGE_SAMPLED_BIT,
	sharingMode: VkSharingMode.VK_SHARING_MODE_EXCLUSIVE,
	initialLayout: VkImageLayout.VK_IMAGE_LAYOUT_PREINITIALIZED,
});

// Or C#-style "target-typed `new`" / C++-style aggregate initialization
auto img = createImage(device, {
	imageType: VkImageType.VK_IMAGE_TYPE_2D,
	format: VkFormat.VK_FORMAT_R8G8B8A8_UNORM,
	extent: image.size,
	mipLevels: image.mipLevels,
	arrayLayers: image.layers,
	samples: VkSampleCountFlagBits.VK_SAMPLE_COUNT_1_BIT,
	tiling: VkImageTiling.VK_IMAGE_TILING_LINEAR, //VK_IMAGE_TILING_OPTIMAL,
	usage: VkImageUsageFlagBits.VK_IMAGE_USAGE_TRANSFER_SRC_BIT | VkImageUsageFlagBits.VK_IMAGE_USAGE_SAMPLED_BIT,
	sharingMode: VkSharingMode.VK_SHARING_MODE_EXCLUSIVE,
	initialLayout: VkImageLayout.VK_IMAGE_LAYOUT_PREINITIALIZED,
});

On Saturday, 2 July 2022 at 16:37:55 UTC, Nick Treleaven wrote:

struct S{}

void f();
void f(S s);

f({}); // which gets called?

So, you have to make a choice, the better choice is to not have implicit conversion and require a splat operator. The other choice is to make {...} unbound and let the use context bind the type. The third choice is to use f({{}}). The forth choice is to introduce proper tuples and type variables and let those represent parameter lists, which might be the best option.

On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

    void reset()
    {
        state.end_index = 0;
        state.buffer_list = SinglyLinkedList!(ubyte[])();
    }

    void reset()
    {
        state.end_index = 0;
        state.buffer_list = {};
    }

Um, what’s wrong with destroy? It resets any variable to initial state (and calls its destructor). Isn’t it what you need?

On Wednesday, 6 July 2022 at 14:14:09 UTC, Ogi wrote:

    void reset()
    {
        state.end_index = 0;
        state.buffer_list = SinglyLinkedList!(ubyte[])();
    }

    void reset()
    {
        state.end_index = 0;
        state.buffer_list = {};
    }

I don't use RAII, destroy does something very specific in my arena allocator

The problem i have with destroy is that it is a global and universal function that accepts anything

It should be either internal, reserved with a prefix, moved to a module, or removed

D likes to steal common words that i can't use in my APIs

debug, version, init, destroy

It forces me to come up with annoying alternatives

dbg, versionn, create, dispose (but i really need destroy)

This is poor design in my opinion

On Wednesday, 6 July 2022 at 15:51:56 UTC, ryuukk_ wrote:

    void reset()
    {
        state.end_index = 0;
        state.buffer_list = {};
    }

Why can't you call object.destroy()?

object.destroy is well named, it destroys the data. If you want to unallocate the memory, dispose is actually a better name IMO.