www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Syntax sugar for {} with structs

reply ryuukk_ <ryuukk.dev gmail.com> writes:
I had to write this recently


```D
     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 = {}`?


```D
     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 ` disable`d

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!
Jul 01 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

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


Simple enough to write a utility function that does this:

```d
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.
Jul 01 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 1 July 2022 at 15:55:50 UTC, Paul Backus wrote:

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

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


 Simple enough to write a utility function that does this:

 ```d
 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.


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
Jul 01 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 1 July 2022 at 17:33:55 UTC, ryuukk_ wrote:

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

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

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


 Simple enough to write a utility function that does this:

 ```d
 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.


 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


     A a;
     a = new();



https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-new
Jul 01 2022
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 1 July 2022 at 17:33:55 UTC, ryuukk_ wrote:

 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


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.
Jul 01 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 1 July 2022 at 18:02:59 UTC, Paul Backus wrote:

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

 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


 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.


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?
Jul 01 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 1 July 2022 at 18:21:01 UTC, ryuukk_ wrote:

 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 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 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 gave [a detailed response][1] 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:

```d
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.

[1]: 
https://forum.dlang.org/post/zggvaorhdkijuwegmtpz forum.dlang.org
Jul 01 2022
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
 ```d
 struct A {}
 struct B {}

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

 f({}); // ambiguous
 ```



     Error: function overload found, ambiguous, please be explicit


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

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



     Error: function overload found, ambiguous, please be explicit



 ```d
 void h(A, B) {}

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


I do not see any confusions here



 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.


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

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

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

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



 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.


If compile error for ambiguous i don't think limiting it to just 
that is right, it'd make things inconsistent imo
Jul 01 2022
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 1 July 2022 at 19:03:25 UTC, Paul Backus wrote:


 ```d
 struct A {}
 struct B {}

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

 f({}); // ambiguous


Why is this more problematic than e.g.:

```d
void f(int[])
{
}

void f(byte[])
{
}

void main()
{
     f([]); // Nice ambiguity error
}
```
?



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

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

 void h(A, B) {}

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


Same:

```d
void h(A[], B[]);
h([], []);
```
Jul 01 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 1 July 2022 at 20:21:45 UTC, Max Samukha wrote:

 Why is this more problematic than e.g.:

 ```d
 void f(int[])
 {
 }

 void f(byte[])
 {
 }

 void main()
 {
     f([]); // Nice ambiguity error
 }
 ```


It's not. I'd say they're both equally problematic.

Array literals are useful enough in general that we're willing to 
accept this problematic special case in order to have them. It's 
not obvious to me that the proposed `{}` meets the same standard. 
Maybe if the proposal were for some kind of "struct literals", 
rather than just `{}` by itself, it would be more attractive.
Jul 01 2022
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 1 July 2022 at 21:01:43 UTC, Paul Backus wrote:

 On Friday, 1 July 2022 at 20:21:45 UTC, Max Samukha wrote:

 Why is this more problematic than e.g.:

 ```d
 void f(int[])
 {
 }

 void f(byte[])
 {
 }

 void main()
 {
     f([]); // Nice ambiguity error
 }
 ```


 It's not. I'd say they're both equally problematic.


I really don't see what is problematic with this (except for the 
FUD spread by some C++ gurus).


 Array literals are useful enough in general that we're willing 
 to accept this problematic special case in order to have them. 
 It's not obvious to me that the proposed `{}` meets the same 
 standard. Maybe if the proposal were for some kind of "struct 
 literals", rather than just `{}` by itself, it would be more 
 attractive.


'{}' by itself would be bad.
Jul 01 2022
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 1 July 2022 at 21:01:43 UTC, Paul Backus wrote:

 Maybe if the proposal were for some kind of "struct literals", 
 rather than just `{}` by itself, it would be more attractive.


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

Rephrasing the example from the second comment:


```d
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,
});


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,
});
```
Jul 05 2022
parent Nick Treleaven <nick geany.org> writes:
On Tuesday, 5 July 2022 at 17:56:05 UTC, Petar Kirov [ZombineDev] 
wrote:

 ```d
 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,
 });


