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