On Tuesday, 5 January 2021 at 17:13:01 UTC, ag0aep6g wrote:
Sure. I've said in my first post in this thread that "issue
1807 is well worth fixing/implementing".
Ok, if we have a majority for this, then all is good.
A program has a bug when it doesn't behave as intended by its
author. I think that's a pretty permissive definition of bug.
So, DMD has a bug when it doesn't behave as Walter intended
when he wrote or accepted the code.
Ok, I can't argue if that is the definition.
My main concern is that we need to attract more people with a
strong comp.sci. background because as a language grow it becomes
more tricky to improve and the most difficult topics are the ones
that remain unresolved (like we see with @live, shared and GC).
I agree that there are more important topics than streamlining
parametric types. Like shared and memory management. But it is
still important to have an idea of which areas are worth picking
up, if someone comes along with an interest in writing solvers,
then this could be something he/she could tinker with.
should work. Walter has not come forward to say that he made a
mistake in the implementation.
Ok, but that is not important. What is important is that if
someone comes along with an interest in this area, then we can
encourage them to work on it.
Done. Incremental improvements lead to a system that works
pretty well a lot of the time. That's Walter's signature, isn't
it?
That happens in many compiler development cycles. Of course, D
has also added a lot of features... perhaps at the expense of
bringing what is to perfection.
I don't disagree. But we have to work with what we got. The
implementation exists. The spec doesn't.
It probably would be a good idea to focus on one subsystem at a
time. Refactor, document, make a list of priority improvements
for that subsystem, and then improve/reimplement, document, then
move on to the next subsystem.
If memory management is in the center now, then that is great,
but then maybe the next cycle could take another look at the type
system as a whole.