Looks like this code would benefit more from inferring enum 
member types (as in the recent DIPX thread). Also it would be 
great to have struct literals with named fields as the issue 
requests. Although having to write the struct name is sometimes 
useful for those reading the code later.
Jul 09 2022
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 1 July 2022 at 20:21:45 UTC, Max Samukha wrote:

 On Friday, 1 July 2022 at 19:03:25 UTC, Paul Backus wrote:


 ```d
 struct A {}
 struct B {}

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

 f({}); // ambiguous


 Why is this more problematic than e.g.:

 ```d
 void f(int[])
 {
 }

 void f(byte[])
 {
 }

 void main()
 {
     f([]); // Nice ambiguity error
 }
 ```
 ?


`[]` has type `noreturn[]` [1], so the conversion to other array 
types will work naturally through the type system. `{}` would 
need special casing outside the type system, or a new type 
created just for it. (Assuming `{}` as an empty function literal 
was deprecated).

[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1034.md#the-type-of-the-empty-array-literal
Jul 02 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 2 July 2022 at 11:26:23 UTC, Nick Treleaven wrote:

 `{}` would need special casing outside the type system, or a 
 new type created just for it. (Assuming `{}` as an empty 
 function literal was deprecated).


How it works in C++ is that it is a list for the constructor, so 
if D wants to do this then the compiler should type {} as a 
parameter list.

E.g. in C++ it works like this:

```C++
tuple<int,double,tuple<float,string>> f() {
     return {0,1.0,{3.14f,"hello"}};
}

```

Or

```C++
using A = tuple<int,double,tuple<float,string>>;

void f(A x){}

int main()
{
     f({0,1.0,{3.14f,"hello"}});
}
```

Ambiguities are not a big deal, just prefix with the type:

```C++
f(A{0,1.0,{3.14f,"hello"}});
```
Jul 02 2022
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 2 July 2022 at 13:59:39 UTC, Ola Fosheim Grøstad 
wrote:

 if D wants to do this then the compiler should type {} as a 
 parameter list.


A parameter list of zero parameters?

```d
struct S{}

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

f({}); // which gets called?
```
Jul 02 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 2 July 2022 at 15:00:41 UTC, Nick Treleaven wrote:

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

 if D wants to do this then the compiler should type {} as a 
 parameter list.


 A parameter list of zero parameters?

 ```d
 struct S{}

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

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


It is a parameter list for the constructor of S, so `F(S s)` gets 
called.
Jul 02 2022
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 2 July 2022 at 16:15:13 UTC, Ola Fosheim Grøstad 
wrote:

 ```d
 struct S{}

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

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


 It is a parameter list for the constructor of S, so `F(S s)` 
 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)`.
Jul 02 2022
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 2 July 2022 at 16:37:55 UTC, Nick Treleaven wrote:

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

 ```d
 struct S{}

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

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


 It is a parameter list for the constructor of S, so `F(S s)` 
 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)`.


It could also be ambiguous in the above case.
Jul 02 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 2 July 2022 at 16:42:20 UTC, Stefan Koch wrote:

 It could also be ambiguous in the above case.


