• Justin Johansson (11/11) Sep 01 2010 IIRC std.contracts has been deprecated and replaced by std.exception,
• Steven Schveighoffer (18/27) Sep 01 2010 Compile time checks are only available for compile time values. If you ...
• Justin Johansson (5/21) Sep 01 2010 Thanks Steve,
• Philippe Sigaud (7/13) Sep 01 2010 Yes, Steve is right. Also, you cannot throw exceptions at CT.
• bearophile (4/5) Sep 01 2010 This is a temporary limitation :-)
• Philippe Sigaud (4/7) Sep 01 2010 Really? That means being able to create reference types at CT, that'd be
• bearophile (4/7) Sep 01 2010 I think in Bugzilla there is a patch to use exceptions at CT, but it pro...
• Jonathan M Davis (5/14) Sep 01 2010 Well, according to TDPL, the ultimate goal is to be able to use _all_ of...
• Steven Schveighoffer (6/23) Sep 02 2010 I think step 1 is to rewrite the compiler in D. Right now, CTFE is
• Don (10/37) Sep 02 2010 Writing the compiler in D would be great, but it's a long way off. This
• bearophile (4/6) Sep 02 2010 Is is possible&good to rewrite in D just the D interpreter used for CTFE...
• Denis Koroskin (7/43) Sep 02 2010 DDMD advances pretty fast, it can already compile druntime, phobos and
• dsimcha (6/12) Sep 02 2010 Awesome work! The only unfortunate thing about DDMD, as you point out o...
• dsimcha (3/4) Sep 02 2010 Clarification of an ambiguous question: I know DDMD is supposed to comp...
• Andrej Mitrovic (4/8) Sep 02 2010 According to this it's DMD2:
• Andrej Mitrovic (4/8) Sep 02 2010 According to this it's DMD2:
• Don (4/51) Sep 02 2010 Yes, although the absence of GC is not the problem with the CTFE

Justin Johansson <no spam.com> writes:

IIRC std.contracts has been deprecated and replaced by std.exception,
enforce and friends.  The latter are runtime things, correct(?).

Is there a valid use case for compile-time (i.e. subject to static
analysis) design-by-contract (DBC) enforce-like machinery?

For example, and perhaps not the best example, one might like to pass
an array of Foos to a function which by static design expects to
receive such array at runtime as containing a minimum and/or maximum of
elements.  Should (i.e. could it be desirable that) such interface
contracts be checkable at compile-time?

Cheers
Justin Johansson

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Wed, 01 Sep 2010 09:03:39 -0400, Justin Johansson <no spam.com> wrote:

 IIRC std.contracts has been deprecated and replaced by std.exception,
 enforce and friends.  The latter are runtime things, correct(?).

 Is there a valid use case for compile-time (i.e. subject to static
 analysis) design-by-contract (DBC) enforce-like machinery?

 For example, and perhaps not the best example, one might like to pass
 an array of Foos to a function which by static design expects to
 receive such array at runtime as containing a minimum and/or maximum of
 elements.  Should (i.e. could it be desirable that) such interface
 contracts be checkable at compile-time?

Compile time checks are only available for compile time values.  If you  
have a function like this:

void foo(int[] x)

There is no way at compile time to check whether x has a maximum or  
minimum number of elements. But if you have something like this:

void foo(uint N)(ref int[N] x)

Then you can check N, because it is a compile-time value.  you can make  
checks via template constraints or static assert statements:

void foo(uint N)(ref int[N] x) if(N >= minvalue)

- or -

void foo(uint N)(ref int[N] x)
{
    static assert(N >= minvalue, "Error, invalid sized array passed to  
foo");
}

Both of these will fail to compile if you pass incorrect data.

-Steve

Justin Johansson <no spam.com> writes:

On 01/09/10 22:49, Steven Schveighoffer wrote:
 Compile time checks are only available for compile time values. If you
 have a function like this:

 void foo(int[] x)

 There is no way at compile time to check whether x has a maximum or
 minimum number of elements. But if you have something like this:

 void foo(uint N)(ref int[N] x)

 Then you can check N, because it is a compile-time value. you can make
 checks via template constraints or static assert statements:

 void foo(uint N)(ref int[N] x) if(N >= minvalue)

 - or -

 void foo(uint N)(ref int[N] x)
 {
 static assert(N >= minvalue, "Error, invalid sized array passed to foo");
 }

 Both of these will fail to compile if you pass incorrect data.

 -Steve

Thanks Steve,

I'm returning to bomb bay to think about this.  (See my
'Dark Star' post for interpretation)

- Justin :-)

Philippe Sigaud <philippe.sigaud gmail.com> writes:

On Wed, Sep 1, 2010 at 16:28, Justin Johansson <no spam.com> wrote:

 On 01/09/10 22:49, Steven Schveighoffer wrote:

 Compile time checks are only available for compile time values.


Yes, Steve is right. Also, you cannot throw exceptions at CT.

