www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will implicit function template instantiation be in DMD 1.0?

reply Don Clugston <dac nospam.com.au> writes:
In one of the recent threads, there was a mention of blockers.
One of these, I think, is the absence of any kind of a roadmap.
No great detail is required, just a crude travel plan along the lines of 
"we'll go to Switzerland, but not until after we've visited Portugal".

The most uncertain feature is also the most important:
When will implicit function template instantiation be introduced?

For example, it doesn't make sense to develop standard container classes 
without an answer to this question. Will it begin to happen in, say, the 
next ten releases? Or will the path to 1.0 be mainly bug fixes and minor 
tweaking?

It seems that most other major confirmed features have been categorised 
as "2.0" or "eventually, but not yet". But the timescale for IFTI is 
still very unclear.
Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:ds9qaa$1of9$1 digitaldaemon.com...
 In one of the recent threads, there was a mention of blockers.
 One of these, I think, is the absence of any kind of a roadmap.
 No great detail is required, just a crude travel plan along the lines of 
 "we'll go to Switzerland, but not until after we've visited Portugal".

 The most uncertain feature is also the most important:
 When will implicit function template instantiation be introduced?

 For example, it doesn't make sense to develop standard container classes 
 without an answer to this question. Will it begin to happen in, say, the 
 next ten releases? Or will the path to 1.0 be mainly bug fixes and minor 
 tweaking?

 It seems that most other major confirmed features have been categorised as 
 "2.0" or "eventually, but not yet". But the timescale for IFTI is still 
 very unclear.

The problem is these "must have" features keep coming up. I thought I'd have implicit function template instantiation by now, but haven't even started on it. I'd spent a lot of time working on the other template problems you uncovered. I'd say hold off on designing a template library without implicit function template instantiation.
Feb 07 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:ds9qaa$1of9$1 digitaldaemon.com...
 
In one of the recent threads, there was a mention of blockers.
One of these, I think, is the absence of any kind of a roadmap.
No great detail is required, just a crude travel plan along the lines of 
"we'll go to Switzerland, but not until after we've visited Portugal".

The most uncertain feature is also the most important:
When will implicit function template instantiation be introduced?

For example, it doesn't make sense to develop standard container classes 
without an answer to this question. Will it begin to happen in, say, the 
next ten releases? Or will the path to 1.0 be mainly bug fixes and minor 
tweaking?

It seems that most other major confirmed features have been categorised as 
"2.0" or "eventually, but not yet". But the timescale for IFTI is still 
very unclear.

The problem is these "must have" features keep coming up. I thought I'd have implicit function template instantiation by now, but haven't even started on it. I'd spent a lot of time working on the other template problems you uncovered. I'd say hold off on designing a template library without implicit function template instantiation.

Fantastic! In that case, I withdraw all other proposals I've made regarding templates. The meta-programming template support seems to be really quite solid now, from my original list of workarounds, the only one that remains is digitalmars.com digitalmars.D.bugs:6004 which I think you just missed, because you fixed the almost identical one digitalmars.com digitalmars.D.bugs:6003. Now, almost everything I try works as I'd hoped (and I've tried some pretty wild stuff!). It tends to be unforgiving, in that some kinds of syntax errors segfault the compiler instead of giving error messages; but that does not prevent library development. It's possible to write really elegant metafunctions now. I'm not sure how I managed to get your attention, but it's been an exciting thing to be involved with. Some of those quirks that were fixed seemed to be fundamental issues with scoping, I'm amazed that they were solved so quickly. Apparently the rumours that you never sleep are true <g>.
Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dsa0p5$1tl7$1 digitaldaemon.com...
 Fantastic! In that case, I withdraw all other proposals I've made 
 regarding templates. The meta-programming template support seems to be 
 really quite solid now, from my original list of workarounds, the only one 
 that remains is
 digitalmars.com digitalmars.D.bugs:6004
 which I think you just missed, because you fixed the almost identical one 
 digitalmars.com digitalmars.D.bugs:6003.

The one about (a[x]) template arguments? That one turns out to be not so easy to solve, which is why I deferred it. The workaround (putting redundant parentheses around it) is ugly, but not onerous.
 Now, almost everything I try works as I'd hoped (and I've tried some 
 pretty wild stuff!). It tends to be unforgiving, in that some kinds of 
 syntax errors segfault the compiler instead of giving error messages; but 
 that does not prevent library development. It's possible to write really 
 elegant metafunctions now.

