Bug in D!!!

[EntangledQuanta via Digitalmars-d-learn]

On Saturday, 2 September 2017 at 16:20:10 UTC, Jesse Phillips 
wrote:
> On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta 
> wrote:
>> Regardless of the implementation, the idea that we should 
>> throw the baby out with the bathwater is simply wrong. At 
>> least there are a few who get that. By looking in to it in a 
>> serious manner an event better solution might be found. Not 
>> looking at all results in no solutions and no progress.
>
> Problem is that you didn't define the problem. You showed some 
> code the compiler rejected and expressed that the compiler 
> needed to figure it out. You did change it to having the 
> compiler instantiate specified types, but that isn't defining 
> the problem.

I think the problem is clearly defined, it's not my job to be a D 
compiler researcher and spell everything out for everyone else. 
Do I get paid for solving D's problems?

> You didn't like the code needed which would generate the 
> functions and you hit a Visual D with the new static foreach.

This sentence makes no sense. "hit a Visual D" what? Do you mean 
bug? If that is the case, how is that my fault? Amd I suppose to 
know off the bat that an access violation is caused by Visual D 
and not dmd when there is no info about the violation? Is it my 
fault that someone didn't code one of those tools good enough to 
express enough information for one to figure it out immediately?

> All of these are problems you could define, and you could have 
> evaluated static foreach as a solution but instead stopped at 
> problems with the tooling.

Huh? I think you fail to understand the real problem. The problem 
has nothing to do with tooling and I never said it did. The 
static foreach "solution" came after the fact when SEVERAL 
people(ok, 2) said it was an impossible task to do. That is where 
all this mess started. I then came up with a solution which 
proved that it is possible to do on some level, that is a 
solution to a problem that was defined, else the solution 
wouldn't exist.


> You also don't appear to care about the complexity of the 
> language. I expressed three required changes some of which may 
> not play nicely with least surprise. You went straight to, we 
> just need to define a syntax for that instead of expressing 
> concern that the compiler will also need to handle errors to 
> the use, such that the user understands that a feature they use 
> is limited to very specific situations.

Do you not understand that if a library solution exists then 
there is no real complexity added? It is called "lowering" by 
some. The compiler simply "rewrites" whatever new syntax is added 
in a form that the library solution realized. You are pretended, 
why?, that what I am proposed will somehow potentially affect 
every square micron of the D language and compiler, when it won't.

Not all additions to a compiler are add *real* complexity. That 
is a failing of you and many on the D forums who resist change.

> Consider if you have a module defined interface, is that 
> interface only available for use in that module? If not, how 
> does a different model inherent the interface, does it need a 
> different syntax.

What does that have to do with this problem? We are not talking 
about interfaces. We are talking about something inside 
interfaces, so the problem about interfaces is irrelevant to this 
discussion because it applies to interfaces in general... 
interfaces that already exist and the problem exists regardless 
of what I

> There is a lot more to a feature then having a way to express 
> your desires. If your going to stick to a stance that it must 
> exist and aren't going to accept there are problems with the 
> request why expect others to work through the request.


No, your problem is your ego and your inability to interpret 
things outside of your own mental box. You should always keep in 
mind that you are interpreting someone elses mental wordage in 
your own way and it is not a perfect translation, in fact, we are 
lucky if 50% is interpreted properly. Now, if I do not have a 
right to express my desires, then at least state that, but I do 
have a right not to express any more than that. As far as 
motivating other people, that is isn't my job. I could care less 
actually. D is a hobby for me and I do it because I like the 
power D has, but D is the most frustrating language I have ever 
used. It's the most(hyperbole) buggy, most incomplete(good docs 
system: regardless of what the biased want to claim, tool, etc), 
most uninformative(errors that just toss the whole kitchen sink 
at you), etc.  But I do have hope... which is the only reason I 
use it. Maybe I'm just an idiot and should go with the crowed, it 
would at least save me some frustration. C#, since you are 
familiar with it, you should know there is a huge difference. If 
D was like C# as far as the organizational structure(I do not 
mean MS, I mean the docs, library, etc) you would surely agree 
that D would most likely be the #1 language on this planet? C# 
has it's shit together. It is, for the most part, and elegant 
language that is well put together in almost every regard. It was 
thought out well and not hacked together the way D feels. The 
problem is that the D community doesn't seem to want to go a 
similar direction but go in circles. I think D will not progress 
much further in the next 10 years, if at all as far as improving 
it's self. The attitude of D programmers tends to be quite 
lame(it's a ragtag collection of individuals working in disparate 
means that only come together when there is a common need rather 
than a team working together for a higher focused purpose).


