www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.77 release

reply "Walter" <walter digitalmars.com> writes:
Lots of new additions. Didn't get to most of the bug reports; I wanted to
get D to be 'feature complete' first, the next version will be bug
polishing. I'm setting sights on releasing D 1.0 by March.

Lots of improvements to templates:

o    No more instance keyword (though still supported for the time being).
To instantiate template Foo with arguments a,b use:
    Foo!(a,b)
which is equivalent to the C++:
    Foo<a,b>
but doesn't have parsing problems.

o If there's only one declaration in a template, and its name matches the
template name, it is 'promoted' to the enclosing scope:

    template Foo(T) { class Foo { T a,b; }}
    ...
    void func()
    {
        Foo(int) x;
        x.a = 3;
    }

o As a shortcut to the above, the template could have been written as:

    class Foo(T) { T a,b; }

There is no equivalent shortcut for function templates, the syntax would
look too awful. But this works:

    template Max(T) { T Max(T a, T b) { return ... ; } }
    ...
        x = Max!(int)(5,7);

o Templates can now take 'alias' parameters where any non-local symbol can
be substituted:

    template Foo(alias S) { int* x = &S; }

See the changelog for more cool stuff:

http://www.digitalmars.com/d/changelog.html
Jan 02 2004
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Fri, 02 Jan 2004 20:00:56 -0800, Walter wrote:


 Lots of new additions.


:)

but where is std.c.math ?

Ant
Jan 02 2004
parent "Walter" <walter digitalmars.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.01.03.04.53.11.207275 yahoo.ca...

 but where is std.c.math ?


It's there now.
Jan 03 2004
prev sibling next sibling parent Lewis <dethbomb hotmail.com> writes:
Walter wrote:


 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.
 
 Lots of improvements to templates:
 
 o    No more instance keyword (though still supported for the time being).
 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.
 
 o If there's only one declaration in a template, and its name matches the
 template name, it is 'promoted' to the enclosing scope:
 
     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }
 
 o As a shortcut to the above, the template could have been written as:
 
     class Foo(T) { T a,b; }
 
 There is no equivalent shortcut for function templates, the syntax would
 look too awful. But this works:
 
     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);
 
 o Templates can now take 'alias' parameters where any non-local symbol can
 be substituted:
 
     template Foo(alias S) { int* x = &S; }
 
 See the changelog for more cool stuff:
 
 http://www.digitalmars.com/d/changelog.html
 
 
 



Looks very impressive walter, keep up the excellent work!

yay   switch case expressionlist
Jan 03 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Wow. You've been busy!

Frankly speaking, I think the new templates just plain rock! ;)

Especially the alias mechanism is something that looks minor at first 
but could turn out to be very useful. It is now possibly to rename 
namespaces and just about everything else!

Great work!

Btw: the "name promotion" feature is missing in the docs on the website.

Hauke


Walter wrote:


 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.
 
 Lots of improvements to templates:
 
 o    No more instance keyword (though still supported for the time being).
 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.
 
 o If there's only one declaration in a template, and its name matches the
 template name, it is 'promoted' to the enclosing scope:
 
     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }
 
 o As a shortcut to the above, the template could have been written as:
 
     class Foo(T) { T a,b; }
 
 There is no equivalent shortcut for function templates, the syntax would
 look too awful. But this works:
 
     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);
 
 o Templates can now take 'alias' parameters where any non-local symbol can
 be substituted:
 
     template Foo(alias S) { int* x = &S; }
 
 See the changelog for more cool stuff:
 
 http://www.digitalmars.com/d/changelog.html
Jan 03 2004
prev sibling next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
About pragma's: couldn't these be implemented using versioning functionality
instead?

Each compiler defines an identifier as its version already, and proprietary
extensions would then have to be enclosed in such version sections.
For example:

version (DigitalMars) {
    __some_proprietary_keyword__ int x;
} else {
    int x;
}

Reasoning behind this: I tend to prefer minimalistic feature sets
Jan 03 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Jeroen van Bemmel wrote:


About pragma's: couldn't these be implemented using versioning functionality
instead?

Each compiler defines an identifier as its version already, and proprietary
extensions would then have to be enclosed in such version sections.
For example:

version (DigitalMars) {
    __some_proprietary_keyword__ int x;
} else {
    int x;
}

Reasoning behind this: I tend to prefer minimalistic feature sets


  


