On Sunday, 18 September 2022 at 12:15:17 UTC, Max Samukha wrote:

You can use hex literals behind an high level interface that hides them behind enums/aliases, in this way users won't need to know the position of each bit when they'll use your library.

Also if you need to change the order of two bits for some reason you'll just change 2/3 enums and your code will work anyway. In general it's better to hide constants behind an alias instead of copy them in several places.

On Sunday, 18 September 2022 at 12:47:03 UTC, Don Allen wrote:

Prelude> 0x10
16
Prelude> 0o10
8
Prelude> 0b10

<interactive>:8:2: error: Variable not in scope: b10

ps@DESKTOP:~$ ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Prelude> :set -XBinaryLiterals
Prelude> 0b0010
2
Prelude>

Well if you use that as your definition, you can technically remove it off the list. The language extensions in Haskell are probably candidates for the next official standard though.

On Sunday, 18 September 2022 at 11:00:12 UTC, Loara wrote:

enum MyFlag {A = 0, B, C}

T asFlag(T)(in T f) pure @safe nothrow @nogc{
  return (1 << f);
}

...

int field = MyFlag.A.asFlag & MyFlag.B.asFlag;

You made an error right away.

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

Function types. I don’t mean types like int function(string) (that is a function pointer type); I mean int(string). They are nowhere documented (as far as I can tell) and make some meta-programming tasks nasty.

void F(T)(T* ptr)
{
    pragma(msg, T); // prints void()
}
void main()
{
    void function() f = { };
    F(f);
}

If you try making f a delegate, the call F(f) cannot resolve T (obviously).

In C++, I can at least make use of them when a lot of functions should have the same signature and I don’t want to bother the reader making sure that is actually the case; I can typedef (via using) the function type and declare the functions to have exactly the same signature without repeating it:

// file.h
using F = void(int, double);
F f1, f2; // look like variables, but are function declarations.

// file.cpp
void f1(int i, double d) { }
void f2(int i, double d) { }

If I wanted something like that in D, my take would not be to add function types, but to do this:

alias F = void function(int, double);
enum F f1 = (i, d) { }
enum F f2 = (i, d) { }

If needed, just add a language rule that enum function pointers are an alternative syntax for free or static member functions and that enum delegates are an alternative syntax for non-static member functions (aka. methods).

Currently, function types are “needed” to apply __parameters to. Not only should __parameters work with function pointer types and delegate types, it should not work with function types because function types should not exist.

On Wednesday, 21 September 2022 at 11:50:16 UTC, Quirin Schroll wrote:

void F(T)(T* ptr)
{
    pragma(msg, T); // prints void()
}
void main()
{
    void function() f = { };
    F(f);
}

alias F = void function(int, double);
enum:F{ f1 = (i, d) { writeln("f1"); }}
enum:F{ f2 = (i, d) { writeln("f2"); }}

or

alias F = void function(int, double);
enum:F {
    f1 = (i, d) { },
    f2 = (i, d) { }
}

so i'd say this should work too

enum:F f1 = (i, d) { };

On Wednesday, 21 September 2022 at 12:12:52 UTC, Zealot wrote:

alias F = void function(int, double);
enum : F
{
    f1 = (i, d) { },
    f2 = (i, d) { }
}

This is big. You can do

enum : void function(int, double)
{
    f1 = (i, d) { },
    f2 = (i, d) { },
}

enum : F f1 = (i, d) { };

Why do you think this is good? Just use a space instead of :.

On Wednesday, 21 September 2022 at 19:22:00 UTC, Don Allen wrote:

Yeah, I guess an extreme version of this could be saying that Haskell has refinement types because Liquid Haskell exists

A lot of C's flaws could be accounted for if we were willing to consider GNU C rather than ISO C