On 09/07/2024 4:48 PM, IchorDev wrote:
> On Tuesday, 9 July 2024 at 03:57:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> It is used quite heavily to mean that the variable isn't used for say foreach statements.
> 
> ‘Used to mean’—I use it for that too, but it’s a convention not a language feature. (Unless it’s undocumented?)

There is nothing special about it, its just a variable called ``_``.

>> We will not be diverging from C's identifiers.
> 
> Fortunately there are plenty of good prefixes that don’t require diverging from C’s identifiers.

Yes, I need to talk to Walter about the member-of-operator ideally at next monthly meeting to unblock my sum type work.

It is a very restrictive subset of this, which may take some convincing as he has some very strong opinions that do impact performance. An expansion can come later to introduce Identifier Type's as described in this thread with expanded use cases.

>> We are in the process of bumping the version from C99 to C23.
>> I can say this on behalf of Walter, due to that bump being something I had to fight for.
> 
> And thank you for doing that!

I'm happy to do it, it should be the only bump we will ever need to do.

On 09/07/2024 8:26 PM, IchorDev wrote:
> On Tuesday, 9 July 2024 at 04:54:54 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Yes, I need to talk to Walter about the member-of-operator ideally at next monthly meeting to unblock my sum type work.
>>
>> It is a very restrictive subset of this, which may take some convincing as he has some very strong opinions that do impact performance. An expansion can come later to introduce Identifier Type's as described in this thread with expanded use cases.
> 
> Ah yes, I’d forgotten all about that!
> Do you think I should attend the meeting?

Up to you, my main focus for this is to get Walter to confirm what level of cost for argument to parameter matching will be acceptable for him.

If I can't get even the most restricted design okayed to continue, all this work is kinda at a dead end.

On 02/08/2024 4:53 AM, Nick Treleaven wrote:
> On Sunday, 7 July 2024 at 19:42:25 UTC, Nick Treleaven wrote:
>> Vladimir's idea of making an identifier expression have its own type
> 
> So identifier literals can be compatible with enum members, as discussed above. One interesting application of identifier literals could be for some of the situations where implicit construction of a user-defined type would be used in C++ - we don't have that in D. It could work by defining a named enum or static member of an aggregate type. E.g. for the struct type below, the `none` enum:
> 
> ```d
> struct Option(T) {
>      enum none = Option!T.init;
> 
>      bool empty = true;
>      T value;
> 
>      this(T v) {
>          empty = false;
>          value = v;
>      }
> }
> 
> void f(Option!int o)
> {
>      import std.stdio;
>      writeln(o);
> }
> void main() {
>      f(Option!int(5));
>      f(:none); // same as `f(Option!int.none)`
> }
> ```
> 
> I'm using `:none` as the syntax for an identifier literal. `typeof(:none)` could match f's argument type of `Option!int`, because `none` is a value member of that type. So `:none` would be equivalent to passing `Option!int.none` there.
> 
> So identifier literals seem more flexible than just selecting an enum member. They would also be useful as an argument to a mixin template instead of a string literal for the name of an identifier symbol to mixin.

Yeah that is more or less what I'm calling the member-of-operator. It is currently waiting on Walter, without his approval no point doing a DIP in development as I know he has strong feelings on it.