I think version and pragma are quite different beasts.  One is like a 
compile-time "if statement" while the other is like a compile time 
enable/disable.  What may be useful is if you can use versioning to 
determine if a pragma is enabled or not (or if it's in a particular state).

pragma(ident);

version (ident)
{
	//ident is enabled
}
Jan 03 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bt6dhd$6sm$1 digitaldaemon.com...

 About pragma's: couldn't these be implemented using versioning


functionality

 instead?

 Each compiler defines an identifier as its version already, and


proprietary

 extensions would then have to be enclosed in such version sections.
 For example:

 version (DigitalMars) {
     __some_proprietary_keyword__ int x;
 } else {
     int x;
 }


I'm pretty familiar with the proprietary keywords that are rampant in C and
C++, and how new proprietary syntaxes constantly appear and evolve. The
trouble with proprietary syntaxes is that different D compilers will not be
able to parse them even if they are protected with a version statement. With
the pragma syntax, proprietary extensions can be added in a way that other
compilers can parse even if they cannot handle it otherwise.


 Reasoning behind this: I tend to prefer minimalistic feature sets


I agree with you!
Jan 03 2004
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 I'm pretty familiar with the proprietary keywords that are rampant in C


and

 C++, and how new proprietary syntaxes constantly appear and evolve. The
 trouble with proprietary syntaxes is that different D compilers will not


be

 able to parse them even if they are protected with a version statement.


With

 the pragma syntax, proprietary extensions can be added in a way that other
 compilers can parse even if they cannot handle it otherwise.


OK, so what is the reason for parsing 'version' sections that are not
active?
Jan 03 2004
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
to find the end of the section?

dunno:D

In article <bt7gpe$1r0i$1 digitaldaemon.com>, Jeroen van Bemmel says...

 I'm pretty familiar with the proprietary keywords that are rampant in C


and

 C++, and how new proprietary syntaxes constantly appear and evolve. The
 trouble with proprietary syntaxes is that different D compilers will not


be

 able to parse them even if they are protected with a version statement.


With

 the pragma syntax, proprietary extensions can be added in a way that other
 compilers can parse even if they cannot handle it otherwise.


OK, so what is the reason for parsing 'version' sections that are not
active?
Jan 03 2004
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt7h59$1rfr$1 digitaldaemon.com...

 to find the end of the section?


OK, perhaps I should elaborate on my question: regular C compilers (or
actually their preprocessors) have to deal with "#ifdef {sym}" ... "#endif",
and their behavior when the expression evaluates to false is simply to skip
the contents until they encounter '#endif'

I would call this 'skipping' rather than 'parsing' (although technically it
is still parsing), hence my question: why parse it?

My thought was that the D compiler could do the same for version sections,
unless Walter had other reasons to do parsing of the sections (see his
posting)
Jan 03 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Jeroen van Bemmel wrote:

 My thought was that the D compiler could do the same for version sections,
 unless Walter had other reasons to do parsing of the sections (see his
 posting)


For a recursive descent, hand-written parser there is no problem. But 
for other compilers, which may be based off a perser generator (such as 
Bison used by Gnu) this would be a problem.

The difference, preprocessor does not do complete parsing. It only does 
lexing. And the logic to reject tokens is handwritten, bolted on top of 
the lexer. But since we don't want to have a preprocessor, but instead 
to parse the source directly...

-eye
Jan 04 2004
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 For a recursive descent, hand-written parser there is no problem. But
 for other compilers, which may be based off a perser generator (such as
 Bison used by Gnu) this would be a problem.

 The difference, preprocessor does not do complete parsing. It only does
 lexing. And the logic to reject tokens is handwritten, bolted on top of
 the lexer. But since we don't want to have a preprocessor, but instead
 to parse the source directly...


Yes, this all makes sense. I just wanted to understand the reasoning behind
some of these design choices, and I think it is important to document them
explicitly
(although D documentation is in pretty good shape already)

It follows then that the design lets potential other compiler versions
extend the language semantically (by adding pragma identifiers), but not
syntactically (by adding keywords) ?
Jan 04 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Jeroen van Bemmel wrote:

 It follows then that the design lets potential other compiler versions
 extend the language semantically (by adding pragma identifiers), but not
 syntactically (by adding keywords) ?


Wrong. You cannot prohobit anyone to make syntactic additions or add new 
  keywords. It's just that the users would need to think twice before 
they use such extentions, because they would radically disallow the 
source to be compiled by other compilers.

It would thus make sense for a compiler vendor, to provide extensions 
(possibly additionally) in the form of pragmas, so that the source can 
be reused for multiple different compilers. This particularly makes 
sense when writing code, which would be targeted at different machines 
with different compilers, but would only need the extensions within one 
of the targets.

Besides, if anyone makes a syntactic addition, it may break someone's 
code - so there should be a possibility to turn all such extensions off. 
Adding a pragme doesn't break any existing code, and need not be turned 
off for any reason.

-eye
Jan 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bta7m8$2np9$1 digitaldaemon.com...

 Jeroen van Bemmel wrote:

 It follows then that the design lets potential other compiler versions
 extend the language semantically (by adding pragma identifiers), but not
 syntactically (by adding keywords) ?




Yes.


 Wrong. You cannot prohobit anyone to make syntactic additions or add new
   keywords.


While you are technically correct, the idea is to provide vendors a sensible
way to add extensions that is endorsed by the D community and would be
backward compatible with D tools. Market pressure would presumably be the
enforcement tool, as it is with C/C++ standards compliance.


 It's just that the users would need to think twice before
 they use such extentions, because they would radically disallow the
 source to be compiled by other compilers.
 It would thus make sense for a compiler vendor, to provide extensions
 (possibly additionally) in the form of pragmas, so that the source can
 be reused for multiple different compilers. This particularly makes
 sense when writing code, which would be targeted at different machines
 with different compilers, but would only need the extensions within one
 of the targets.


Yes.


 Besides, if anyone makes a syntactic addition, it may break someone's
 code - so there should be a possibility to turn all such extensions off.
 Adding a pragme doesn't break any existing code, and need not be turned
 off for any reason.


Yes. Vendors need to be able to add extensions for special purposes for
their customers. Pragmas give them a way to do it that doesn't break other D
tools.
Jan 04 2004
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 Jeroen van Bemmel wrote:

 It follows then that the design lets potential other compiler versions
 extend the language semantically (by adding pragma identifiers), but






not

 syntactically (by adding keywords) ?




 Yes.


 Wrong. You cannot prohobit anyone to make syntactic additions or add new
   keywords.


 While you are technically correct, the idea is to provide vendors a


sensible

 way to add extensions that is endorsed by the D community and would be
 backward compatible with D tools. Market pressure would presumably be the
 enforcement tool, as it is with C/C++ standards compliance.


Of course anybody can write any parser they would like, I was referring to
the design intention of the 'pragma' feature.

This calls for a "100% pure D" certification program, with a syntax-only
checker that can approve compliant source files (i.e. without added
keywords) ;)
Jan 05 2004
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 This calls for a "100% pure D" certification program, with a syntax-only
 checker that can approve compliant source files (i.e. without added
 keywords) ;)


Whoops, misspelt it. That should be "100% pureD"
Jan 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:btcoss$vrf$1 digitaldaemon.com...

 This calls for a "100% pure D" certification program, with a syntax-only
 checker that can approve compliant source files (i.e. without added
 keywords) ;)


 Whoops, misspelt it. That should be "100% pureD"


Should we trademark "pureeD" ? <g>
Jan 05 2004
parent The Lone Haranguer <The_member pathlink.com> writes:
In article <btd0sq$1c00$1 digitaldaemon.com>, Walter says...

"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:btcoss$vrf$1 digitaldaemon.com...

 This calls for a "100% pure D" certification program, with a syntax-only
 checker that can approve compliant source files (i.e. without added
 keywords) ;)


 Whoops, misspelt it. That should be "100% pureD"


Should we trademark "pureeD" ? <g>


I like my code to be purdy.
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bt7gpe$1r0i$1 digitaldaemon.com...

 I'm pretty familiar with the proprietary keywords that are rampant in C


 and

 C++, and how new proprietary syntaxes constantly appear and evolve. The
 trouble with proprietary syntaxes is that different D compilers will not


 be

 able to parse them even if they are protected with a version statement.


 With

 the pragma syntax, proprietary extensions can be added in a way that




other

 compilers can parse even if they cannot handle it otherwise.


 OK, so what is the reason for parsing 'version' sections that are not
 active?


So things like syntax directed editors and other syntax analyzers will work.
Jan 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Walter

Is there a way to provide the equivalent to the following C/C++ in D?

#if defined(linux)
. . .
#elif defined(WIN32)
. . .
#else

#endif

like

version(Linux)
{
}
version(Windows)
{
}
else
{
  X
}

And have X not break the compilation for Linux and Windows, but break the
compilation (preferably with a meaningful message) for anything?

I have foundered on this a couple of times when writing libs. The ExeModule
had this issue, and if neither -version=Windows or -version=Linux is
specified, then it just gives some unintelligible error due to undefined
constructs.

And though I'm sure no-one would suggest it, relying on else to give Windows
in the absence of Linux, or vice versa, is just a future-platform-porting
landmine.

version(Linux)
{
}
else // Assuming Windows
{
  // What happens if we're building for Palm!?
}



"Walter" <walter digitalmars.com> wrote in message
news:bt7j5t$1ul2$1 digitaldaemon.com...

 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bt7gpe$1r0i$1 digitaldaemon.com...

 I'm pretty familiar with the proprietary keywords that are rampant in






C

 and

 C++, and how new proprietary syntaxes constantly appear and evolve.






The

 trouble with proprietary syntaxes is that different D compilers will






not

 be

 able to parse them even if they are protected with a version






statement.

 With

 the pragma syntax, proprietary extensions can be added in a way that




 other

 compilers can parse even if they cannot handle it otherwise.


 OK, so what is the reason for parsing 'version' sections that are not
 active?


 So things like syntax directed editors and other syntax analyzers will


work.





 Jan 03 2004



  parent reply "Walter" <walter digitalmars.com>  writes:


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bt7nh7$24ot$1 digitaldaemon.com...

 Is there a way to provide the equivalent to the following C/C++ in D?

 #if defined(linux)
 . . .
 #elif defined(WIN32)
 . . .
 #else

 #endif

 like

 version(Linux)
 {
 }
 version(Windows)
 {
 }
 else
 {
   X
 }

 And have X not break the compilation for Linux and Windows, but break the
 compilation (preferably with a meaningful message) for anything?


