Bug 1012 – cannot instantiate template with no or default arguments without !()

# class Bar(T = int){ # } # # void foo(T = int)(){ # } # # void main(){ # foo(); // success # auto b = new Bar(); // fails # } test.d(9): class test.Bar(T = int) is used as a type test.d(9): Error: new can only create structs, dynamic arrays or class objects, not void's

[email protected] wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=1012 > > Summary: type templates don't support default arguments > Product: D > Version: 1.007 > Platform: PC > OS/Version: All > Status: NEW > Severity: normal > Priority: P3 > Component: DMD > AssignedTo: [email protected] > ReportedBy: [email protected] > > > # class Bar(T = int){ > # } > # > # void foo(T = int)(){ > # } > # > # void main(){ > # foo(); // success > # auto b = new Bar(); // fails > # } > > test.d(9): class test.Bar(T = int) is used as a type > test.d(9): Error: new can only create structs, dynamic arrays or class objects, > not void's > > Are you allowed to leave out the !() in class template instantations? I'd expect to have to write auto b = new Bar!()(); or at least auto b = new Bar!();

Don Clugston wrote: > > Are you allowed to leave out the !() in class template instantations? No, but I think you perhaps should be allowed. I posted as much here asking for comments, but the thread got no replies: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=48672

AIUI this isn't supposed to work. If we allowed such implicit template instantiation everywhere, it would create ambiguities (alias declarations come to mind). That's why, at the moment, it's explicitly allowed in some contexts where it's unambiguous, such as IFTI and (to some degree) mixins.

Created attachment 466 convert TypeIdentifer refering to TemplateDeclaration to TypeInstance I don't expect any additional ambiguities, because the template types are in the same namespace as all other identifers anyway (apart from version and debug identifiers). This patch against 2.032 converts a TypeIdentifier (as created by the parser) into a TypeInstance if name lookup revealed that it is actually a template.

*** Issue 1328 has been marked as a duplicate of this issue. ***

D2 pull: https://github.com/D-Programming-Language/dmd/pull/1295

I have severe misgivings about this. C has had problems with implicitly taking the address of a function. D has had a number of problems with implicitly calling a function (the @property thing). It's just ambiguous in many cases, and leads to trouble, trouble, trouble.

> I have severe misgivings about this. I concur. It seems like it just begging for trouble when providing minimal gain. Not to mention that it would harm code readability in many cases, which will therefore harm code maintainability. issue# 6082 might be reasonable to implement (I don't know), in which case the example here would compile, but that would be restricted specifically to constructors. Making it so that templates in general can be instantiated without !() if they don't need any arguments is a bad idea IHMO. And I think that this post on the newsgroup is a good example of why this is a bad idea: http://forum.dlang.org/post/[email protected]

(In reply to comment #8) > issue# 6082 might be reasonable to implement (I don't know), It's not possible in the general case. http://stackoverflow.com/questions/13151072/ It might still be an attractive feature to have for specific, common cases, but it would either have to be defined as a "compiler's best effort" thing, which hurts portability, or defined to only work for a select few specific cases. The latter is what's currently done for IFTI, but the rules are intuitive, especially thanks to eponymous templates.

Here is a use case where the lack of this feature forces us to introduce an MonoTimeImpl template while keeping the default as MonoTime alias. https://github.com/D-Programming-Language/druntime/pull/990#issuecomment-59793264

*** Issue 18028 has been marked as a duplicate of this issue. ***

The current error message is a bit better: > test.d(9): Error: template class test.Bar(T = int) is used as a type without instantiation; to instantiate it use Bar!(arguments) Given that: - This bug has been open for 12 years - There is no consensus in the favor of this enhancement - Walter Bright has spoken against it It should clearly go through the DIP process to properly assess if there would be any corner cases, semantic or parsing wise.