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.


 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.


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.


 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.


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.


 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.


 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


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.


 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.


 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


 
 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.


 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.


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.


 Time for that to move from proof-of-concept to some serious code, I think. 
 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.


 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.


 
 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.


 Time for that to move from proof-of-concept to some serious code, I think. 
 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.


 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.
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




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
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




expected

 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