Something that I wanted to write about for quite some time and it was triggered by the discussion about allowing alias template parameters to accept basic types. I wrote about it in the thread, but decided to write a separate post which would provide more explanation and details: http://eldar.me/2012/11/27/symbols-in-the-d-compiler/ . I think that this will be a better solution to the alias problem. Any thoughts?

On 2012-11-27 16:35, Eldar Insafutdinov wrote:
> Something that I wanted to write about for quite some time and it was
> triggered by the discussion about allowing alias template parameters to
> accept basic types. I wrote about it in the thread, but decided to write
> a separate post which would provide more explanation and details:
> http://eldar.me/2012/11/27/symbols-in-the-d-compiler/ . I think that
> this will be a better solution to the alias problem. Any thoughts?

I like the idea.

ATP, should be TAP ?

-- 
/Jacob Carlborg

On Tuesday, 27 November 2012 at 15:50:25 UTC, Jacob Carlborg wrote:
> On 2012-11-27 16:35, Eldar Insafutdinov wrote:
>> Something that I wanted to write about for quite some time and it was
>> triggered by the discussion about allowing alias template parameters to
>> accept basic types. I wrote about it in the thread, but decided to write
>> a separate post which would provide more explanation and details:
>> http://eldar.me/2012/11/27/symbols-in-the-d-compiler/ . I think that
>> this will be a better solution to the alias problem. Any thoughts?
>
> I like the idea.
>
> ATP, should be TAP ?

Thanks, corrected now!

What you are suggesting makes perfect sense. IMHO the biggest source of waste in any language both natural and contrived (and with many things outside of languages) is inconsistency. The more differences and incompatibilities there are between the various constructs, the more complexity is introduced into the system, often needlessly. Even if you have to fake it, making x consistent with y is often worth doing, and IMO it can be done with zero cost in terms of performance and other forms of overhead.

Unfortunately D was modeled after C++, a legacy language built on top of an inconsistent foundation. Even though D is an improvement, I think D has inherited at its foundation a crippling affect that will be impossible to shake off fully. The language would have to fundamentally change to become consistent.

No matter, as you've suggested (and I think shown), D can still be adjusted to get rid of at least some of the crippling effects of inconsistency, and even a small fix to an inconsistency can potentially create a big improvement.

--rt

On Tuesday, 27 November 2012 at 17:49:00 UTC, Rob T wrote:
>
> Unfortunately D was modeled after C++, a legacy language built on top of an inconsistent foundation. Even though D is an improvement, I think D has inherited at its foundation a crippling affect that will be impossible to shake off fully. The language would have to fundamentally change to become consistent.

Yes, this is what I implied in my post, that the decision of handling basic types separately from user defined comes from C++ which itself is built on the ancient C. Symbol itself is a vague and legacy concept that comes from C/C++ and we must not include it in the justification for how language features should work.

> No matter, as you've suggested (and I think shown), D can still be adjusted to get rid of at least some of the crippling effects of inconsistency, and even a small fix to an inconsistency can potentially create a big improvement.

I also believe that it is possible to introduce these changes in an iterative manner. Each step will provide significant improvements to the language. If everybody agrees that this proposed change is worth exploring into and has chances to be included in D, I am willing to commit my time to implement it.

On Tuesday, 27 November 2012 at 18:38:57 UTC, Eldar Insafutdinov wrote:
> On Tuesday, 27 November 2012 at 17:49:00 UTC, Rob T wrote:
>> No matter, as you've suggested (and I think shown), D can still be adjusted to get rid of at least some of the crippling effects of inconsistency, and even a small fix to an inconsistency can potentially create a big improvement.
>
> I also believe that it is possible to introduce these changes in an iterative manner. Each step will provide significant improvements to the language. If everybody agrees that this proposed change is worth exploring into and has chances to be included in D, I am willing to commit my time to implement it.

Well I do agree in principle, but politically there may be a large resistance due to the desire to stabilize the language such that it will no longer create breaking changes.

I of course think that stability is essential, but at the same time it can also be a bad thing. What we should try to achieve, is a clear and practical way to allow the language to stabilize, yet at the same time also allow it to continue to evolve for the better which inevitably means making breaking changes. If we continue long the same path C/C++ took, then in short order we'll end up with C/C++ all over again. I can already taste it, and I don't like that taste! Look at C++11, was that really an improvement?

In any event, we'll need to see the movers and shakers of D come on board with considering how D can still stabilize, but also be made to evolve for the better, not like C++ is doing, but really for the better in fundamental ways.

So, let's wait and see what kind of comments show up in here.

--rt

On Tuesday, 27 November 2012 at 18:38:57 UTC, Eldar Insafutdinov wrote:
> I also believe that it is possible to introduce these changes in an iterative manner. Each step will provide significant improvements to the language. If everybody agrees that this proposed change is worth exploring into and has chances to be included in D, I am willing to commit my time to implement it.

I think the main question is: How many breaking changes to the *language* will it introduce? Unless I'm missing something, there should not be to many besides some template matching special cases (alias T vs. T, ...), so I think this would in theory have good changes of making it in. However, this all depends on Walter being willing to accept such a change to the compiler anyway.

David

On Tuesday, 27 November 2012 at 19:07:41 UTC, David Nadlinger wrote:
> On Tuesday, 27 November 2012 at 18:38:57 UTC, Eldar Insafutdinov wrote:
>> I also believe that it is possible to introduce these changes in an iterative manner. Each step will provide significant improvements to the language. If everybody agrees that this proposed change is worth exploring into and has chances to be included in D, I am willing to commit my time to implement it.
>
> I think the main question is: How many breaking changes to the *language* will it introduce? Unless I'm missing something, there should not be to many besides some template matching special cases (alias T vs. T, ...), so I think this would in theory have good changes of making it in. However, this all depends on Walter being willing to accept such a change to the compiler anyway.
>
> David

At some point the compiler really should be built entirely in D, perhaps that would be the time for fixing and simplifying a ton of things.

--rt