I still want any bug reports that produce seg faults.
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

It's because you and Eric offered a kick-ass response to those C++ people who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.
 Some of those quirks that were fixed seemed to be fundamental issues with 
 scoping, I'm amazed that they were solved so quickly. Apparently the 
 rumours that you never sleep are true <g>.

I originally thought the scope thing wasn't solvable. But the answer one day just popped into my head, I have no idea where it came from <g>.
Feb 07 2006
next sibling parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

It's because you and Eric offered a kick-ass response to those C++ people who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.

This might be a bit OT, but where may I find those examples? --Sebastián.
Feb 07 2006
next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Sebastián E. Peyrott" <as7cf yahoo.com> wrote in message 
news:dsb154$2ua8$1 digitaldaemon.com...
It's because you and Eric offered a kick-ass response to those C++ people
who denigrate D's templates as "not capable of metaprogramming." You and
Eric have shown that D templates enable much more powerful uses than C++
ones do, and look a lot better to boot. The regex example blew my socks 
off,
and I wanted to showcase it. That meant fixing D's templates so regex 
didn't
need all those ugly workarounds.

This might be a bit OT, but where may I find those examples?

http://trac.dsource.org/projects/ddl/browser/trunk/meta/regex.d
Feb 07 2006
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Sebastián E. Peyrott wrote:
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.

This might be a bit OT, but where may I find those examples? --Sebastián.

The "meta" package that Walter is referring to I believe lives at the DDL project on dsource.org. Somebody correct me if I'm wrong.
Feb 07 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <dsb5vt$2o2$1 digitaldaemon.com>, Kyle Furlong says...
Sebastián E. Peyrott wrote:
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.

This might be a bit OT, but where may I find those examples? --Sebastián.

The "meta" package that Walter is referring to I believe lives at the DDL project on dsource.org. Somebody correct me if I'm wrong.

Yes, that is correct: http://trac.dsource.org/projects/ddl/browser/trunk/meta/regex.d As Walter mentioned, there is much that he's improved with the compiler that obviates the need for some sillyness in the code. I don't know when I'll get around to improving it, but it's BSD licensed after all. Go nuts! - Eric Anderton at yahoo
Feb 07 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
pragma wrote:
 In article <dsb5vt$2o2$1 digitaldaemon.com>, Kyle Furlong says...
 Sebastián E. Peyrott wrote:
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.

--Sebastián.


Yes, that is correct: http://trac.dsource.org/projects/ddl/browser/trunk/meta/regex.d As Walter mentioned, there is much that he's improved with the compiler that obviates the need for some sillyness in the code. I don't know when I'll get around to improving it, but it's BSD licensed after all. Go nuts! - Eric Anderton at yahoo