Replace X with:
    static assert(0);    // unimplemented version


 I have foundered on this a couple of times when writing libs. The


ExeModule

 had this issue, and if neither -version=Windows or -version=Linux is
 specified, then it just gives some unintelligible error due to undefined
 constructs.

 And though I'm sure no-one would suggest it, relying on else to give


Windows

 in the absence of Linux, or vice versa, is just a future-platform-porting
 landmine.


I agree. Don't do that <g>.



 Jan 03 2004



  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


"Walter" <walter digitalmars.com> wrote in message
news:bt7pts$28dc$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt7nh7$24ot$1 digitaldaemon.com...

 Is there a way to provide the equivalent to the following C/C++ in D?

 #if defined(linux)
 . . .
 #elif defined(WIN32)
 . . .
 #else

 #endif

 like

 version(Linux)
 {
 }
 version(Windows)
 {
 }
 else
 {
   X
 }

 And have X not break the compilation for Linux and Windows, but break




the

 compilation (preferably with a meaningful message) for anything?


 Replace X with:
     static assert(0);    // unimplemented version


Doh!. Of course. :)

Even better, would be

version(Linux)
{
}
version(Windows)
{
}
else
{
  const unrecognised_platform = 0;

  static assert(unrecognised_platform);
}

I take it that will be accepted by the compiler?


 I have foundered on this a couple of times when writing libs. The


 ExeModule

 had this issue, and if neither -version=Windows or -version=Linux is
 specified, then it just gives some unintelligible error due to undefined
 constructs.

 And though I'm sure no-one would suggest it, relying on else to give


 Windows

 in the absence of Linux, or vice versa, is just a




future-platform-porting

 landmine.


 I agree. Don't do that <g>.


Quick! Make a wish!

<G>



 Jan 03 2004



  parent reply "Walter" <walter digitalmars.com>  writes:


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bt7t0j$2cqr$1 digitaldaemon.com...

 Even better, would be

 version(Linux)
 {
 }
 version(Windows)
 {
 }
 else
 {
   const unrecognised_platform = 0;

   static assert(unrecognised_platform);
 }

 I take it that will be accepted by the compiler?


It should work.



 Jan 03 2004



  parent reply "Sean L. Palmer" <palmer.sean verizon.net>  writes:


But it won't do what you want, probably.

Won't that parse as:

version(Linux)
{
}

////

version(Windows)
{
}
else
{
  const unrecognised_platform = 0;
  static assert(unrecognised_platform); // will assert on Linux, even though
it's handled above
}

??  Anyway it's probably worth adding a unit test for.

Also, just browsing on the D website and I found this section on pragmas at
the bottom of the "Lexical" section.  Should it be
moved/integrated/otherwise reconciled with the new "pragmas" section?

Pragmas
Pragmas are special token sequences that give instructions to the compiler.
Pragmas are processed by the lexical analyzer, may appear between any other
tokens, and do not affect the syntax parsing.
There is currently only one pragma, the #line pragma.

	Pragma



	Filespec
		" Characters "
	This sets the source line number to Integer, and optionally the source file
name to Filespec, beginning with the next line of source text. The source
file and line number is used for printing error messages and for mapping
generated code back to the source for the symbolic debugging output.
For example:

	int #line 6 "foo\bar"
	x;			// this is now line 6 of file foo\bar
	Note that the backslash character is not treated specially inside Filespec
strings.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bt8397$2lkb$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bt7t0j$2cqr$1 digitaldaemon.com...

 Even better, would be

 version(Linux)
 {
 }
 version(Windows)
 {
 }
 else
 {
   const unrecognised_platform = 0;

   static assert(unrecognised_platform);
 }

 I take it that will be accepted by the compiler?


 It should work.





 Jan 04 2004



  parent  "Walter" <walter digitalmars.com>  writes:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt8q7h$lhb$1 digitaldaemon.com...

 But it won't do what you want, probably.

 Won't that parse as:

 version(Linux)
 {
 }

 ////

 version(Windows)
 {
 }
 else
 {
   const unrecognised_platform = 0;
   static assert(unrecognised_platform); // will assert on Linux, even


though

 it's handled above
 }


Sorry, an 'else' is needed in front of 'version(Windows)'.


 Also, just browsing on the D website and I found this section on pragmas


at

 the bottom of the "Lexical" section.  Should it be
 moved/integrated/otherwise reconciled with the new "pragmas" section?

 Pragmas
 Pragmas are special token sequences that give instructions to the


compiler.

 Pragmas are processed by the lexical analyzer, may appear between any


other

 tokens, and do not affect the syntax parsing.
 There is currently only one pragma, the #line pragma.


That has nothing to do with the new pragma construct, I need to fix the
documentation.



 Jan 04 2004



prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Walter wrote:


o    No more instance keyword (though still supported for the time being).
To instantiate template Foo with arguments a,b use:
  


Does this imply that your going to remove the instance keyword some time 
in the future? 

If so, it might be a good idea, to remove it from the example 
documentation (such as on 
http://www.digitalmars.com/d/declaration.html#alias), to prevent new 
users from using it.

PS - Sorry if I'm stating the obvious.



 Jan 03 2004



 next sibling parent  "Carlos Santander B." <carlos8294 msn.com>  writes:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bt6jc4$flc$1 digitaldaemon.com...
| Walter wrote:
|
| >o    No more instance keyword (though still supported for the time
being).
| >To instantiate template Foo with arguments a,b use:
| >
| >
| Does this imply that your going to remove the instance keyword some time
| in the future?
|
| If so, it might be a good idea, to remove it from the example
| documentation (such as on
| http://www.digitalmars.com/d/declaration.html#alias), to prevent new
| users from using it.
|
| PS - Sorry if I'm stating the obvious.
|

Also it should be removed from error messages. This code:

class A(T) { T b; this(T _b) { b=_b; } }
void main() {
        A!(int) a = new A!(3);
}

Produces this message: "instance A(3) does not match any template
declaration".

Also, if I change the assignment to "new A!;" (wrong, obviously), dmd
crashes.

-----------------------
Carlos Santander Bernal



 Jan 03 2004



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bt6jc4$flc$1 digitaldaemon.com...

 Walter wrote:


o    No more instance keyword (though still supported for the time




being).

To instantiate template Foo with arguments a,b use:


 Does this imply that your going to remove the instance keyword some time
 in the future?


Yes.


 If so, it might be a good idea, to remove it from the example
 documentation (such as on
 http://www.digitalmars.com/d/declaration.html#alias), to prevent new
 users from using it.


There's a spot I missed!


 PS - Sorry if I'm stating the obvious.


Stating the obvious is always a good idea, because often one misses the
obvious.



 Jan 03 2004



  parent  "Luna Kid" <lunakid neuropolis.org>  writes:


 PS - Sorry if I'm stating the obvious.


 Stating the obvious is always a good idea, because often one misses the
 obvious.


Wow, this is a nice one, straight
from the Book of Ethernal Wisdom! ;)

Cheers,
Sz.



 Jan 04 2004



prev sibling next sibling parent  "Robert" <no spam.ne.jp>  writes:


How Great!
Typeof properties and new features of templates are what I've been waiting
for.


BTW, though class templates can be very easily declared,
function templates, alias templates, etc. are not.
I think that template declaration like C++ is useful for the sake.

template(T) T max(T a, T b) {
    return a > b ? a : b;
}

It also looks like an attribute.



 Jan 03 2004



prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net>  writes:


Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit
instantiation, but it's better than it was.  It seems this syntax won't
conflict with use of ! as logical not.

I noticed a doc bug (I think),  in typeof section:

int[typeof[p]] a;	// a is of type int[int*]

Shouldn't that be typeof(p)?

Multiple case expressions are good.  Adding goto case opens the door for
later removing implicit fallthru (D 2.0?) so I see that as good also.

Walter, do you see the template "limitations" being lifted in the future?

Since there were conflicts between std.intrinsic and std.math fixed, I will
try my D3D test again using 0.77.. thanks!

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:

 o    No more instance keyword (though still supported for the time being).
 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.

 o If there's only one declaration in a template, and its name matches the
 template name, it is 'promoted' to the enclosing scope:

     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }

 o As a shortcut to the above, the template could have been written as:

     class Foo(T) { T a,b; }

 There is no equivalent shortcut for function templates, the syntax would
 look too awful. But this works:

     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);

 o Templates can now take 'alias' parameters where any non-local symbol can
 be substituted:

     template Foo(alias S) { int* x = &S; }

 See the changelog for more cool stuff:

 http://www.digitalmars.com/d/changelog.html





 Jan 03 2004



 next sibling parent  "Walter" <walter digitalmars.com>  writes:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt79le$1gb0$1 digitaldaemon.com...

 Walter, do you see the template "limitations" being lifted in the future?


