enum Format

[Timon Gehr]

On 1/10/24 20:53, Walter Bright wrote:
> On 1/9/2024 2:38 PM, Timon Gehr wrote:
>  > %s7 8 9
> 
> Yes, I used writeln instead of writefln. The similarity between the two 
> names is a source of error, but if that was a festering problem we'd 
> have seen a lot of complaints about it by now.
> ...

My point was with DIP1036e it either works or does not compile, not that 
you called the wrong function.

> 
>> And you can get rid of the runtime overhead by adding a 
>> `pragma(inline, true)` `writeln` overload. (I guess with DMD that will 
>> still bloat the executable,
> 
> Try it and see.
> 
> I didn't mention the other kind of bloat - the rather massive number and 
> size of template names being generated that go into the object file, as 
> well as all the uncalled functions generated only to be removed by the 
> linker.
> ...

I understand the drawbacks of DIP1036e which it shares with most 
non-trivial metaprogramming. D underdelivers in this department at the 
moment, but this still remains one of the key selling points of D.

The issue is that DIP1027 is worse than DIP1036e. DIP1027 is also worse 
than nothing. It has been rejected for good reason. For some reason you 
however keep insisting it is essentially as useful as DIP1036e. That's 
just not the case.

I think a much better answer to DIP1036e than a DIP1027 revival would 
have been to add a -preview=experimental-DIP1036e flag and do a call to 
action to resolve language issues and limitations that force DIP1036e to 
generate bloat. Maybe there would have been an even better way to handle 
this.

> As far as I can tell, the only advantage of DIP1036 is the use of 
> inserted templates to "key" the tuples to specific functions.

Well, this is not the case, that is not the only advantage.

> Isn't that 
> what the type system is supposed to do? Maybe the real issue is that a 
> format string should be a different type than a conventional string. For 
> example:
> 
> ```d
> extern (C) pragma(printf) int printf(const(char*), ...);
> 
> enum Format : string;
> 
> void foo(Format f) { printf("Format %s\n", f.ptr); }
> void foo(string s) { printf("string %s\n", s.ptr); }
> 
> void main()
> {
>      Format f = cast(Format)"f";
>      foo(f);
>      string s = "s";
>      foo(s);
> }
> ```
> which prints:
> 
> Format f
> string s
> 
> If we comment out `foo(string s)`:
> 
> test2.d(14): Error: function `test2.foo(Format f)` is not callable using 
> argument types `(string)`
> test2.d(14):        cannot pass argument `s` of type `string` to 
> parameter `Format f`
> 
> If we comment out `foo(Format s)`:
> 
> string f
> string s
> 
> This means that if execi()'s first parameter is of type `Format`, and 
> the istring generates the format string with type `Format`, this key 
> will fit the lock. A string generated by other means, such as `.text`, 
> will not fit that lock.
> 

Well, this is a step in the right direction, but rest assured if this 
was the only advantage of DIP1036e, then Adam would have gone with this 
suggestion. I am almost sure this is one of the ideas he discarded.