I had to write this recently

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

While not that bad, it's annoying, why can't we do like like: A a = {}?

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

It is much easier to read, i do not use constructors or RAII, and i feel like i'm being penalized because i want to keep things simple

Could it be allowed for cases where there are no constructors? i don't know the rules about them, but if one is automatically generated, maybe check for @disabled

Maybe it could be a syntax sugar for state.buffer_list = state.buffer_list.init

Even though i also hate .init because just like destroy they are already used in druntime and therefore i can't use them myself.. i hate rules like that

Quality of life for people who only live with structs, please!

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

Simple enough to write a utility function that does this:

void reset(T)(ref T obj)
{
    obj = typeof(obj).init;
}

Now you can write reset(state.buffer_list) (or state.buffer_list.reset if you prefer). No need to repeat yourself.

On Friday, 1 July 2022 at 15:55:50 UTC, Paul Backus wrote:

void reset(T)(ref T obj)
{
    obj = typeof(obj).init;
}

We have to stop with utility function to solve annoyances like this

I'd use an other language if i have to keep writing utility functions and templates all over the place and keep importing ton of modules because the language refuses to evolve paste the 80's

On Friday, 1 July 2022 at 17:33:55 UTC, ryuukk_ wrote:

void reset(T)(ref T obj)
{
    obj = typeof(obj).init;
}

A a;
a = new();

Even C# added that recently: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new

On Friday, 1 July 2022 at 17:33:55 UTC, ryuukk_ wrote:

What's the problem with utility functions? You would prefer it if any time something annoys someone, we add an entire new language feature for it? Surely you can understand why that approach to language development is not sustainable.

If your objection is "I shouldn't have to write this myself; it should be available out of the box," then I encourage you to make a PR submitting it to the standard library. If it's useful to you, there's a good chance it will be useful to others too.

On Friday, 1 July 2022 at 18:02:59 UTC, Paul Backus wrote:

I'm not a language developer, i write games, so the only thing i can do is write games and suggest language improvements

Of course i can write the template, of course i could write a function in the struct

If i came to write the thread is to talk about the feature idea, not what function i can write

Suggesting me to write a function is implying i didn't think about it beforehand, wich is a little bit rude, i got the same kind of answers about the .Enum, wich is unfortunate that people can't focus on talking about the feature instead of telling people to do what they were already doing and to not bother trying

I'd have got the information why the feature wasn't already in place, why it is not possible, or what it would take to have the feature, pros/cons and that kind of things

If for every feature suggestion i post here, i am telling to write a function or template instead, then where can i talk about language features propositions?

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 = {};
    }

Are you suggesting that D should copy the modern C++ uniform initialization? That's one thing I don't like with C++ because it is very ugly.

D also don't need it because D has default initialization as standard. C++ added the uniform initialization (among other things) in order to create a syntax where variables are properly initialized. D got this right from the beginning.

In D the .init property is usually fine for most cases.

On Friday, 1 July 2022 at 18:21:01 UTC, ryuukk_ wrote:

I can't read your mind, so I don't know what you thought about beforehand or what you wrote this thread to talk about. I only know what you actually wrote in your post.

I gave a detailed response to the enum proposal the first time it came up, back in December.

This proposal has essentially the same issues as that one, which is that the expression {} would be ambiguous in many contexts. For example:

struct A {}
struct B {}

void f(A) {}
void f(B) {}

f({}); // ambiguous

void g(A) {}
void g(int) {}

g({}); // not ambiguous, but potentially confusing

void h(A, B) {}

h({}, {}); // not ambiguous, but potentially confusing

The obvious solution is to make ambiguous usage a compile-time error. However, even if you do that, there are still the unambiguous-but-confusing cases to deal with.

Another solution is to narrow the scope of the proposal, and just make = {} a special-case syntax for assignment, without allowing the use of {} anywhere else. The problem with this proposal is that you can get exactly the same result using the utility function, so the benefits are probably not high enough to outweigh the fixed costs of adding a new language feature.

struct A {}
struct B {}

void f(A) {}
void f(B) {}

f({}); // ambiguous

Error: function overload found, ambiguous, please be explicit

void g(A) {}
void g(int) {}

g({}); // not ambiguous, but potentially confusing

Error: function overload found, ambiguous, please be explicit

void h(A, B) {}

h({}, {}); // not ambiguous, but potentially confusing

I do not see any confusions here

Ok we thought of the same about the error, that is nice to read, i still believe the confusion is over estimated

stuff(byte, int);
stuff(1, 1215145415);

Why it's not a confusion here?, we don't do things like this:

stuff(byte(1), int(1215145415));

If compile error for ambiguous i don't think limiting it to just that is right, it'd make things inconsistent imo

On Friday, 1 July 2022 at 18:54:24 UTC, IGotD- wrote:

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

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

I am not suggesting to copy C++, i had to write that code and i thought what if we could shorten this and reuse what we do for A a = {};

That's exactly why i came up with that proposal, because in some case, things can become very verbose, what if it was a super long template?

Is that syntax not good? maybe #init @init?