At the moment, we'll see how far we get with things as they are.



 Jan 03 2004



prev sibling  parent reply "Ben Hinkle" <bhinkle4 juno.com>  writes:


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt79le$1gb0$1 digitaldaemon.com...

 Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit
 instantiation, but it's better than it was.  It seems this syntax won't
 conflict with use of ! as logical not.


What are the common use cases for implicit instantiation? Actually, the only
ones I can think of off the top of my head are function templates. The
example Walter gave:


     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);




seems pretty compact and readable. The implicit form would be x = Max(5,7);
(right? I can't even remember since the times I've used templates recently
have been STL container stuff of the form vector<int> etc).

 I'm psyched about 0.77. It is definitely an improvement in the template
support.
-Ben



 Jan 03 2004



 next sibling parent  Andy Friesen <andy ikagames.com>  writes:


Ben Hinkle wrote:


 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bt79le$1gb0$1 digitaldaemon.com...
 

Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit
instantiation, but it's better than it was.  It seems this syntax won't
conflict with use of ! as logical not.


 
 
 What are the common use cases for implicit instantiation? Actually, the only
 ones I can think of off the top of my head are function templates. The
 example Walter gave:
 
 

    template Max(T) { T Max(T a, T b) { return ... ; } }
    ...
        x = Max!(int)(5,7);




 
 
 seems pretty compact and readable. The implicit form would be x = Max(5,7);
 (right? I can't even remember since the times I've used templates recently
 have been STL container stuff of the form vector<int> etc).
 
  I'm psyched about 0.77. It is definitely an improvement in the template
 support.
 -Ben


I've used implicit instantiation as an uber-alias in C++ before.

template <typename A, typename B, typename C, typename D>
Tuple<A, Tuple<B, Tuple<C, Tuple<D, NoneType> > > >
     bind(A a, B b, C c, D d) {
         /* You don't want to see this.  Trust me. */
}

(mostly joking.  mostly)

  -- andy



 Jan 03 2004



prev sibling  parent reply davepermen <davepermen_member pathlink.com>  writes:


the current "implicit" way is to specify the type based on some parameter..
thanks to typeof, that works

int x = max!(typeof(a))(a,b);

not _that_ implicit, but at least, you don't have to know the type..

if the type parameters would be in !( )! braces, we could even implement a
deduction method.. like this:

int x = max!(int)!(a,b);

for manual instantiation

int x = max!(typeof(a))!(a,b);

we want it to be the first passed type as first passed template type, too

int x = max!!(a,b);

just do the typeof(a) yourself..

so if you call a templated method with two !!, and no () in between, it just
takes the argumentlist (in this case, a,b) and takes typeof till all template
parameters are filled


would be implicit enough for me, i guess


In article <bt83f5$2lut$1 digitaldaemon.com>, Ben Hinkle says...

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt79le$1gb0$1 digitaldaemon.com...

 Most excellent!  See, Walter *does* listen to us.  ;)  It's not implicit
 instantiation, but it's better than it was.  It seems this syntax won't
 conflict with use of ! as logical not.


What are the common use cases for implicit instantiation? Actually, the only
ones I can think of off the top of my head are function templates. The
example Walter gave:


     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);




seems pretty compact and readable. The implicit form would be x = Max(5,7);
(right? I can't even remember since the times I've used templates recently
have been STL container stuff of the form vector<int> etc).

 I'm psyched about 0.77. It is definitely an improvement in the template
support.
-Ben





 Jan 04 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


davepermen wrote:


the current "implicit" way is to specify the type based on some parameter..
thanks to typeof, that works

int x = max!(typeof(a))(a,b);

not _that_ implicit, but at least, you don't have to know the type..

if the type parameters would be in !( )! braces, we could even implement a
deduction method.. like this:

int x = max!(int)!(a,b);

for manual instantiation

int x = max!(typeof(a))!(a,b);

we want it to be the first passed type as first passed template type, too

int x = max!!(a,b);

just do the typeof(a) yourself..

so if you call a templated method with two !!, and no () in between, it just
takes the argumentlist (in this case, a,b) and takes typeof till all template
parameters are filled


would be implicit enough for me, i guess

  


I really like this idea!



 Jan 04 2004



  parent  davepermen <davepermen_member pathlink.com>  writes:


thanks

In article <bt99h5$1be7$1 digitaldaemon.com>, J Anderson says...

davepermen wrote:


the current "implicit" way is to specify the type based on some parameter..
thanks to typeof, that works

int x = max!(typeof(a))(a,b);

not _that_ implicit, but at least, you don't have to know the type..

if the type parameters would be in !( )! braces, we could even implement a
deduction method.. like this:

int x = max!(int)!(a,b);

for manual instantiation

int x = max!(typeof(a))!(a,b);

we want it to be the first passed type as first passed template type, too

int x = max!!(a,b);

just do the typeof(a) yourself..

so if you call a templated method with two !!, and no () in between, it just
takes the argumentlist (in this case, a,b) and takes typeof till all template
parameters are filled


would be implicit enough for me, i guess

  


I really like this idea!





 Jan 04 2004



prev sibling  parent reply "Robert" <no spam.ne.jp>  writes:


I've thought the similar idea.
I think following syntax:

int x = max?(a, b);

! denotes explicit and ? denotes implicit.


"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt992p$1b32$1 digitaldaemon.com...

 the current "implicit" way is to specify the type based on some


parameter..

 thanks to typeof, that works

 int x = max!(typeof(a))(a,b);

 not _that_ implicit, but at least, you don't have to know the type..

 if the type parameters would be in !( )! braces, we could even implement a
 deduction method.. like this:

 int x = max!(int)!(a,b);

 for manual instantiation

 int x = max!(typeof(a))!(a,b);

 we want it to be the first passed type as first passed template type, too

 int x = max!!(a,b);

 just do the typeof(a) yourself..

 so if you call a templated method with two !!, and no () in between, it


