Bug in D!!!

[EntangledQuanta via Digitalmars-d-learn]

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.

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.

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.

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)

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. 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).


> 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).

This is all programming is. We define certain symbols to mean 
certain bit patterns, or generic bit matters(an if keyword/symbol 
is a generic bit pattern, a set of machine instructions(0's and 
1's) and substitution placeholders that are eventually filled 
with 0's and 1's).

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. 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) 
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: Is the gap "large", how much work will it take 
to fill the gap? Will feeling that gap have utility? etc. These 
practical questions can only be dealt with once the theoretical 
can of "is it possible" is dealt with. I have shown it is 
possible(well, Jonathan gave a proof of concept first, I just 
implemented an automation for it).

I think, at least several of us, should now be convinced that it 
is theoretically possible since several ways have been shown to 
be fruitful. We are now at where you have said you are not 
convinced if a new simpler syntax is warranted. The only real way 
to know is to implement that syntax experimentally, use it, then 
compare with the other methods and compare. But of course this is 
real work that most people are not willing to invest and so they 
approximate, as you have, an answer.

I do not know, as you don't. We have our guesses derived from our 
experiences and our extrapolations. I can say, that in my case, 
it would only simplify my code by a few lines(and, of course, 
remove a library dependency, which I do not like anyways). What 
it mainly does is reduce kludges and being I'm the type of person 
that does not like kludges, makes me "happier". If you are ok 
with kludges, then it won't effect you as much.

The only thing I can say are theoretical assertions and it is up 
for you to decide if they are worth your time to implement 
them(assuming you were the person).

1. Library solutions are always less desirable in the theoretical 
world. Ideally we would want a compiler that does everything and 
does it perfectly. Such an ideal may not be possible, but 
obviously compiler and language designers feel there is some 
amorphous ideal and history shows compilers tend to move towards 
that ideal. Libraries create dependencies on external code which 
have versioning issues, upkeep, etc. They are a middle ground 
solution between the practical and theoretical. But they are not 
something that should be "striven" for. Else, again, we should 
just write in binary and have everything implemented as a library 
solution. (which, once we do, we will realize we have a compiler) 
Library solutions also add complexity to the code itself. It is a 
trade off of compiler complexity vs user code complexity. The D 
community seems to love to push the complexity on the user. I 
feel this is partly do to those that deal with the compiler not 
really being coders(in the common sense of writing practical 
business applications for making $$$). For example, What has 
Walter actually coded as far as "practical stuff"? A video game? 
Did he even use D? This is not a jab at him, but my guess is that 
he is more of a mathematician rather than an engineer. You can't 
really do both and be great at them because there is only so much 
time in the day... even though they overlap greatly. When you get 
in to writing massive real world applications that span hundreds 
of developers, I'd bet D starts to fail miserably... of course, 
unless you are writing the next clone of pac man or some ad 
software. It's not that it can't be done, or that it can't be 
done well, but D starts showing it's weakness the more difficult 
the problem becomes(and it's strengths). You can write a simple 
command line utility in just about any language... it's not a 
test of the languages strengths and weaknesses.



2. Given the nature of the topic, which is virtual templated 
functions, which is a parallel of virtual functions, it seems IMO 
that it is more of a core concept that fits nicely with the other 
pieces. Those pieces are not implemented as a library 
solution(they could be, but then we are back to 1). Hence, it is 
not too much of a leap to think that adding this feature as a 
compiler solution is warranted. Since these are a simple 
extension of a compiler solution, it seems natural that the 
compiler should deal with it. If it were a library solution then 
it would be natural to extend the library... not mix and match, 
which is what is generally being suggested.


Now, it's true that the suggested solutions are relatively 
straight forward. So, the issue is somewhat moot now. It wasn't, 
at least for me, when I asked... and given that several people 
quickly denied that such a solution(any) existed, is what made 
this thread much longer than it needed to be. I'd prefer a 
compiler solution... that is my opinion. Do what you will with 
it. It means nothing at the end of the day. If I had my own 
compiler I would have already implemented it in the compiler. If 
my compiler was so fragile that I could not add such a simple 
rewrite rule(which should be very simple extensions that 
introduce minimum complexity to the language or compiler), I'd 
either rewrite the compiler(fix it like it should) or move one to 
greener fields.  Also keep in mind that what is complex to one 
person is not necessarily so to another. I just don't like to be 
*told*(not proven) that something is impossible when I very well 
know it is... it's really not about "liking" but the fact that 
those same people go and perpetuate their ignorance on other 
people. I can deal with it because I know better, but many people 
fall victim to such ignorance and it's one of the reasons why the 
world has so many problems as it does.