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: # template Func1(T, U) # { # void Func1( T t, U u ) {} # } # # template Func2(R, S) # { # R Func2( S s ) {} # } # # int x, y; # Func1!()( x, y ); # x = Func2!(typeof(x))( y ); 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


 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:

 # template Func1(T, U)
 # {
 #     void Func1( T t, U u ) {}
 # }
 #
 # template Func2(R, S)
 # {
 #     R Func2( S s ) {}
 # }
 #
 # int x, y;
 # Func1!()( x, y );
 # x = Func2!(typeof(x))( y );

 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

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

 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

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

 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

 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

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

This can help.
Jul 30 2004