just

 takes the argumentlist (in this case, a,b) and takes typeof till all


template

 parameters are filled


 would be implicit enough for me, i guess


 In article <bt83f5$2lut$1 digitaldaemon.com>, Ben Hinkle says...

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt79le$1gb0$1 digitaldaemon.com...

 Most excellent!  See, Walter *does* listen to us.  ;)  It's not






implicit

 instantiation, but it's better than it was.  It seems this syntax won't
 conflict with use of ! as logical not.


What are the common use cases for implicit instantiation? Actually, the




only

ones I can think of off the top of my head are function templates. The
example Walter gave:


     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);




seems pretty compact and readable. The implicit form would be x =




Max(5,7);

(right? I can't even remember since the times I've used templates




recently

have been STL container stuff of the form vector<int> etc).

 I'm psyched about 0.77. It is definitely an improvement in the template
support.
-Ben







 Jan 04 2004



 next sibling parent reply davepermen <davepermen_member pathlink.com>  writes:


even more cool!!

In article <bt9u5g$29tj$1 digitaldaemon.com>, Robert says...

I've thought the similar idea.
I think following syntax:

int x = max?(a, b);

! denotes explicit and ? denotes implicit.


"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt992p$1b32$1 digitaldaemon.com...

 the current "implicit" way is to specify the type based on some


parameter..

 thanks to typeof, that works

 int x = max!(typeof(a))(a,b);

 not _that_ implicit, but at least, you don't have to know the type..

 if the type parameters would be in !( )! braces, we could even implement a
 deduction method.. like this:

 int x = max!(int)!(a,b);

 for manual instantiation

 int x = max!(typeof(a))!(a,b);

 we want it to be the first passed type as first passed template type, too

 int x = max!!(a,b);

 just do the typeof(a) yourself..

 so if you call a templated method with two !!, and no () in between, it


just

 takes the argumentlist (in this case, a,b) and takes typeof till all


template

 parameters are filled


 would be implicit enough for me, i guess


 In article <bt83f5$2lut$1 digitaldaemon.com>, Ben Hinkle says...

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt79le$1gb0$1 digitaldaemon.com...

 Most excellent!  See, Walter *does* listen to us.  ;)  It's not






implicit

 instantiation, but it's better than it was.  It seems this syntax won't
 conflict with use of ! as logical not.


What are the common use cases for implicit instantiation? Actually, the




only

ones I can think of off the top of my head are function templates. The
example Walter gave:


     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);




seems pretty compact and readable. The implicit form would be x =




Max(5,7);

(right? I can't even remember since the times I've used templates




recently

have been STL container stuff of the form vector<int> etc).

 I'm psyched about 0.77. It is definitely an improvement in the template
support.
-Ben









 Jan 04 2004



  parent  Matthias Becker <Matthias_member pathlink.com>  writes:


I don't like this !!, !()!, ... stuff. Eigther leav it as it is or use the ?
addition.



 Jan 05 2004



prev sibling  parent  "Sean L. Palmer" <palmer.sean verizon.net>  writes:


That seems as if it would conflict with ?: operator.

But you guys are on the right track, IMHO.

Sean

"Robert" <no spam.ne.jp> wrote in message
news:bt9u5g$29tj$1 digitaldaemon.com...

 I've thought the similar idea.
 I think following syntax:

 int x = max?(a, b);

 ! denotes explicit and ? denotes implicit.


 "davepermen" <davepermen_member pathlink.com> wrote in message
 news:bt992p$1b32$1 digitaldaemon.com...

 the current "implicit" way is to specify the type based on some


 parameter..

 thanks to typeof, that works

 int x = max!(typeof(a))(a,b);

 not _that_ implicit, but at least, you don't have to know the type..
 ...
 int x = max!!(a,b);

 just do the typeof(a) yourself..

 so if you call a templated method with two !!, and no () in between, it


 just

 takes the argumentlist (in this case, a,b) and takes typeof till all


 template

 parameters are filled


 would be implicit enough for me, i guess







 Jan 05 2004



prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net>  writes:


This module causes an internal error "Internal error: e2ir.c 133":   (I'm
also having trouble with it not thinking dim and tfloat are defined in some
other methods... still trying to track that down)

module vector;

import std.intrinsic;

import std.math;

public:

template VecTemplate(tfloat, int dim)

{

struct Vector

{

tfloat d[dim];

Vector opMul(tfloat b) { Vector r; for (int i=0; i<dim; ++i) r.d[i] = d[i] *
b; return r; }

Vector opDiv(tfloat b) { return *this * (1/b); }

tfloat opMul(Vector b) { tfloat r=0; for (int i=0; i<dim; ++i) r += d[i];
return r; }

}

tfloat sqr(Vector v)

{

return v * v;

}

tfloat abs(Vector v)

{

return sqrt(sqr(v));

}

}

alias VecTemplate!(float,2) V2;

alias V2.Vector Vector2;

unittest

{

float n;

Vector2 a,b,c;

n = V2.sqr(a);

n = V2.abs(a);

n = V2.abs(b-a);

}



I'm not sure what to do about template methods sqr, abs, etc, as their
namespace must be explicitly indicated... what I have above (V2 alias) is
the most elegant solution I thought of so far.

I think foreach has the potential to really clean up the implementation of
this Vector template, and if I give it an opApply it will help users out
too.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:

 o    No more instance keyword (though still supported for the time being).
 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.

 o If there's only one declaration in a template, and its name matches the
 template name, it is 'promoted' to the enclosing scope:

     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }

 o As a shortcut to the above, the template could have been written as:

     class Foo(T) { T a,b; }

 There is no equivalent shortcut for function templates, the syntax would
 look too awful. But this works:

     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);

 o Templates can now take 'alias' parameters where any non-local symbol can
 be substituted:

     template Foo(alias S) { int* x = &S; }

 See the changelog for more cool stuff:

 http://www.digitalmars.com/d/changelog.html





 Jan 03 2004



 next sibling parent reply "C" <dont respond.com>  writes:


Are your writing several collection classes ?  If so can you post when your
done ?

C


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt7cbt$1k9n$1 digitaldaemon.com...

 This module causes an internal error "Internal error: e2ir.c 133":   (I'm
 also having trouble with it not thinking dim and tfloat are defined in


some

 other methods... still trying to track that down)

 module vector;

 import std.intrinsic;

 import std.math;

 public:

 template VecTemplate(tfloat, int dim)

 {

 struct Vector

 {

 tfloat d[dim];

 Vector opMul(tfloat b) { Vector r; for (int i=0; i<dim; ++i) r.d[i] = d[i]


*

 b; return r; }

 Vector opDiv(tfloat b) { return *this * (1/b); }

 tfloat opMul(Vector b) { tfloat r=0; for (int i=0; i<dim; ++i) r += d[i];
 return r; }

 }

 tfloat sqr(Vector v)

 {

 return v * v;

 }

 tfloat abs(Vector v)

 {

 return sqrt(sqr(v));

 }

 }

 alias VecTemplate!(float,2) V2;

 alias V2.Vector Vector2;

 unittest

 {

 float n;

 Vector2 a,b,c;

 n = V2.sqr(a);

 n = V2.abs(a);

 n = V2.abs(b-a);

 }



 I'm not sure what to do about template methods sqr, abs, etc, as their
 namespace must be explicitly indicated... what I have above (V2 alias) is
 the most elegant solution I thought of so far.

 I think foreach has the potential to really clean up the implementation of
 this Vector template, and if I give it an opApply it will help users out
 too.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted




