Regarding the proposed Binray Literals Deprecation

[Quirin Schroll]

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright 
wrote:
> On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:
>> But it doesn't disprove the fact that *sometimes*, hex digits 
>> aren't as clear.
>
> Does sometimes justify a language feature, when there are other 
> ways?
>
> People often complain that D has too many features. What 
> features would you say are not worth it?

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.
```D
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:
```cpp
// 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:
```D
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.