First, you make up stuff as I never said anything about it *must 
existing* in D. Search the thread and you will see that you are 
the first one to use that phrase. Second, you fail to understand 
the difference between a theoretical discussion about what is 
possible and the practical of what is possible.

Second, I am talking about the theoretical aspects of the 
*ability* to use virtual template function in D. I was told it is 
impossible, at least at first. Jonathan then came up with a hand 
written method where one uses a kludge to sort of do it. I then 
came up with a library solution that shows that it can be 
implemented and used with a few lines of code that enable such a 
feature(the two mixins). I also clarified the problem that by 
stating it is not an issue about virtual templated function but 
about the "size" of T(in which I do not mean the byte size but 
the space).

With such a solution, it shows that a compiler can internally 
"add those lines"(effectively, which means that it will do 
whatever similar work it needs to do and so we can get a similar 
behavior without having to explicitly use the library solution to 
provide such functionality).

Third, knowing that it is feasible opens the door and at least 
should pacify those that claim it is impossible. That is actually 
quite a lot on my part. I could have just shut up and let things 
be what they are and let the ignorance continue being ignorant. I 
put the foot in the door. But by doing that it opens up things 
for discussion about progression, which is what happened next 
PRECISELY because I pushed through the ignorance and put in the 
time to get the discussion going. Sure, I could have silently 
written up a dip and put 4 weeks of effort in it, forked dmd and 
implemented the code to show how it could be done, etc. But that 
is not my job, and considering how appreciative people around 
here are of compiler changes, dips, and advanced featuers, I'd 
expect it to a total waste of time. I have better things to do 
with my life than that. Given also the nature of the dmd 
community and the level of the tooling, docs, and such, I'm not 
going to invest my life it beyond planting seeds that maybe one 
day will sprout, but unlikely not because no one cares to water 
them.


So, now we are at the "static foreach" solution that Adam added. 
I tried it, it looks nice but crashed as I did it. You seem to 
think I'm suppose to realize immediately with the only error 
"Access violtion: Object(0x34234)" is suppose to be a tooling 
problem. I guess I'm just not that smart. But eventually I did 
figure it out on my own and realized it was with visual D.

But even that should be irrelevant as we are taking about a D 
feature. You then come along and add your 2c, and suggest a few 
specific issues and your thoughts about them. I then respond 
essentially agreeing with you but stating I still don't think it 
can be done for every T but offer a few syntaxes that might work 
in limiting T to being finite, which, is fundamentally the 
problem, regardless if you think it is or not and your statements 
are contradictory where you say "limit the linkage" and "all T". 
To spell it out:

First you say "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."

Then at the end you say "With those three simple changes to the 
language I think that this feature will work for every T."

Which are contraditory. Assuming we've told the compiler that no 
future linking is going to occur IS limiting T which means it 
won't work for EVERY T. By every T I mean every T in existence 
ever, regardless of any assumptions, rules, etc. If you meant 
every T in the source code, then yes, but you should have made 
that explicit since the problem innately depends on T being 
finite regardless of any implementation.

You then basically attack me saying I should have done this and 
that and it's my fault for not stating the problem(which I did, 
clearly or not, or we wouldn't be at this point). I should think 
about the ramifications, etc. But I guess every day is different, 
right?

Anyways, any library solution or kludge is not a solution in my 
book. The foreach method is no different than the mixin solution 
as far as added additional lines of code to a project that make 
the code less clear, less elegant, and less robust.

You can make claims all day long that everything that can be 
implemented in a library should be. If that is the case many 
compiler features/all should be eliminated, in fact, maybe we 
should write in binary, as we can add everything to a library 
that we need? For some reason the DMD compiler and D language is 
treated like a golden calf that can't be changed. So much worry 
about adding complexity. If the design is so fragile that 
additional complexity or changes will potentially cause it to 
collapse, then it's not the features problems but D/dmd. At least 
state that case if it is. In that case it will collapse on it's 
own in due time regardless of what new stuff is added, patches 
can only take one so far.

Anyways, I'm done with this conversation. I've shown light on a 
problem with D and shown that it has the potential to be solved, 
I am not going to be the one to solve it. If you want to waste 
many hours of your life on trying to get find a proper solution 
and get it accepted, by all means. I will use kludges as it gets 
me down the road... it doesn't make me happy, but who cares about 
happiness?