to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:

 o    No more instance keyword (though still supported for the time




being).

 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.

 o If there's only one declaration in a template, and its name matches




the

 template name, it is 'promoted' to the enclosing scope:

     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }

 o As a shortcut to the above, the template could have been written as:

     class Foo(T) { T a,b; }

 There is no equivalent shortcut for function templates, the syntax would
 look too awful. But this works:

     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);

 o Templates can now take 'alias' parameters where any non-local symbol




can

 be substituted:

     template Foo(alias S) { int* x = &S; }

 See the changelog for more cool stuff:

 http://www.digitalmars.com/d/changelog.html







 Jan 03 2004



 next sibling parent  "C" <dont respond.com>  writes:


Err, ignore me.

C
"C" <dont respond.com> wrote in message
news:bt7cig$1kmb$1 digitaldaemon.com...

 Are your writing several collection classes ?  If so can you post when


your

 done ?

 C


 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bt7cbt$1k9n$1 digitaldaemon.com...

 This module causes an internal error "Internal error: e2ir.c 133":




(I'm

 also having trouble with it not thinking dim and tfloat are defined in


 some

 other methods... still trying to track that down)

 module vector;

 import std.intrinsic;

 import std.math;

 public:

 template VecTemplate(tfloat, int dim)

 {

 struct Vector

 {

 tfloat d[dim];

 Vector opMul(tfloat b) { Vector r; for (int i=0; i<dim; ++i) r.d[i] =




d[i]

 *

 b; return r; }

 Vector opDiv(tfloat b) { return *this * (1/b); }

 tfloat opMul(Vector b) { tfloat r=0; for (int i=0; i<dim; ++i) r +=




d[i];

 return r; }

 }

 tfloat sqr(Vector v)

 {

 return v * v;

 }

 tfloat abs(Vector v)

 {

 return sqrt(sqr(v));

 }

 }

 alias VecTemplate!(float,2) V2;

 alias V2.Vector Vector2;

 unittest

 {

 float n;

 Vector2 a,b,c;

 n = V2.sqr(a);

 n = V2.abs(a);

 n = V2.abs(b-a);

 }



 I'm not sure what to do about template methods sqr, abs, etc, as their
 namespace must be explicitly indicated... what I have above (V2 alias)




is

 the most elegant solution I thought of so far.

 I think foreach has the potential to really clean up the implementation




of

 this Vector template, and if I give it an opApply it will help users out
 too.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted







 to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:

 o    No more instance keyword (though still supported for the time




 being).

 To instantiate template Foo with arguments a,b use:
     Foo!(a,b)
 which is equivalent to the C++:
     Foo<a,b>
 but doesn't have parsing problems.

 o If there's only one declaration in a template, and its name matches




 the

 template name, it is 'promoted' to the enclosing scope:

     template Foo(T) { class Foo { T a,b; }}
     ...
     void func()
     {
         Foo(int) x;
         x.a = 3;
     }

 o As a shortcut to the above, the template could have been written as:

     class Foo(T) { T a,b; }

 There is no equivalent shortcut for function templates, the syntax






would

 look too awful. But this works:

     template Max(T) { T Max(T a, T b) { return ... ; } }
     ...
         x = Max!(int)(5,7);

 o Templates can now take 'alias' parameters where any non-local symbol




 can

 be substituted:

     template Foo(alias S) { int* x = &S; }

 See the changelog for more cool stuff:

 http://www.digitalmars.com/d/changelog.html









 Jan 03 2004



prev sibling  parent  "Sean L. Palmer" <palmer.sean verizon.net>  writes:


I'm mostly just working on mathematical vectors/matrices; personally I'm
happy with builtin arrays and associative arrays for 99% of what I do.  I'm
sure others on this NG are or will be working on collection templates.

Sean

"C" <dont respond.com> wrote in message
news:bt7cig$1kmb$1 digitaldaemon.com...

 Are your writing several collection classes ?  If so can you post when


your

 done ?

 C





 Jan 03 2004



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


I cannot reproduce the error. What compiler switches did you use?

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt7cbt$1k9n$1 digitaldaemon.com...

 This module causes an internal error "Internal error: e2ir.c 133":





 Jan 04 2004



  parent  "Sean L. Palmer" <palmer.sean verizon.net>  writes:


\dmd\bin\dmd -g -debug -unittest -version=debug -c vector

on vector.d

You are probably missing the -unittest, which would cause the bug not to
happen (I commented out the unit test and the bug went away)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bt8kvi$e46$1 digitaldaemon.com...

 I cannot reproduce the error. What compiler switches did you use?

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bt7cbt$1k9n$1 digitaldaemon.com...

 This module causes an internal error "Internal error: e2ir.c 133":







 Jan 04 2004



prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net>  writes:


I'm running into a situation where function bodies inside templates are
instantiated and checked even if that instantiation is never used.  This is
causing problems, in that I can't provide, say, setters that take more
parameters than the vector template was instantiated with.  Those errors
should happen during instantiation, but the instantiation should happen at
point of call, not point of template instantiation.  You probably also can't
have methods that utilize properties or methods of template parameters that
some may have and others may not (such as ++ on float) even if the method is
never actually used.

C++ dealt with this by mandating implementations not expand and check
template methods until they are used.

Sean

module vector;

import std.intrinsic;

import std.math;

public:

template VecTemplate(tfloat, int dim)

{

struct Vector

{

tfloat d[dim];


void set(tfloat r) { foreach(inout tfloat v; d) v = r; }

void set(tfloat a0,tfloat a1) { d[0] = a0; d[1] = a1; for(int i=2; i<dim;
++i) d[i] = 0; }

void set(tfloat a0,tfloat a1,tfloat a2) { d[0] = a0; d[1] = a1; d[2] = a2;
for(int i=3; i<dim; ++i) d[i] = 0; } // error... d[2] is outside allowed
range, but this function is never called!

void set(tfloat a0,tfloat a1,tfloat a2,tfloat a3) { d[0] = a0; d[1] = a1;
d[2] = a2; d[3] = a3; for(int i=4; i<dim; ++i) d[i] = 0; } // error... d[2]
is outside allowed range

void set(tfloat[dim] r) { for (int i=0; i<dim; ++i) d[i] = r[i]; }

}
}
alias VecTemplate!(float,2) V2;

alias V2.Vector Vector2;

unittest

{

Vector2 b;

b.set(0);

b.set(0,1);

}

"Walter" <walter digitalmars.com> wrote in message
news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:





 Jan 03 2004



  parent  "Walter" <walter digitalmars.com>  writes:


I understand the problem. It might be a bit difficult to correct, though. In
the meantime, to workaround, make the 2 a variable instead.

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bt7d5u$1lgq$1 digitaldaemon.com...

 I'm running into a situation where function bodies inside templates are
 instantiated and checked even if that instantiation is never used.  This


is

 causing problems, in that I can't provide, say, setters that take more
 parameters than the vector template was instantiated with.  Those errors
 should happen during instantiation, but the instantiation should happen at
 point of call, not point of template instantiation.  You probably also


