TypeFunction example creatiing a conversion matrix

[Ola Fosheim Grøstad]

On Thursday, 1 October 2020 at 12:47:08 UTC, Stefan Koch wrote:
> It's an argument.
> But I would like to argue my actual use-case first.

Certainly, I was not discouraging your efforts. Simply trying to 
point out that it might be easier to convince sceptics if you can 
argue that your concept is a cog in the existing machinery or 
that it can be seen as syntactic sugar over desired cogs in a 
future revision of the language. You don't want sceptics to see 
your concept as sitting on a limb.


> It goes for making a very common usage patterns (at least in 
> all the big codebases I looked at, it common)

Yes, this is a good argument. Strengthening existing community 
practice. Making learning/reading easier.


> I also don't see D coming to a slim core. And frankly I don't 
> see why it needs to.
> D does not cater to purists, it caters to people who value 
> choice and creativity.
> At least as far as I see it.
> At least that is who I am.

I think you are right. Powerful features like the compiles-trait 
could make it virtually impossible to streamline language 
concepts in a non-breaking fashion as libraries might start to 
break when corner cases are removed.

Also there are recent additions that support your view. E.g. the 
addition of shared semantics which basically is just 
boxing/unboxing should have been possible as a library construct. 
Yet Manu had found it difficult to do as a pure library construct 
and wanted to see it implemented sooner than later, so D got 
another "limb feature". But there was little resistance to this 
feature because "shared" was already perceived by the community 
as being a language feature (although I would argue that it 
wasn't, it was more of a social construct). If a slim language 
was a goal then it would have been done as a library feature and 
"shared" would just have been syntactical sugar for that library 
feature.

Another vector you might use to argue for your feature is that 
reification/mangling is making future language evolution more 
difficult than your solution. At least, that is my understanding. 
Maybe I am wrong? I could be. But you might find some argument 
you can use there if your concept has a higher abstraction level 
than the alternatives. Which is generally desirable in a language 
as it is better for modelling. And D is marketed as being good 
for modelling, so that would be an argument if favour of your 
idea.

If people argue that your feature could be done using the 
existing language/reification then you should be able to argue 
that your feature is much needed syntactical sugar over such 
constructs. Basically, that you simply are creating an 
abstraction over existing features and practice that improves on 
the usability of the language.

Compiler performance issues should be argued as being 
optimizations. Abstractions often makes optimizations easier to 
implement as less static analysis is needed (the search space is 
smaller). So even though you might see your idea as being a 
compiler addition, you should be able to argue that it isn't 
really, but that it would be beneficial to implement it as such.

Anyway, I am interested to see where you go with this. :-)