Bug in D!!!

Sat Sep 2 19:39:19 PDT 2017

On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta 
wrote:
> On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner 
> wrote:
>> On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta 
>> wrote:
>>> On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips 
>>> wrote:
>>>> I've love being able to inherit and override generic 
>>>> functions in C#. Unfortunately C# doesn't use templates and 
>>>> I hit so many other issues where Generics just suck.
>>>>
>>>> I don't think it is appropriate to dismiss the need for the 
>>>> compiler to generate a virtual function for every 
>>>> instantiated T, after all, the compiler can't know you have 
>>>> a finite known set of T unless you tell it.
>>>>
>>>> But lets assume we've told the compiler that it is compiling 
>>>> all the source code and it does not need to compile for 
>>>> future linking.
>>>>
>>>> First the compiler will need to make sure all virtual 
>>>> functions can be generated for the derived classes. In this 
>>>> case the compiler must note the template function and 
>>>> validate all derived classes include it. That was easy.
>>>>
>>>> Next up each instantiation of the function needs a new 
>>>> v-table entry in all derived classes. Current compiler 
>>>> implementation will compile each module independently of 
>>>> each other; so this feature could be specified to work 
>>>> within the same module or new semantics can be written up of 
>>>> how the compiler modifies already compiled modules and those 
>>>> which reference the compiled modules (the object sizes would 
>>>> be changing due to the v-table modifications)
>>>>
>>>> With those three simple changes to the language I think that 
>>>> this feature will work for every T.
>>>
>>> Specifying that there will be no further linkage is the same 
>>> as making T finite. T must be finite.
>>>
>>> C# uses generics/IR/CLR so it can do things at run time that 
>>> is effectively compile time for D.
>>>
>>> By simply extending the grammar slightly in an intuitive way, 
>>> we can get the explicit finite case, which is easy:
>>>
>>> foo(T in [A,B,C])()
>>>
>>> and possibly for your case
>>>
>>> foo(T in <module>)() would work
>>>
>>> or
>>>
>>> foo(T in <program>)()
>>>
>>> the `in` keyword makes sense here and is not used nor 
>>> ambiguous, I believe.
>>
>> While I agree that `in` does make sense for the semantics 
>> involved, it is already used to do a failable key lookup 
>> (return pointer to value or null if not present) into an 
>> associative array [1] and input contracts. It wouldn't be 
>> ambiguous AFAICT, but having a keyword mean three different 
>> things depending on context would make the language even more 
>> complex (to read).
>
> Yes, but they are independent, are they not? Maybe not.
>
> foo(T in Typelist)()
>
> in, as used here is not a input contract and completely 
> independent. I suppose for arrays it could be ambiguous.

The contexts being independent of each other doesn't change that 
we would still be overloading the same keyword with three vastly 
different meanings. Two is already bad enough imho (and if I had 
a good idea with what to replace the "in" for AA's I'd propose 
removing that meaning).

>
> For me, and this is just me, I do not find it ambiguous. I 
> don't find different meanings ambiguous unless the context 
> overlaps. Perceived ambiguity is not ambiguity, it's just 
> ignorance... which can be overcome through learning. Hell, D 
> has many cases where there are perceived ambiguities... as do 
> most things.

It's not about ambiguity for me, it's about readability. The more 
significantly different meanings you overload some keyword - or 
symbol, for that matter - with, the harder it becomes to read.

>
> But in any case, I could care less about the exact syntax. It's 
> just a suggestion that makes the most logical sense with regard 
> to the standard usage of in. If it is truly unambiguous then it 
> can be used.

Well, yes, as I wrote, I think it is unambiguous (and can thus be 
used), I just think it shouldn't be used.

>
> Another alternative is
>
> foo(T of Typelist)
>
> which, AFAIK, of is not used in D and even most programming 
> languages. Another could be
>
> foo(T -> Typelist)
>
> or even
>
> foo(T from Typelist)

I would much rather see it as a generalization of existing 
template specialization syntax [1], which this is t.b.h. just a 
superset of (current syntax allows limiting to exactly one, you 
propose limiting to 'n'):

---
foo(T: char)      // Existing syntax: Limit T to the single type 
`char`
foo(T: (A, B, C)) // New syntax:      Limit T to one of A, B, or C
---

Strictly speaking, this is exactly what template specialization 
is for, it's just that the current one only supports a single 
type instead of a set of types.
Looking at the grammar rules, upgrading it like this is a fairly 
small change, so the cost there should be minimal.

>
> or whatever. Doesn't really matter. They all mean the same to 
> me once the definition has been written in stone. Could use 
> `foo(T eifjasldj Typelist)` for all I care.

That's okay, but it does matter to me.

> The import thing for me is that such a simple syntax exists 
> rather than the "complex syntax's" that have already been 
> given(which are ultimately syntax's as everything is at the end 
> of the day).

Quoting a certain person (you know who you are) from DConf 2017: 
"Write a DIP".
I'm quite happy to discuss this idea, but at the end of the day, 
as it's not an insignificant change to the language someone will 
to do the work and write a proposal.

>
>
>> W.r.t. to the idea in general: I think something like that 
>> could be valuable to have in the language, but since this 
>> essentially amounts to syntactic sugar (AFAICT), but I'm not 
>> (yet) convinced that with `static foreach` being included it's 
>> worth the cost.
>>
>
> Everything is syntactic sugar. So it isn't about if but how 
> much. We are all coding in 0's and 1's whether we realize it or 
> not. The point if syntax(or syntactic sugar) is to reduce the 
> amount of 0's and 1's that we have to *effectively* code by 
> grouping common patterns in to symbolic equivalents(by 
> definition).

AFAIK the difference between syntax sugar and enabling syntax in 
PLs usually comes down to the former allowing you to express 
concepts already representable by other constructs in the PL; 
when encountered, the syntax sugar could be lowered by the 
compiler to the more verbose syntax and still be both valid in 
the PL and recognizable as the concept (while this is vague, a 
prominent example would be lambdas in Java 8).

>
> No one can judge the usefulness of syntax until it has been 
> created because what determines how useful something is is its 
> use. But you can't use something if it doesn't exist. I think 
> many fail to get that.

Why do you think that? Less than ten people have participated in 
this thread so far.

> The initial questions should be: Is there a gap in the 
> language? (Yes in this case). Can the gap be filled? (this is a 
> theoretical/mathematical question that has to be answered.

> Most people jump the gun here and make assumptions)

Why do you assume that? I've not seen anyone here claiming 
template parameter specialization to one of n types (which is the 
idea I replied to) couldn't be done in theory, only that it can't 
be done right now (the only claim as to that it can't be done I 
noticed was w.r.t. (unspecialized) templates and virtual 
functions, which is correct due to D supporting separate 
compilation; specialized templates, however, should work in 
theory).

> Does the gap need to be filled? Yes in this case, because all 
> gaps ultimately need to be filled, but this then leads the 
> practical issues:

Actually, I disagree here. It only *needs* filling if enough 
users of the language actually care about it not being there. 
Otherwise, it's a *nice to have* (like generics and Go, or memory 
safety and C :p ).

[1] https://dlang.org/spec/template.html#parameters_specialization