But you can use 'static assert(...)' to force the evaluation of an assertion
at CT.


 Thanks Steve,

 I'm returning to bomb bay to think about this.  (See my
 'Dark Star' post for interpretation)

Why do I think that half the reason you asked this question was to be able
to post this reply? ;)


Philippe

bearophile <bearophileHUGS lycos.com> writes:

Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

This is a temporary limitation :-)

Bye,
bearophile

Philippe Sigaud <philippe.sigaud gmail.com> writes:

On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com> wrote:

 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 This is a temporary limitation :-)

Really? That means being able to create reference types at CT, that'd be
interesting, to say the least. And what code would catch them? Aren't they
caught by the runtime?

bearophile <bearophileHUGS lycos.com> writes:

Philippe Sigaud:
 Really? That means being able to create reference types at CT, that'd be
 interesting, to say the least. And what code would catch them? Aren't they
 caught by the runtime?

I think in Bugzilla there is a patch to use exceptions at CT, but it probably
doesn't work and has problems. So I don't know if this limit will be removed.

Bye,
bearophile

Jonathan M Davis <jmdavisprog gmail.com> writes:

On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote:
 On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com> wrote:
 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 
 This is a temporary limitation :-)

 
 Really? That means being able to create reference types at CT, that'd be
 interesting, to say the least. And what code would catch them? Aren't they
 caught by the runtime?

Well, according to TDPL, the ultimate goal is to be able to use _all_ of SafeD 
with CTFE. So, exceptions would be on the list. However, I wouldn't expect CTFE 
to get that powerful anytime soon.

- Jonathan M Davis

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Wed, 01 Sep 2010 17:11:50 -0400, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:

 On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote:
 On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com>  
 wrote:
 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 This is a temporary limitation :-)

 Really? That means being able to create reference types at CT, that'd be
 interesting, to say the least. And what code would catch them? Aren't  
 they
 caught by the runtime?

 Well, according to TDPL, the ultimate goal is to be able to use _all_ of  
 SafeD
 with CTFE. So, exceptions would be on the list. However, I wouldn't  
 expect CTFE
 to get that powerful anytime soon.

I think step 1 is to rewrite the compiler in D.  Right now, CTFE is  
interpreting things from a C++-based program.  I think without a garbage  
collector too.

-Steve

Don <nospam nospam.com> writes:

Steven Schveighoffer wrote:
 On Wed, 01 Sep 2010 17:11:50 -0400, Jonathan M Davis 
 <jmdavisprog gmail.com> wrote:
 
 On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote:
 On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com> 
 wrote:
 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 This is a temporary limitation :-)

 Really? That means being able to create reference types at CT, that'd be
 interesting, to say the least. And what code would catch them? Aren't 
 they
 caught by the runtime?

 Well, according to TDPL, the ultimate goal is to be able to use _all_ 
 of SafeD
 with CTFE. So, exceptions would be on the list. However, I wouldn't 
 expect CTFE
 to get that powerful anytime soon.

 
 I think step 1 is to rewrite the compiler in D.  Right now, CTFE is 
 interpreting things from a C++-based program.  I think without a garbage 
 collector too.
 
 -Steve

Writing the compiler in D would be great, but it's a long way off. This 
will happen a lot sooner than that.
Exceptions, like almost all other CTFE features, are blocked by bug 
1330. Fixing this will require a new CTFE memory allocation system. It's 
  not terribly complicated, but won't happen until the high priority 
bugs are taken care of.
Other than memory management, most of the CTFE machinery for classes and 
exceptions is already in place. Note, for example, that reference 
parameters and struct member functions work correctly.

bearophile <bearophileHUGS lycos.com> writes:

Don:
 Writing the compiler in D would be great, but it's a long way off. This 
 will happen a lot sooner than that.

Is is possible&good to rewrite in D just the D interpreter used for CTFE?

Bye,
bearophile

"Denis Koroskin" <2korden gmail.com> writes:

On Thu, 02 Sep 2010 18:55:14 +0400, Don <nospam nospam.com> wrote:

 Steven Schveighoffer wrote:
 On Wed, 01 Sep 2010 17:11:50 -0400, Jonathan M Davis  
 <jmdavisprog gmail.com> wrote:

 On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote:
 On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com>  
 wrote:
 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 This is a temporary limitation :-)

 Really? That means being able to create reference types at CT, that'd  
 be
 interesting, to say the least. And what code would catch them? Aren't  
 they
 caught by the runtime?

 Well, according to TDPL, the ultimate goal is to be able to use _all_  
 of SafeD
 with CTFE. So, exceptions would be on the list. However, I wouldn't  
 expect CTFE
 to get that powerful anytime soon.

  I think step 1 is to rewrite the compiler in D.  Right now, CTFE is  
 interpreting things from a C++-based program.  I think without a  
 garbage collector too.
  -Steve

 Writing the compiler in D would be great, but it's a long way off. This  
 will happen a lot sooner than that.
 Exceptions, like almost all other CTFE features, are blocked by bug  
 1330. Fixing this will require a new CTFE memory allocation system. It's  
   not terribly complicated, but won't happen until the high priority  
 bugs are taken care of.
 Other than memory management, most of the CTFE machinery for classes and  
 exceptions is already in place. Note, for example, that reference  
 parameters and struct member functions work correctly.

