www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implicit instantiation: why not?

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Walter

Can you give a short description of why II is not desirable to you, as a
compiler writer?

I've a couple of ideas for some halfway-houses that I'd like to share (after a
bit more pondering), assuming they don't
violate your principles (on which I'm still a bit muddy).

Matthew
Jul 29 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Matthew wrote:

 
 Can you give a short description of why II is not desirable to you, as a
compiler writer?


For the sake of discussion, I'll hazard a guess: it would complicate 
compilaion.  Assuming full C++ like function template support were done, 
it may change the order things are evaluated, and it may require a 
loosening of some rules (as templates names are currently not allowed to 
be overloaded with function names).

To me, the most valuable thing would be the implicit type determination 
however, not the overloading with non-template functions.  For this 
reason, perhaps we could do something like this:















ie. Template functions are always signaled with the ! and parens, just 
as they are now.  If the complier can't determine a type based on the 
calling conventions then it must be specified (just as in C++).  This 
would save us from typing painfully long types without overly 
complicating evaluation.


Sean
Jul 29 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:ceci0l$243h$1 digitaldaemon.com...

 Matthew wrote:

 Can you give a short description of why II is not desirable to you, as a




compiler writer?

 For the sake of discussion, I'll hazard a guess: it would complicate
 compilaion.  Assuming full C++ like function template support were done,
 it may change the order things are evaluated, and it may require a
 loosening of some rules (as templates names are currently not allowed to
 be overloaded with function names).

 To me, the most valuable thing would be the implicit type determination
 however, not the overloading with non-template functions.  For this
 reason, perhaps we could do something like this:















 ie. Template functions are always signaled with the ! and parens, just
 as they are now.  If the complier can't determine a type based on the
 calling conventions then it must be specified (just as in C++).  This
 would save us from typing painfully long types without overly
 complicating evaluation.


 Sean


Funny, I was just thinking the same thing - and the business about erroring
when there are any ambiguities is consistent with other D rules. For example
if Func1 had default parameters for T and U then the !() would error because
the compiler couldn't tell if it should use implicit instantiation or the
default types.
Jul 30 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cec1mn$1tlt$4 digitaldaemon.com...

 Walter

 Can you give a short description of why II is not desirable to you, as a


compiler writer?

 I've a couple of ideas for some halfway-houses that I'd like to share


(after a bit more pondering), assuming they don't

 violate your principles (on which I'm still a bit muddy).


For a long time I felt that implicit function instantiation of templates was
where C++ templates ran off the road into the weeds. Certainly, I still feel
that way about overloading them with regular functions of the same name, but
I'm not so sure about the rest. I still loathe things like implicitly
instantiating template functions by taking their address, mainly because it
is a b*tch to get to work right in a language that fundamentally does bottom
up typing (this kind of instantiation is top down, and so where they meet is
a swamp of bugs).

Implict instantiation is an enormous increase in complexity.
Jul 29 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cecq57$27on$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cec1mn$1tlt$4 digitaldaemon.com...

 Walter

 Can you give a short description of why II is not desirable to you, as a


 compiler writer?

 I've a couple of ideas for some halfway-houses that I'd like to share


 (after a bit more pondering), assuming they don't

 violate your principles (on which I'm still a bit muddy).


 For a long time I felt that implicit function instantiation of templates was
 where C++ templates ran off the road into the weeds. Certainly, I still feel
 that way about overloading them with regular functions of the same name, but
 I'm not so sure about the rest. I still loathe things like implicitly
 instantiating template functions by taking their address, mainly because it
 is a b*tch to get to work right in a language that fundamentally does bottom
 up typing (this kind of instantiation is top down, and so where they meet is
 a swamp of bugs).

 Implict instantiation is an enormous increase in complexity.


What I'm wondering is whether we can live with a halfway house.

This is my first thrust, so please take and mould:

An implicitly instantiable template:

- cannot bear the same name, i.e. is not overloaded with, any other
type/function in the same module
- bears the keyword implicit on all its specialisations
- can't have its address taken, or otherwise be treated as anything other than
an "inline mixin".

Hence:

implicit template accumulate(T, I)
{
    T accumulate(I first, I last, T initial);
}

Now this seems quite limiting, but it's not. The reason is that *inside* the
implementation we can be as specific as we
like with _explicit_ instantiations.

Alas, the specific example I had on my morning's ride evaporated in the shower,
but my thoughts are basically that once
inside the implicitly instantiated templates, we have access to all the
variables and types (via the template params, or
typeof if necessary) and so we can explicitly instantiate anything within there.

Thus, if we can boil down your minimum acceptable definition of implicitly
instantiated templates, it may be that you
can give us something good enough to use.
Jul 30 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:ced108$2bh1$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message


news:cecq57$27on$1 digitaldaemon.com...

 What I'm wondering is whether we can live with a halfway house.

 This is my first thrust, so please take and mould:

 An implicitly instantiable template:

 - cannot bear the same name, i.e. is not overloaded with, any other


type/function in the same module

It still has to be overloadable with other templates of the same name,
otherwise the feature is useless. Next, you have overloading of implicit
function templatess with arguments that are implicitly instantiated function
templates. This is where things get ugly.


 - bears the keyword implicit on all its specialisations


Doesn't help the complexity, since all the work has to be done any way.


 - can't have its address taken, or otherwise be treated as anything other


than an "inline mixin".

This can help.
Jul 30 2004