can't

 have methods that utilize properties or methods of template parameters


that

 some may have and others may not (such as ++ on float) even if the method


is

 never actually used.

 C++ dealt with this by mandating implementations not expand and check
 template methods until they are used.

 Sean

 module vector;

 import std.intrinsic;

 import std.math;

 public:

 template VecTemplate(tfloat, int dim)

 {

 struct Vector

 {

 tfloat d[dim];


 void set(tfloat r) { foreach(inout tfloat v; d) v = r; }

 void set(tfloat a0,tfloat a1) { d[0] = a0; d[1] = a1; for(int i=2; i<dim;
 ++i) d[i] = 0; }

 void set(tfloat a0,tfloat a1,tfloat a2) { d[0] = a0; d[1] = a1; d[2] = a2;
 for(int i=3; i<dim; ++i) d[i] = 0; } // error... d[2] is outside allowed
 range, but this function is never called!

 void set(tfloat a0,tfloat a1,tfloat a2,tfloat a3) { d[0] = a0; d[1] = a1;
 d[2] = a2; d[3] = a3; for(int i=4; i<dim; ++i) d[i] = 0; } // error...


d[2]

 is outside allowed range

 void set(tfloat[dim] r) { for (int i=0; i<dim; ++i) d[i] = r[i]; }

 }
 }
 alias VecTemplate!(float,2) V2;

 alias V2.Vector Vector2;

 unittest

 {

 Vector2 b;

 b.set(0);

 b.set(0,1);

 }

 "Walter" <walter digitalmars.com> wrote in message
 news:bt5esp$1o8d$1 digitaldaemon.com...

 Lots of new additions. Didn't get to most of the bug reports; I wanted




to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.

 Lots of improvements to templates:







 Jan 04 2004



prev sibling next sibling parent  davepermen <davepermen_member pathlink.com>  writes:


how about, instead of the promoting, following more the C++ syntax directly?

template(T) T max(T a,T b) { return a > b ? a : b; }

as equivalent to the current

template max(T) { T max(T a,T b) { return a > b ? a : b; } }

i don't see any syntactical problems with this.. and for the classes, that would
work, too

template(T) class Container {
private T[] data;
}

instead of

template Container(T) { class Container {
private T[] data;
} }

or

class Container(T) {
private T[] data;
}

yes, the last is shorter, but i like to have a template keyword in each template
declaration... btw, how do you create such a Container?

Container!(int) x = new Container!(int)(ctor-params here?);

because .77 just plain crashes all the time..

In article <bt5esp$1o8d$1 digitaldaemon.com>, Walter says...

Lots of new additions. Didn't get to most of the bug reports; I wanted to
get D to be 'feature complete' first, the next version will be bug
polishing. I'm setting sights on releasing D 1.0 by March.

Lots of improvements to templates:

o    No more instance keyword (though still supported for the time being).
To instantiate template Foo with arguments a,b use:
    Foo!(a,b)
which is equivalent to the C++:
    Foo<a,b>
but doesn't have parsing problems.

o If there's only one declaration in a template, and its name matches the
template name, it is 'promoted' to the enclosing scope:

    template Foo(T) { class Foo { T a,b; }}
    ...
    void func()
    {
        Foo(int) x;
        x.a = 3;
    }

o As a shortcut to the above, the template could have been written as:

    class Foo(T) { T a,b; }

There is no equivalent shortcut for function templates, the syntax would
look too awful. But this works:

    template Max(T) { T Max(T a, T b) { return ... ; } }
    ...
        x = Max!(int)(5,7);

o Templates can now take 'alias' parameters where any non-local symbol can
be substituted:

    template Foo(alias S) { int* x = &S; }

See the changelog for more cool stuff:

http://www.digitalmars.com/d/changelog.html





 Jan 03 2004



prev sibling  parent reply Brad Anderson <brad sankaty.com>  writes:


Walter wrote:

 Lots of new additions. Didn't get to most of the bug reports; I wanted to
 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.


If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the fourth 
planet...  too much coffee today.



 Jan 05 2004



 next sibling parent  "Matthew" <matthew.hat stlsoft.dot.org>  writes:


I like that.

Also, it gives enough time for some of the outstanding important library
stuff to happen.

"Brad Anderson" <brad sankaty.com> wrote in message
news:btcq7t$10fd$1 digitaldaemon.com...

 Walter wrote:

 Lots of new additions. Didn't get to most of the bug reports; I wanted




to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.


 If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the


fourth

 planet...  too much coffee today.





 Jan 05 2004



prev sibling  parent reply "Phill" <phill pacific.net.au>  writes:


Thats a bad number for the Chinese, very similar to
Death.


"Brad Anderson" <brad sankaty.com> wrote in message
news:btcq7t$10fd$1 digitaldaemon.com...

 Walter wrote:

 Lots of new additions. Didn't get to most of the bug reports; I wanted




to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.


 If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the


fourth

 planet...  too much coffee today.





 Jan 07 2004



  parent reply "Robert" <no spam.ne.jp>  writes:


Also for the Japanese.
It's no wonder since they are loanwords from Chinese.

"Phill" <phill pacific.net.au> wrote in message
news:btgi8s$qre$1 digitaldaemon.com...

 Thats a bad number for the Chinese, very similar to
 Death.


 "Brad Anderson" <brad sankaty.com> wrote in message
 news:btcq7t$10fd$1 digitaldaemon.com...

 Walter wrote:

 Lots of new additions. Didn't get to most of the bug reports; I wanted




 to

 get D to be 'feature complete' first, the next version will be bug
 polishing. I'm setting sights on releasing D 1.0 by March.


 If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the


 fourth

 planet...  too much coffee today.







 Jan 07 2004



  parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Robert wrote:


Also for the Japanese.
It's no wonder since they are loanwords from Chinese.

  


You'd probably be able to find reasons against using any number.
However, China and Japan are pretty big populations.


"Phill" <phill pacific.net.au> wrote in message
news:btgi8s$qre$1 digitaldaemon.com...
  


Thats a bad number for the Chinese, very similar to
Death.


"Brad Anderson" <brad sankaty.com> wrote in message
news:btcq7t$10fd$1 digitaldaemon.com...
    


Walter wrote:
      


Lots of new additions. Didn't get to most of the bug reports; I wanted
        




to
    


get D to be 'feature complete' first, the next version will be bug
polishing. I'm setting sights on releasing D 1.0 by March.
        


If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is the
      


fourth
    


planet...  too much coffee today.
      




  





 Jan 07 2004



  parent reply "Robert" <no spam.ne.jp>  writes:


Don't mind my words.
Four-leaf clovers are lucky also in Japan. :)

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bth3iu$1i82$2 digitaldaemon.com...

 Robert wrote:


Also for the Japanese.
It's no wonder since they are loanwords from Chinese.


 You'd probably be able to find reasons against using any number.
 However, China and Japan are pretty big populations.


"Phill" <phill pacific.net.au> wrote in message
news:btgi8s$qre$1 digitaldaemon.com...



Thats a bad number for the Chinese, very similar to
Death.


"Brad Anderson" <brad sankaty.com> wrote in message
news:btcq7t$10fd$1 digitaldaemon.com...



Walter wrote:



Lots of new additions. Didn't get to most of the bug reports; I wanted




to



get D to be 'feature complete' first, the next version will be bug
polishing. I'm setting sights on releasing D 1.0 by March.