DDMD advances pretty fast, it can already compile druntime, phobos and  
some of the applications. We also started updating it to newer versions,  
so it's catching up (ddmd is at 2.036 atm). GC is disabled atm due to  
memory corruptions inherited from DMD, though. I believe once we resolve  
those and enable GC we could backport the changes to DMD so that it could  
use Boehm's GC. Win-win?

dsimcha <dsimcha yahoo.com> writes:

== Quote from Denis Koroskin (2korden gmail.com)'s article
 DDMD advances pretty fast, it can already compile druntime, phobos and
 some of the applications. We also started updating it to newer versions,
 so it's catching up (ddmd is at 2.036 atm). GC is disabled atm due to
 memory corruptions inherited from DMD, though. I believe once we resolve
 those and enable GC we could backport the changes to DMD so that it could
 use Boehm's GC. Win-win?

Awesome work!  The only unfortunate thing about DDMD, as you point out on the
wiki, is that it's far from idiomatic D.  For example, I doubt you'd find
anything
like:

import std.algorithm

in there.  BTW, is DDMD targeting D1 or D2?

dsimcha <dsimcha yahoo.com> writes:

== Quote from dsimcha (dsimcha yahoo.com)'s article
 BTW, is DDMD targeting D1 or D2?

Clarification of an ambiguous question:  I know DDMD is supposed to compile D2.
Is the code to DDMD itself written in D1 or D2?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

According to this it's DMD2:
http://www.dsource.org/projects/ddmd/wiki/BuildInstructions/Windows

2010/9/2 dsimcha <dsimcha yahoo.com>:
 =3D=3D Quote from dsimcha (dsimcha yahoo.com)'s article
 BTW, is DDMD targeting D1 or D2?

 Clarification of an ambiguous question: =A0I know DDMD is supposed to com=

pile D2.
 Is the code to DDMD itself written in D1 or D2?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

According to this it's DMD2:
http://www.dsource.org/projects/ddmd/wiki/BuildInstructions/Windows

2010/9/2 dsimcha <dsimcha yahoo.com>:
 =3D=3D Quote from dsimcha (dsimcha yahoo.com)'s article
 BTW, is DDMD targeting D1 or D2?

 Clarification of an ambiguous question: =A0I know DDMD is supposed to com=

pile D2.
 Is the code to DDMD itself written in D1 or D2?

Don <nospam nospam.com> writes:

Denis Koroskin wrote:
 On Thu, 02 Sep 2010 18:55:14 +0400, Don <nospam nospam.com> wrote:
 
 Steven Schveighoffer wrote:
 On Wed, 01 Sep 2010 17:11:50 -0400, Jonathan M Davis 
 <jmdavisprog gmail.com> wrote:

 On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote:
 On Wed, Sep 1, 2010 at 22:37, bearophile <bearophileHUGS lycos.com> 
 wrote:
 Philippe Sigaud:
 Yes, Steve is right. Also, you cannot throw exceptions at CT.

 This is a temporary limitation :-)

 Really? That means being able to create reference types at CT, 
 that'd be
 interesting, to say the least. And what code would catch them? 
 Aren't they
 caught by the runtime?

 Well, according to TDPL, the ultimate goal is to be able to use 
 _all_ of SafeD
 with CTFE. So, exceptions would be on the list. However, I wouldn't 
 expect CTFE
 to get that powerful anytime soon.

  I think step 1 is to rewrite the compiler in D.  Right now, CTFE is 
 interpreting things from a C++-based program.  I think without a 
 garbage collector too.
  -Steve

 Writing the compiler in D would be great, but it's a long way off. 
 This will happen a lot sooner than that.
 Exceptions, like almost all other CTFE features, are blocked by bug 
 1330. Fixing this will require a new CTFE memory allocation system. 
 It's   not terribly complicated, but won't happen until the high 
 priority bugs are taken care of.
 Other than memory management, most of the CTFE machinery for classes 
 and exceptions is already in place. Note, for example, that reference 
 parameters and struct member functions work correctly.

 
 DDMD advances pretty fast, it can already compile druntime, phobos and 
 some of the applications. 

Cool! Have you tried the DMD test suite?

 We also started updating it to newer versions, 
 so it's catching up (ddmd is at 2.036 atm). GC is disabled atm due to 
 memory corruptions inherited from DMD, though. I believe once we resolve 
 those and enable GC we could backport the changes to DMD so that it 
 could use Boehm's GC. Win-win?

Yes, although the absence of GC is not the problem with the CTFE 
implementation.