In what way? `f()` doesn't take any parameters. An empty list is 
more than nothing.
Jul 02 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 2 July 2022 at 16:37:55 UTC, Nick Treleaven wrote:

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

 ```d
 struct S{}

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

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


 It is a parameter list for the constructor of S, so `F(S s)` 
 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)`.


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.
Jul 06 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

 I had to write this recently


 ```D
     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 = {}`?


 ```D
     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.
Jul 01 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 1 July 2022 at 18:54:24 UTC, IGotD- wrote:

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

 I had to write this recently


 ```D
     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 = {}`?


 ```D
     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.


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


 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.


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`?
Jul 01 2022
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 1 July 2022 at 19:21:28 UTC, ryuukk_ wrote:

 `A a = {};`


that works because it is unambiguous in struct init context.
Whereas `{}` anywhere else is an empty function literal.
That's also the reason why D cannot use `{ }` for tuples.

Now one could make that case that an empty function literal is 
useless and so is one containing a sequence of values, without a 
return statement.

and you could reasonably introduce c++ like braced  value 
sequences to be used as initialization expressions.

As far as I can see that wouldn't clash with existing syntax.
Jul 01 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

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


I also like simple things. But I don't think it should be that 
simple!



 Why it's not a confusion here?, we don't do things like this:
 ```d
    stuff(byte(1), int(1215145415));
 ```d


It already supports something like this:
```d
struct POW(byte n)
{
   int result;

   this(int pow)
   {
     print(int(pow), byte(n));
   }

   void print(int pow, byte num)
   {
     import std.stdio : writefln;
     this.result = num^^pow;
     writefln("%s", result);
   }
   void reset() {}
}

void main()
{
   auto square = POW!127(2); // "16129"
   //square.init; // Error: `POW(0)` has no effect
   square.writefln!"%s"; // POW!cast(byte)127(16129)
}
```

SDB 79
Jul 01 2022
prev sibling next sibling parent Martin B <martin.brzenska googlemail.com> writes:
On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

 It is much easier to read


I have seen this as an argument multiple times. I always imply 
"easy to understand" if I see such argument. Unfortunately, "easy 
to read" often come with "easy to understand" not included. As it 
is in this case.. imo.
Jul 02 2022
prev sibling next sibling parent reply Ogi <ogion.art gmail.com> writes:
On Friday, 1 July 2022 at 11:51:57 UTC, ryuukk_ wrote:

 I had to write this recently


 ```D
     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 = {}`?


 ```D
     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?
Jul 06 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 6 July 2022 at 14:14:09 UTC, Ogi wrote:

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

 I had to write this recently


 ```D
     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 = {}`?


 ```D
     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?


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
Jul 06 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jul 06, 2022 at 03:51:56PM +0000, ryuukk_ via Digitalmars-d wrote:
[...]

 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


https://dlang.org/dstyle.html

Quote from section "Keywords":

	If a name would conflict with a keyword, and it is desirable to
	use the keyword rather than pick a different name, a single
	underscore ‘_’ should be appended to it.

This is just a recommendation, of course. But at least you wouldn't have
to invent new words for your identifiers.


T

-- 
A program should be written to model the concepts of the task it performs
rather than the physical world or a process because this maximizes the
potential for it to be applied to tasks that are conceptually similar and, more
important, to tasks that have not yet been conceived. -- Michael B. Allen
Jul 06 2022
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 6 July 2022 at 16:23:58 UTC, H. S. Teoh wrote:

 On Wed, Jul 06, 2022 at 03:51:56PM +0000, ryuukk_ via 
 Digitalmars-d wrote: [...]

 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


 https://dlang.org/dstyle.html

 Quote from section "Keywords":

 	If a name would conflict with a keyword, and it is desirable to
 	use the keyword rather than pick a different name, a single
 	underscore ‘_’ should be appended to it.

 This is just a recommendation, of course. But at least you 
 wouldn't have to invent new words for your identifiers.


 T


That's not something i like, more care should have been put when 
deciding to name and  put a function in the global scope, i 
shouldn't have to pay for that
Jul 06 2022
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Wednesday, 6 July 2022 at 15:51:56 UTC, ryuukk_ wrote:

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

 ```D
     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?


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


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


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


`object.destroy` is well named, it destroys the data. If you want 
to unallocate the memory, dispose is actually a better name IMO.
Jul 07 2022
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
https://twitter.com/FlohOfWoe/status/1551167966141726720

It's a compelling feature that people **want**

Including the inferred length for static arrays
Jul 24 2022