If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is








the


fourth



planet...  too much coffee today.











 Jan 07 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


Yea they usually grow out of the graves!
hahahah

Phill


"Robert" <no spam.ne.jp> wrote in message
news:bth8a5$1r6c$1 digitaldaemon.com...

 Don't mind my words.
 Four-leaf clovers are lucky also in Japan. :)

 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:bth3iu$1i82$2 digitaldaemon.com...

 Robert wrote:


Also for the Japanese.
It's no wonder since they are loanwords from Chinese.


 You'd probably be able to find reasons against using any number.
 However, China and Japan are pretty big populations.


"Phill" <phill pacific.net.au> wrote in message
news:btgi8s$qre$1 digitaldaemon.com...



Thats a bad number for the Chinese, very similar to
Death.


"Brad Anderson" <brad sankaty.com> wrote in message
news:btcq7t$10fd$1 digitaldaemon.com...



Walter wrote:



Lots of new additions. Didn't get to most of the bug reports; I












wanted




to



get D to be 'feature complete' first, the next version will be bug
polishing. I'm setting sights on releasing D 1.0 by March.


If I were you, I'd wait until 4/4/04 - a unique date.  Also, Mars is








 the


fourth



planet...  too much coffee today.













 Jan 07 2004



  parent reply Ilya Minkov <minkov cs.tum.edu>  writes:


The munich botanical garten has a loan where you can pick some. Or was 
going to have.

By the way, what do you have against the graves? We all find peace there 
someday. I would be happy to bring luck to anybody by growing a 
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:

 Yea they usually grow out of the graves!
 hahahah
 
 Phill





 Jan 07 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...

 The munich botanical garten has a loan where you can pick some. Or was
 going to have.

 By the way, what do you have against the graves? We all find peace there
 someday. I would be happy to bring luck to anybody by growing a
 four-leaf clover, but it will probably not happen.

 -eye

 Phill wrote:

 Yea they usually grow out of the graves!
 hahahah

 Phill







 Jan 07 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.

  


Because they are rare (were rare?), your lucky if you find one.  Someone 
probably got that meaning muddled up in translation, so now they 
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...
  


The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace there
someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:
    


Yea they usually grow out of the graves!
hahahah

Phill
      





  





 Jan 07 2004



 next sibling parent reply davepermen <davepermen_member pathlink.com>  writes:


i one time found a 7-leafed one.. now that was special..

In article <btikdm$v32$1 digitaldaemon.com>, J Anderson says...

Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.

  


Because they are rare (were rare?), your lucky if you find one.  Someone 
probably got that meaning muddled up in translation, so now they 
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...
  


The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace there
someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:
    


Yea they usually grow out of the graves!
hahahah

Phill
      





  







 Jan 07 2004



  parent reply "Phill" <phill pacific.net.au>  writes:


that much luck can get you into trouble.....

τΏτ
  0

Phill



"davepermen" <davepermen_member pathlink.com> wrote in message
news:btinf5$13e2$1 digitaldaemon.com...

 i one time found a 7-leafed one.. now that was special..

 In article <btikdm$v32$1 digitaldaemon.com>, J Anderson says...

Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.


Because they are rare (were rare?), your lucky if you find one.  Someone
probably got that meaning muddled up in translation, so now they
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...



The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace








there

someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:



Yea they usually grow out of the graves!
hahahah

Phill













 Jan 07 2004



  parent  davepermen <davepermen_member pathlink.com>  writes:


i know. luck left me last summer.. i hope i'll find new one..

In article <btiskb$1bj5$1 digitaldaemon.com>, Phill says...

that much luck can get you into trouble.....

τΏτ
  0

Phill



"davepermen" <davepermen_member pathlink.com> wrote in message
news:btinf5$13e2$1 digitaldaemon.com...

 i one time found a 7-leafed one.. now that was special..

 In article <btikdm$v32$1 digitaldaemon.com>, J Anderson says...

Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.


Because they are rare (were rare?), your lucky if you find one.  Someone
probably got that meaning muddled up in translation, so now they
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...



The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace








there

someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:



Yea they usually grow out of the graves!
hahahah

Phill















 Jan 08 2004



prev sibling  parent reply Luke D <Luke_member pathlink.com>  writes:


No, it's just that the word for death is in the word for 4.  7 too I think (so 7
is an unlucky number too, but not as unlucky as 4)  The Japanese actually came
up with second names for the numbers 4 and 7 so they wouldn't have to say
"death" whenever they say the #s.  Stangely, Japanese numbers are written in
groups of 4 when groups of that amount are usually avoided.

In article <btikdm$v32$1 digitaldaemon.com>, J Anderson says...

Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.

  


Because they are rare (were rare?), your lucky if you find one.  Someone 
probably got that meaning muddled up in translation, so now they 
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...
  


The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace there
someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:
    


Yea they usually grow out of the graves!
hahahah

Phill
      





  







 Jan 08 2004



 next sibling parent  "Phill" <phill pacific.net.au>  writes:


Yes, in Chinese(Cantonese) both 4 and 7 sound
like Death/Die (Cantonese 4 = Say)
Or so my Chinese wife tells me anyway :o))

Phill


"Luke D" <Luke_member pathlink.com> wrote in message
news:btkmil$1195$1 digitaldaemon.com...

 No, it's just that the word for death is in the word for 4.  7 too I think


(so 7

 is an unlucky number too, but not as unlucky as 4)  The Japanese actually


came

 up with second names for the numbers 4 and 7 so they wouldn't have to say
 "death" whenever they say the #s.  Stangely, Japanese numbers are written


in

 groups of 4 when groups of that amount are usually avoided.

 In article <btikdm$v32$1 digitaldaemon.com>, J Anderson says...

Phill wrote:


I dont have anything against them, its just
not where I want to be for a looooooooooong
time :o))
Do you really beleive a retarded piece of vegetation
can bring you luck?

Phill.


Because they are rare (were rare?), your lucky if you find one.  Someone
probably got that meaning muddled up in translation, so now they
supposedly "bring luck" ;)


"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bti32a$45l$1 digitaldaemon.com...



The munich botanical garten has a loan where you can pick some. Or was
going to have.

By the way, what do you have against the graves? We all find peace








there

someday. I would be happy to bring luck to anybody by growing a
four-leaf clover, but it will probably not happen.

-eye

Phill wrote:



Yea they usually grow out of the graves!
hahahah

Phill













 Jan 08 2004



prev sibling  parent  Ilya Minkov <minkov cs.tum.edu>  writes:


You guys are gonna bring me into trouble! 4 and 7 are my personal lucky 
numbers!!!

Luke D wrote:

 No, it's just that the word for death is in the word for 4.  7 too I think (so
7
 is an unlucky number too, but not as unlucky as 4)  The Japanese actually came
 up with second names for the numbers 4 and 7 so they wouldn't have to say
 "death" whenever they say the #s.  Stangely, Japanese numbers are written in
 groups of 4 when groups of that amount are usually avoided.





 Jan 09 2004



prev sibling  parent  Ilya Minkov <midiclub tiscali.de>  writes:


Phill wrote:

 I dont have anything against them, its just
 not where I want to be for a looooooooooong
 time :o))


Either you are too young or too old to be pessimistic enough. :)


 Do you really beleive a retarded piece of vegetation
 can bring you luck?


No. But a graveyard can. ;)

-eye



 Jan 08 2004