Reply to dennis,

> Walter Bright schrieb:
> 
>> Some new stuff to make writing templates easier.
>> 
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.031.zip
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.015.zip
> what are difference between Template Constraints
> and static asserts?

if a static assert fail, the compiler just quits. If a template constraints is not satisfied, the template is considered to not match and other matches are attempted.

dennis luehring Wrote:
> what are difference between Template Constraints
> and static asserts?

Besides speed of implementation, I don't think there's much of a difference while SFINAE is in place.  I'd love to see SFINAE removed and start relying on the power of D's template matching.  I know SFINAE is a staple of C++, but I don't think it's really needed in D.  I submitted a request in D's issue tracker, but there has been no response from anyone that'd strongly influence D's design.

Reply to Jason,

> dennis luehring Wrote:
> 
>> what are difference between Template Constraints
>> and static asserts?
> Besides speed of implementation, I don't think there's much of a
> difference while SFINAE is in place.  I'd love to see SFINAE removed
> and start relying on the power of D's template matching.  I know
> SFINAE is a staple of C++, but I don't think it's really needed in D.
> I submitted a request in D's issue tracker, but there has been no
> response from anyone that'd strongly influence D's design.
> 

I don't think SFINAE is effected by static assert. I think the assert is always used and always aborts the compile on failure. (Correct me if I'm wrong)

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> GDC has fallen behind and could use some TLC.
> 
> I hope I'm not stepping on any toes by saying this, but GDC
> seems like a sinking ship to me.  Almost all of the issues
> we have with Tango concern GDC codegen or install problems.
> At this point I'm very much hoping that LLVMDC or the other
> D compiler project (dyld?) can supplant GDC.  In fact, I
> think the LLVMDC folks have been asking for help to get
> some issues sorted out?

I've tried as much as possible to keep improvements to DMD in the front end code, rather than tweaking the back end. This is to make folding the changes in to other D compiler implementations easier.

That said, I am here to help with any questions about how things work in order to help those connecting the front end to other back ends, and I am also willing to do what I can to fold changes into the front end that will make future updates easier.

Sascha Katzner wrote:
> I would love this too. A bootstrapped compiler is like the ultimate statement from a developer that he thinks his product is mature enough that even he himself uses it. I think when D has achieved this goal, it is finally adult. :)

The problem with a D compiler in D is that nearly every compiler back end is in C or C++, and having the D front end in C++ makes it easier to connect to existing back ends.

Many, many times, however, I wished it was in D just because it would make coding it easier.

aarti_pl wrote:
> But anyway thanks - this is rationale although I don't agree fully :-)

It's too much to ask for everyone to agree, the more important thing is if the job is getting done.

Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:g3bqmi$2117$1@digitalmars.com...
>>Jarrett Billingsley wrote:
>>>And if something like this _is_ too much work for one man -- why not put the DMDFE source on dsource and start accepting help on things like this?
>>
>>Reorganizing the internals of the compiler is not just accepting a patch.
>>
>>I've incorporated many user patches to dmd. The source doesn't need to be on dsource for that.
> 
> I'm not suggesting patches.  I'm suggesting that you not be the *only* person working on DMDFE.  I'm also suggesting that if the internals need to be reorganized to implement forward reference resolution -- so be it.  Maybe the compiler needs to be rewritten.  It's been in development an awfully long time and D has changed considerably since development started.  The semantic analysis that used to cut it when it wasn't much more complex than Java might not be working for us anymore. 

We've had this discussion in the past, and Walter has said it's OK for anybody to make changes to the FE, that's why it's open source.

That means that you /already/ can put it on dsource and have people send you patches. You can then automatically (say once a day or week) have the thing compiled, regression test suite run, and have the binary put on download.

Once a particular patch has been used by enough people, it becomes easier to suggest Walter incorporate it in Phobos.

Reply to Georg,


> We've had this discussion in the past, and Walter has said it's OK for
> anybody to make changes to the FE, that's why it's open source.
> 
> That means that you /already/ can put it on dsource and have people
> send you patches. You can then automatically (say once a day or week)
> have the thing compiled, regression test suite run, and have the
> binary put on download.
> 
> Once a particular patch has been used by enough people, it becomes
> easier to suggest Walter incorporate it in Phobos.
> 

one problem, to really make that work you need the backend Walter uses.

Russell Lewis Wrote:

> Robert Fraser wrote:
> > Jason House wrote:
> >> Walter Bright wrote:
> >>
> >>> Some new stuff to make writing templates easier.
> >>>
> >>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.031.zip
> >>>
> >>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.015.zip
> >>
> >> Why is "alias" required when specifying a template parameter?  It
> >> seems like
> >> the most accepting and general case.  Why wouldn't it be the default?
> > 
> > Really? I have never had a use for an alias parameter (although I guess most types could work as alias parameters) except using an un-speced trick with regards to their name mangling. They seem way to permissive.
> 
> One great example of alias parameters is when you want to pass another template name as a parameter.  You can build a foreach() template, operating over a Tuple, which passes each element in the Tuple into some other template.

I'm not saying they're not useful ;-P. I'm just saying that they're used rarely enough that making them the default is not a good idea.

Walter Bright, el 19 de junio a las 12:08 me escribiste:
> Sascha Katzner wrote:
> >I would love this too. A bootstrapped compiler is like the ultimate statement from a developer that he thinks his product is mature enough that even he himself uses it. I think when D has achieved this goal, it is finally adult. :)
> 
> The problem with a D compiler in D is that nearly every compiler back end is in C or C++, and having the D front end in C++ makes it easier to connect to existing back ends.
> 
> Many, many times, however, I wished it was in D just because it would make coding it easier.

I don't think I have to tell *you* this, but since D is link compatible with C, I don't think that's a real issue...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
41% of all people take people with curly hair less seriously