Just out of curiosity, I wanted to run the regex example: auto exp = &regexMatch!("[a-z]*\s*\w*"); writefln("matches: %s",exp("hello world"); However the compilation fails with these errors: main.d(65): undefined escape sequence \s main.d(65): undefined escape sequence \w ... What's going on? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 08 2006
parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 pragma wrote:
 In article <dsb5vt$2o2$1 digitaldaemon.com>, Kyle Furlong says...
 Sebastián E. Peyrott wrote:
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

people who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot. The regex example blew my socks off, and I wanted to showcase it. That meant fixing D's templates so regex didn't need all those ugly workarounds.

--Sebastián.

DDL project on dsource.org. Somebody correct me if I'm wrong.

Yes, that is correct: http://trac.dsource.org/projects/ddl/browser/trunk/meta/regex.d As Walter mentioned, there is much that he's improved with the compiler that obviates the need for some sillyness in the code. I don't know when I'll get around to improving it, but it's BSD licensed after all. Go nuts! - Eric Anderton at yahoo

Just out of curiosity, I wanted to run the regex example: auto exp = &regexMatch!("[a-z]*\s*\w*"); writefln("matches: %s",exp("hello world"); However the compilation fails with these errors: main.d(65): undefined escape sequence \s main.d(65): undefined escape sequence \w ... What's going on?

Try making it a wysiwyg string or doubling up the backslashes. Sean
Feb 08 2006
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 pragma wrote:

 Just out of curiosity, I wanted to run the regex example:
     auto exp = &regexMatch!("[a-z]*\s*\w*");
     writefln("matches: %s",exp("hello    world");
 However the compilation fails with these errors:
         main.d(65): undefined escape sequence \s
         main.d(65): undefined escape sequence \w
     ...
 What's going on?

Try making it a wysiwyg string or doubling up the backslashes. Sean

Duh, silly me. Interesting though, didn't know D didn't accept undefined escape sequences. Seems good idea. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 08 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dsde2h$21n6$1 digitaldaemon.com...
 Duh, silly me. Interesting though, didn't know D didn't accept undefined 
 escape sequences. Seems good idea.

Accepting undefined escape sequences would shut the door on supporting any new escape sequences in the future.
Feb 08 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:dsa0p5$1tl7$1 digitaldaemon.com...
 Fantastic! In that case, I withdraw all other proposals I've made 
 regarding templates. The meta-programming template support seems to be 
 really quite solid now, from my original list of workarounds, the only one 
 that remains is
 digitalmars.com digitalmars.D.bugs:6004
 which I think you just missed, because you fixed the almost identical one 
 digitalmars.com digitalmars.D.bugs:6003.

The one about (a[x]) template arguments? That one turns out to be not so easy to solve, which is why I deferred it. The workaround (putting redundant parentheses around it) is ugly, but not onerous.

Indeed. It's just a mild imperfection. Wow, it's really hard to guess what's difficult to implement and what isn't. That one sounded really easy, whereas I guessed that the static if scoping issue was an intrinsic limitation of the parser.
 Now, almost everything I try works as I'd hoped (and I've tried some 
 pretty wild stuff!). It tends to be unforgiving, in that some kinds of 
 syntax errors segfault the compiler instead of giving error messages; but 
 that does not prevent library development. It's possible to write really 
 elegant metafunctions now.

I still want any bug reports that produce seg faults.
 I'm not sure how I managed to get your attention, but it's been an 
 exciting thing to be involved with.

It's because you and Eric offered a kick-ass response to those C++ people who denigrate D's templates as "not capable of metaprogramming." You and Eric have shown that D templates enable much more powerful uses than C++ ones do, and look a lot better to boot.

<g> C++ metaprogramming using partial template specialisation has always felt like drawing with a crayon. With static if, it's so easy. I found a C++ implementation of a compile-time PI calculation, extremely clever but hilariously unreadable. And I bet it took fifty times longer to write than mine did. The regex example blew my socks off,
 and I wanted to showcase it. That meant fixing D's templates so regex didn't 
 need all those ugly workarounds.

Time for that to move from proof-of-concept to some serious code, I think. If I only had some time...
Feb 08 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <dscv6f$1kks$1 digitaldaemon.com>, Don Clugston says...
The regex example blew my socks off,
 and I wanted to showcase it. That meant fixing D's templates so regex didn't 
 need all those ugly workarounds.

Time for that to move from proof-of-concept to some serious code, I think. If I only had some time...

Same here. - Eric Anderton at yahoo
Feb 08 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dscv6f$1kks$1 digitaldaemon.com...
 Walter Bright wrote:
 The one about (a[x]) template arguments? That one turns out to be not so 
 easy to solve, which is why I deferred it. The workaround (putting 
 redundant parentheses around it) is ugly, but not onerous.

what's difficult to implement and what isn't. That one sounded really easy, whereas I guessed that the static if scoping issue was an intrinsic limitation of the parser.

The trouble is that a[x] could be a type, or it could be an expression. Right now, it assumes it's a type, so it fails to match with a template expression parameter.
 <g> C++ metaprogramming using partial template specialisation has always 
 felt like drawing with a crayon. With static if, it's so easy.
 I found a C++ implementation of a compile-time PI calculation, extremely 
 clever but hilariously unreadable. And I bet it took fifty times longer to 
 write than mine did.

I'd really like a pointer to that, to use as a comparison. Such side-by-side comparisons really drive the point home, and so are very valuable.
 The regex example blew my socks off,
 and I wanted to showcase it. That meant fixing D's templates so regex 
 didn't need all those ugly workarounds.

If I only had some time...

Don't we all <g>. It'd be great to have it in place before SDWest, because then there'll be a surge of very influential people looking at it.
Feb 08 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:dscv6f$1kks$1 digitaldaemon.com...
 Walter Bright wrote:
 The one about (a[x]) template arguments? That one turns out to be not so 
 easy to solve, which is why I deferred it. The workaround (putting 
 redundant parentheses around it) is ugly, but not onerous.

what's difficult to implement and what isn't. That one sounded really easy, whereas I guessed that the static if scoping issue was an intrinsic limitation of the parser.

The trouble is that a[x] could be a type, or it could be an expression. Right now, it assumes it's a type, so it fails to match with a template expression parameter.
 <g> C++ metaprogramming using partial template specialisation has always 
 felt like drawing with a crayon. With static if, it's so easy.
 I found a C++ implementation of a compile-time PI calculation, extremely 
 clever but hilariously unreadable. And I bet it took fifty times longer to 
 write than mine did.

I'd really like a pointer to that, to use as a comparison. Such side-by-side comparisons really drive the point home, and so are very valuable.

It's in http://boost-consulting.com/vault/ in template metaprogramming, mpl_math.zip, boost/mpl/math/pi.hpp ---- C++ version (excerpt) ---------- // Copyright (C) 2005-2006 Cromwell D. Enage // Distributed under the Boost Software License, Version 1.0. [snip] template <typename NumericTag> struct pi : times< typename apply1< BOOST_MPL_AUX_NUMERIC_CAST< big_integral_tag , NumericTag > , big_integral<'+',4> >::type , minus< times< typename apply1< BOOST_MPL_AUX_NUMERIC_CAST< big_integral_tag , NumericTag > , big_integral<'+',4> >::type , arcus_tangent< reciprocal_integral<NumericTag,big_integral<'+',5> > > > , arcus_tangent< reciprocal_integral<NumericTag,big_integral<'+',2,3,9> > > > >::type { }; ---- D version ---------- const pi = 4.0 * (4*atan!(1/5.0) - atan!(1/239.0)); I think it makes the point rather well. It's also interesting to compare the implementation of atan!() with arcus_tangent<>; the latter defines a series using the preprocessor and hard-codes the number of terms to be used. You can trace atan!() all the way back and it never gets ugly (there are just a few simple metafunctions, each only a couple of lines long). However, the C++ version is still under active development (last update 2006-1-11). Maybe they can close the gap... Something you might mention is that much of the C++ compile-time stuff is performed during the optimisation pass. 100% of the D metaprogramming is performed during the semantic pass (and you can verify this by running the programs with the -c option, so that no object file is generated).
 The regex example blew my socks off,
 and I wanted to showcase it. That meant fixing D's templates so regex 
 didn't need all those ugly workarounds.

If I only had some time...

Don't we all <g>. It'd be great to have it in place before SDWest, because then there'll be a surge of very influential people looking at it.

Unfortunately, I won't be able to spend _any_ time on D in the next two weeks, so it will be tough. I had a look at the programme, it's perhaps a shame you're up against Dave Abrahams on metaprogramming, a lot of the target audience will hear him instead.
Feb 09 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:dseu57$p3p$1 digitaldaemon.com...
 Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:dscv6f$1kks$1 digitaldaemon.com...
 <g> C++ metaprogramming using partial template specialisation has always 
 felt like drawing with a crayon. With static if, it's so easy.
 I found a C++ implementation of a compile-time PI calculation, extremely 
 clever but hilariously unreadable. And I bet it took fifty times longer 
 to write than mine did.

I'd really like a pointer to that, to use as a comparison. Such side-by-side comparisons really drive the point home, and so are very valuable.

It's in http://boost-consulting.com/vault/ in template metaprogramming, mpl_math.zip, boost/mpl/math/pi.hpp

Thanks, this is exactly what I need.
 I think it makes the point rather well.

It sure does.
 However, the C++ version is still under active development (last update 
 2006-1-11). Maybe they can close the gap...

I doubt it. It isn't even on the same continent.
 Don't we all <g>. It'd be great to have it in place before SDWest, 
 because then there'll be a surge of very influential people looking at 
 it.

weeks, so it will be tough. I had a look at the programme, it's perhaps a shame you're up against Dave Abrahams on metaprogramming, a lot of the target audience will hear him instead.

Sadly, they put me in a poor time slot.
Feb 09 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au>
 Walter Bright wrote:
 "Don Clugston" <dac nospam.com.au>



 Don't we all <g>. It'd be great to have it in place before
 SDWest, because then there'll be a surge of very influential
 people looking at it.

Unfortunately, I won't be able to spend _any_ time on D in the next two weeks, so it will be tough. I had a look at the programme, it's perhaps a shame you're up against Dave Abrahams on metaprogramming, a lot of the target audience will hear him instead.

Sadly, they put me in a poor time slot.

Have no fear, there's _nothing_ one remembers so well as when one bets on the "safe" thing, and then on the break the hall is just bursting from what the other guy had said! That'll make them play catch-up and the buzz will go on for weeks. Thanks to this, next year you're the one with a line round the block!
Feb 14 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
 I'd say hold off on designing a template library without implicit
 function template instantiation.

That scentence is a little tricky for me, does that mean IFTI is expected for 1.0 ? Charlie "Walter Bright" <newshound digitalmars.com> wrote in message news:ds9tpg$1r87$1 digitaldaemon.com...
 "Don Clugston" <dac nospam.com.au> wrote in message
 news:ds9qaa$1of9$1 digitaldaemon.com...
 In one of the recent threads, there was a mention of blockers.
 One of these, I think, is the absence of any kind of a roadmap.
 No great detail is required, just a crude travel plan along the lines of
 "we'll go to Switzerland, but not until after we've visited Portugal".

 The most uncertain feature is also the most important:
 When will implicit function template instantiation be introduced?

 For example, it doesn't make sense to develop standard container classes
 without an answer to this question. Will it begin to happen in, say, the
 next ten releases? Or will the path to 1.0 be mainly bug fixes and minor
 tweaking?

 It seems that most other major confirmed features have been categorised


 "2.0" or "eventually, but not yet". But the timescale for IFTI is still
 very unclear.

The problem is these "must have" features keep coming up. I thought I'd

 implicit function template instantiation by now, but haven't even started

 it. I'd spent a lot of time working on the other template problems you
 uncovered. I'd say hold off on designing a template library without

 function template instantiation.

Feb 07 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Charles" <noone nowhere.com> wrote in message 
news:dsag9h$2cm8$1 digitaldaemon.com...
 I'd say hold off on designing a template library without implicit
 function template instantiation.

That scentence is a little tricky for me, does that mean IFTI is expected for 1.0 ?

Yes.
Feb 07 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Charles" <noone nowhere.com> wrote in message 
 news:dsag9h$2cm8$1 digitaldaemon.com...
 
I'd say hold off on designing a template library without implicit
function template instantiation.

That scentence is a little tricky for me, does that mean IFTI is expected for 1.0 ?

Yes.

Hooray!
Feb 07 2006
prev sibling next sibling parent "Charles" <noone nowhere.com> writes:
Yay!


"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsapit$2mfo$3 digitaldaemon.com...
 "Charles" <noone nowhere.com> wrote in message
 news:dsag9h$2cm8$1 digitaldaemon.com...
 I'd say hold off on designing a template library without implicit
 function template instantiation.

That scentence is a little tricky for me, does that mean IFTI is


 for 1.0 ?

Yes.

Feb 07 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Charles" <noone nowhere.com> wrote in message 
 news:dsag9h$2cm8$1 digitaldaemon.com...
 
I'd say hold off on designing a template library without implicit
function template instantiation.

That scentence is a little tricky for me, does that mean IFTI is expected for 1.0 ?

Yes.

Wow! I'm just breathless: incredible leaps!!!
Feb 14 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 The problem is these "must have" features keep coming up. I thought I'd have 
 implicit function template instantiation by now, but haven't even started on 
 it. I'd spent a lot of time working on the other template problems you 
 uncovered. I'd say hold off on designing a template library without implicit 
 function template instantiation.

Fantastic! Speculation on this issue was killing me :-) Sean
Feb 07 2006