www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unified handling of basic and user-defined type proposal

reply "Eldar Insafutdinov" <e.insafutdinov gmail.com> writes:
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?
Nov 27 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 27 2012
parent reply "Eldar Insafutdinov" <e.insafutdinov gmail.com> writes:
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!
Nov 27 2012
parent reply "Rob T" <rob ucora.com> writes:
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
Nov 27 2012
parent reply "Eldar Insafutdinov" <e.insafutdinov gmail.com> writes:
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.
Nov 27 2012
next sibling parent "Rob T" <rob ucora.com> writes:
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
Nov 27 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
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
Nov 27 2012
parent "Rob T" <rob ucora.com> writes:
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
Nov 27 2012