How about a special null template parameter?

[Lodovico Giaretta via Digitalmars-d]

On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:
> On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta 
> wrote:
>> 1) `null` has a very precise meaning: it is the only valid 
>> value of an unnamed type only known as `typeof(null)`, which 
>> implicitly converts to any class/pointer/dynamic 
>> array/associative array type. Thus this thing should have a 
>> different name.
>
> null as many interpretations. It is ok to expand the meaning. 
> It is done all the time. If it confuses you are creates a 
> semantic difficulty, I don't mind what it is called. It could 
> be called Boomfurkasufasdf.
>
> In this case, defining it to be null fits in semantically 
> though. If it creates some compiler issue then, again, anything 
> else could be used. I'd prefer Null or NULL or Aleph or 
> something short and meaningless.

The problem is that null is a valid value to instantiate an alias 
template parameter with. So using it to do something completely 
different may create ambiguity (does that null means "parent 
template" or is it a valid instantiation? Who knows). But as you 
said, this is just a matter of finding a name.


>> 2) What about this case:
>> ```
>> class Type(T): Type
>> {
>>     static if (T is Dog)
>>         int y;
>>     else
>>         float z;
>> }
>> ```
>> What should be inside the base?
>
> z.

This is wrong. If Type has to be the base class of every Type!T, 
then it cannot contain z, as there is one Type!T (namely 
Type!Dog) which does not contain z. So in this case the base 
class Type should be empty. As you see it is not that simple.

> I am after simplifying class design.

Fair enough. Though I'm not sure this is the right way to go.

>> 4) I think that the value of this addition is little wrt. the 
>> amount of work the compiler should do to implement it (which 
>> at first sight would be a lot). But this is of course just my 
>> opinion.
>
> It is just syntactic sugar and requires no complex compiler 
> modifications. The benefit is reduced visual complexity and 
> that is always a bonus. That is the point we don't write in 0's 
> and 1's... everything else is just syntactic sugar. In this 
> case, it is a very simple rewrite rule. A few lines of code 
> would be all that is required.

I'm not an expert, but I think this requires *a lot* of compiler 
work: it has to analyze every symbol in the class to find out 
whether it must be part of the "uninstantiated" base or not. And 
this kind of analysis may not be easy (it may be masked by the 
use of traits, template mixins, string mixins and so on). Even 
humans can easily get it wrong (see my previous example).

Also, I thought of other problems:
- Interaction with non-class templates: how should they behave? 
Or are we just introducing a special case for class templates? 
(Special cases are very bad, we should limit them).
- Interaction with base classes and interfaces: how is this 
"uninstantiated base class" inserted into the graph of classes 
and interfaces? Are interfaces considered implemented by this 
base class? Is this base class inserted between the templated 
class and the "original" base class?