www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Against enforce()

reply bearophile <bearophileHUGS lycos.com> writes:
enforce() seems the part of Phobos that I hate more. Among its faults:
- It can't be used in weakly pure functions (because you can't use lazy
arguments in pure functions), and not-purity is viral. Lot of Phobos can't be
pure because of this, so even more user code can't be pure because of this;
- It kills inlining (with the current DMD, and I don't think this problem will
be fixed soon);
- I have seen it slow down code (probably mostly because of its not-inlining
nature);
- Where it is used it usually doesn't give a more meaningful exception like
WrongArgumentException, etc. I don't want a deep hierarchy of one hundred
standard exceptions, but I think some standard exceptions for the most common
mistakes, like wrong arguments, etc, are better than a generic enforce(),
especially for a standard library code that is meant to be written with care
and to give better error messages/exceptions.
- It doesn't allow functions to be nothrow. This is a fault, because D has
Contract Programming, that is meant to be usable for nothrow functions too. D
Contracts with asserts are the right tool.

I see enforce() just as a temporary workaround for a problem of Phobos (that
it's compiled in release mode, so its asserts are vanished) that risks to
become a permanent part of Phobos.

So a better solution is for the standard Phobos library to ship in two
versions, one compiled in release and not release mode, and DMD may choose the
right one according to the compilation switches. This removes most of the need
of enforce(). I suggest to deprecate enforce(). Until the problem with Phobos
compilation is solved and enforces are removed from Phobos, enforce() may
become a private Phobos function that user code can't import.

Bye,
bearophile
Mar 16 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 - It doesn't allow functions to be nothrow. This is a fault,
 because D has Contract Programming, that is meant to be usable for
 nothrow functions too. D Contracts with asserts are the right tool.

assert and enforce cover a completely different problem, and aren't interchangeable. assert catches programming errors. If an assert fails, it's a bug that the programmer should fix. enforce, on the other hand, catches runtime errors that aren't the programmer's fault. Then *have* to be handled to be correct, so being nothrow is out of the question. The function is *not* guaranteed to succeed at runtime. Look at the way enforce is generally used inside Phobos. enforce(fp = fopen("file", "r")); That is something that could fail at no fault of the programmer. It's an exception, not an assert. By far, the majority of enforces in Phobos are of this variety. They cannot possibly be made into contracts, and even if they could, that would be wrong. That said, I tentatively agree that enforce may be bad right now because of the other things you said (except the meaningful exception. enforce does that with an optional argument.) enforce is just a lazy way to write if(xxxxx) throw T(msg); It is elegant, it is beautiful, but if the practical problems aren't fixed, it might be right to avoid it anyway. But it'd have to be replaced with if/throw, not assert.
Mar 16 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, March 16, 2011 16:45:56 bearophile wrote:
 enforce() seems the part of Phobos that I hate more. Among its faults:
 - It can't be used in weakly pure functions (because you can't use lazy
 arguments in pure functions), and not-purity is viral. Lot of Phobos can't
 be pure because of this, so even more user code can't be pure because of
 this; - It kills inlining (with the current DMD, and I don't think this
 problem will be fixed soon); - I have seen it slow down code (probably
 mostly because of its not-inlining nature);

 - Where it is used it usually
 doesn't give a more meaningful exception like WrongArgumentException, etc.
 I don't want a deep hierarchy of one hundred standard exceptions, but I
 think some standard exceptions for the most common mistakes, like wrong
 arguments, etc, are better than a generic enforce(), especially for a
 standard library code that is meant to be written with care and to give
 better error messages/exceptions.

A number of modules in Phobos have exceptions specific to that module - such as DateTimeException or FileException. enforce doesn't stop anyone from using specific exceptions. And it's just as easy to use Exception instead of a specific exception type when throwing directly, so I don't think that this complaint holds much water. It's a valid complaint if Phobos developers are choosing to throw Exception instead of more specific exceptions, but that's not enforce's fault.
 - It doesn't allow functions to be
 nothrow. This is a fault, because D has Contract Programming, that is
 meant to be usable for nothrow functions too. D Contracts with asserts are
 the right tool.

Overall, I favor exceptions when it comes to testing input rather than assertions, but regardless of that. enforce does _not_ stop functions from being nothrow. It just makes it more annoying to make them nothrow. If you want the caller to be nothrow, you have to have a try-catch block in the caller which catches Exception. If the function really isn't ever going to throw, then you can use such a try-catch block with an assert(0) in the catch body, and it's quite safe. std.datetime does that in several places. Regardless, your problem here really isn't enforce anyway. Your problem is that you think that a number of functions should be using assertions instead of exceptions. enforce happens to be a way to throw exceptions, but it's quite easy to use exceptions without it. So, enforce doesn't really have anything to do with it other than the fact that that was the means used to throw the exception.
 I see enforce() just as a temporary workaround for a problem of Phobos
 (that it's compiled in release mode, so its asserts are vanished) that
 risks to become a permanent part of Phobos.

 So a better solution is for the standard Phobos library to ship in two
 versions, one compiled in release and not release mode, and DMD may choose
 the right one according to the compilation switches. This removes most of
 the need of enforce(). I suggest to deprecate enforce(). Until the problem
 with Phobos compilation is solved and enforces are removed from Phobos,
 enforce() may become a private Phobos function that user code can't
 import.

There a number of places in Phobos which throw exceptions and _should_ throw exceptions. ConvExceptions and FileExceptions are great examples. DateTimeException is used liberally in std.datetime, and it really wouldn't make sense to make them use assertions. And even in cases where exceptions were chosen of assertions because of the release vs non-release mode issue, there's still the question of whether we really want Phobos to be throwing AssertErrors, since when a programmer sees an assertion which isn't theirs, they're likely to think that it's someone else's code which is broken, not theirs. So, having AssertErrors thrown from Phobos look just plain bad. Now, in same cases performance still makes assertions more desirable - and there _are_ places in Phobos which use exceptions - but there are still a lot of situations where Phobos _should_ be throwing exceptions. Regardless, enforce is supposed to make throwing exceptions similar to asserting something. It is - in theory at least - a great idea. The problem with it is its laziness and all of the implications that that has (like the inability to inline because of it). If we had a non-lazy version of enforce or if the compiler were made smart enough to realize that it didn't need a lazy version in some cases (such as when it's passed a string literal) and to use a non-lazy version in such cases, then the problem would be reduced. Personally, I rarely use enforce precisely because of the inlining issue. I don't that that if(!condition) throw new ExceptionType(msg); is really much worse than enforce(condition, new ExceptionType(msg)); but I see no reason to get rid enforce. I also disagree with you about how much Phobos should be using exceptions. There _are_ places - such as in a lot of range-based functions - which likely need to use assertions rather than exceptions for performance reasons, but I do _not_ like the idea of using assertions to validate input from code outside of Phobos. I think that that is _exactly_ the sort of place that should be using exceptions rather than assertions. - Jonathan M Davis
Mar 16 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/16/2011 06:45 PM, bearophile wrote:
 enforce() seems the part of Phobos that I hate more.

Yum, love the enforce.
 Among its faults:
 - It can't be used in weakly pure functions (because you can't use lazy
arguments in pure functions), and not-purity is viral. Lot of Phobos can't be
pure because of this, so even more user code can't be pure because of this;

So perhaps the language could be improved as enforce does not break purity.
 - It kills inlining (with the current DMD, and I don't think this problem will
be fixed soon);

Not a problem of enforce.
 - I have seen it slow down code (probably mostly because of its not-inlining
nature);

Not a problem of enforce.
 - Where it is used it usually doesn't give a more meaningful exception like
WrongArgumentException, etc. I don't want a deep hierarchy of one hundred
standard exceptions, but I think some standard exceptions for the most common
mistakes, like wrong arguments, etc, are better than a generic enforce(),
especially for a standard library code that is meant to be written with care
and to give better error messages/exceptions.

enforce helps such idioms, does not prevent them. From the docs: =============== T enforce(T)(T value, lazy Throwable ex); If value is nonzero, returns it. Otherwise, throws ex. ===============
 - It doesn't allow functions to be nothrow. This is a fault, because D has
Contract Programming, that is meant to be usable for nothrow functions too. D
Contracts with asserts are the right tool.

enforce's specification specifies it throws. It would therefore be difficult for it to not throw. This complaint is non sequitur.
 I see enforce() just as a temporary workaround for a problem of Phobos (that
it's compiled in release mode, so its asserts are vanished) that risks to
become a permanent part of Phobos.

enforce is a simple abstraction of the idiom "if (!condition) throw new Exception(args)". If that idiom were rare, then occurrences of enforce would be rare and therefore there would be little need to have enforce at all.
 So a better solution is for the standard Phobos library to ship in two
versions, one compiled in release and not release mode, and DMD may choose the
right one according to the compilation switches. This removes most of the need
of enforce(). I suggest to deprecate enforce(). Until the problem with Phobos
compilation is solved and enforces are removed from Phobos, enforce() may
become a private Phobos function that user code can't import.

There may be some confusion somewhere. enforce is not supposed to be a sort of assert. It is a different tool with a different charter. Use assert for assertions. Andrei
Mar 16 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Yum, love the enforce.

You are silly :-)
 So perhaps the language could be improved as enforce does not break purity.

Currently enforce() uses a lazy argument. A lazy argument is a delegate, and generally such delegate can't be pure, because the expressions you give to enforce() usually refer to variables in the scope where you call enforce(). So what kind of language improvements are you thinking about? This is an example: http://d.puremagic.com/issues/show_bug.cgi?id=5746
 - It kills inlining (with the current DMD, and I don't think this problem will
be fixed soon);


In my opinion it's not wise use widely in the standard library something that requires an optimization that the DMD compiler is not going to have soon, and that makes the code significantly slower. In some cases this almost forces me to keep a patched version of Phobos, or to add more nearly duplicated functions to my dlibs2.
 enforce helps such idioms, does not prevent them. From the docs:
 
 ===============
 T enforce(T)(T value, lazy Throwable ex);
 
 If value is nonzero, returns it. Otherwise, throws ex.
 ===============

Then why is iota() using a nude enforce() instead of the enforce() with a more meaningful exception like WrongArgumentException? I have seen the nude enforce used in other parts of Phobos. So maybe enforce() makes even the standard library writers lazy.
 enforce's specification specifies it throws. It would therefore be difficult
for it to not throw. This complaint is non sequitur.<

I know, and I agree in some situations you want an assert (to test arguments coming from "outside"), so in some situations an enforce is acceptable. The problem is that currently enforce is used as a patch for a DMD/Phobos problem that I hope will be fixed in a short time, see below.
 I see enforce() just as a temporary workaround for a problem of Phobos (that
it's compiled in release mode, so its asserts are vanished) that risks to
become a permanent part of Phobos.<<


 enforce is a simple abstraction of the idiom "if (!condition) throw new
Exception(args)". If that idiom were rare, then occurrences of enforce would be
rare and therefore there would be little need to have enforce at all.<
There may be some confusion somewhere. enforce is not supposed to be a sort of
assert. It is a different tool with a different charter. Use assert for
assertions.<

Right. But saying just that is not enough. You have to add that such "if (!condition) throw new Exception(args)" idiom is common in Phobos because Phobos is present only in release mode. If the zip distribution of DMD contains two Phobos and dmd becomes able to use the right one according to the compilation switches, then I think that "if (!condition) throw new Exception(args)" will become more rare, and the enforce() too will be less commonly needed. Bye, bearophile
Mar 16 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 I know, and I agree in some situations you want an assert (

I meant:
 I know, and I agree in some situations you want an exception (

Sorry, bearophile
Mar 16 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/16/2011 08:53 PM, bearophile wrote:
 Andrei:

 Yum, love the enforce.

You are silly :-)
 So perhaps the language could be improved as enforce does not break purity.

Currently enforce() uses a lazy argument. A lazy argument is a delegate, and generally such delegate can't be pure, because the expressions you give to enforce() usually refer to variables in the scope where you call enforce(). So what kind of language improvements are you thinking about?

I haven't thought through it. Clearly this is a false positive, a restriction that should be at best removed.
 This is an example:
 http://d.puremagic.com/issues/show_bug.cgi?id=5746


 - It kills inlining (with the current DMD, and I don't think this problem will
be fixed soon);


In my opinion it's not wise use widely in the standard library something that requires an optimization that the DMD compiler is not going to have soon, and that makes the code significantly slower. In some cases this almost forces me to keep a patched version of Phobos, or to add more nearly duplicated functions to my dlibs2.

No need to blow out of proportion everything that serves a point. There are only few places in which use of enforce (or checking in general) slows things down. We have decided to assuage that by avoiding duplicate checks and by sometimes leaving it to the user to check (e.g. by using assert). This is a good approach because it starts from conservative and thoroughly checked.
 enforce helps such idioms, does not prevent them. From the docs:

 ===============
 T enforce(T)(T value, lazy Throwable ex);

 If value is nonzero, returns it. Otherwise, throws ex.
 ===============

Then why is iota() using a nude enforce() instead of the enforce() with a more meaningful exception like WrongArgumentException?

Because I don't condone defining large exception hierarchies. It's most important to throw an exception. Then it's okay to refine exception types, but that's not an issue that is the charter of enforce or that enforce prevents.
 I have
 seen the nude enforce used in other parts of Phobos. So maybe
 enforce() makes even the standard library writers lazy.

It makes the standard library writers productive.
 enforce's specification specifies it throws. It would therefore be
 difficult for it to not throw. This complaint is non sequitur.<

I know, and I agree in some situations you want an assert (to test arguments coming from "outside"), so in some situations an enforce is acceptable. The problem is that currently enforce is used as a patch for a DMD/Phobos problem that I hope will be fixed in a short time, see below.

Hoping less and doing more would be great.
 I see enforce() just as a temporary workaround for a problem of
 Phobos (that it's compiled in release mode, so its asserts are
 vanished) that risks to become a permanent part of Phobos.<<


 enforce is a simple abstraction of the idiom "if (!condition) throw
 new Exception(args)". If that idiom were rare, then occurrences of
 enforce would be rare and therefore there would be little need to
 have enforce at all.< There may be some confusion somewhere.
 enforce is not supposed to be a sort of assert. It is a different
 tool with a different charter. Use assert for assertions.<

Right. But saying just that is not enough. You have to add that such "if (!condition) throw new Exception(args)" idiom is common in Phobos because Phobos is present only in release mode. If the zip distribution of DMD contains two Phobos and dmd becomes able to use the right one according to the compilation switches, then I think that "if (!condition) throw new Exception(args)" will become more rare, and the enforce() too will be less commonly needed.

I think you are terribly confused about the relative roles of assert and enforce. Andrei
Mar 16 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Every case that I can think of at the moment where enforce is used,
 an exception _should_ be used.

Right, for once that of mine is a falsifiable assertion (http://en.wikipedia.org/wiki/Falsifiability ) :-) Bye, bearophile
Mar 16 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2011 6:53 PM, bearophile wrote:
 Right. But saying just that is not enough. You have to add that such "if
 (!condition) throw new Exception(args)" idiom is common in Phobos because
 Phobos is present only in release mode. If the zip distribution of DMD
 contains two Phobos and dmd becomes able to use the right one according to
 the compilation switches, then I think that "if (!condition) throw new
 Exception(args)" will become more rare, and the enforce() too will be less
 commonly needed.

I must reiterate that enforce() is NOT FOR DETECTING PROGRAM BUGS. Therefore, enforce() must not change its behavior based on "release mode" or other compiler switches. Contracts and asserts are for program bug detection. NOT enforce. This distinction is critical.
Mar 17 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 17, 2011 12:22:00 Walter Bright wrote:
 On 3/16/2011 6:53 PM, bearophile wrote:
 Right. But saying just that is not enough. You have to add that such "if
 (!condition) throw new Exception(args)" idiom is common in Phobos because
 Phobos is present only in release mode. If the zip distribution of DMD
 contains two Phobos and dmd becomes able to use the right one according
 to the compilation switches, then I think that "if (!condition) throw
 new Exception(args)" will become more rare, and the enforce() too will
 be less commonly needed.

I must reiterate that enforce() is NOT FOR DETECTING PROGRAM BUGS. Therefore, enforce() must not change its behavior based on "release mode" or other compiler switches. Contracts and asserts are for program bug detection. NOT enforce. This distinction is critical.

I completely agree with you. However, I think that part of the confusion is that there was discussion of using enforce in Phobos in some cases where we might otherwise have used an assertion, because the assertions would general be compiled out when anyone went to use Phobos other than Phobos itself, so they would be useless. I'm not aware that ever actually having been done, however. And in general, I don't like the idea of using assertions to validate that someone is using a library function correctly rather than validating the library function itself. I really think that that should be treated like user input and throw an exception if it really is supposed to be being validated. Some additional assertions which could be of benefit both in unit testing and if some actually uses a non-release version of Phobos might be useful, but counting on that sort of check being there makes no sense to me. Assertions are for validating the code that they're in, not someone else's code which is using that code. In any case, I think that part of the confusion here is due to previous discussions on the lack of assertions in -release (and the fact that libphobos.a is normally compiled with -release) and the possible use of enforce to get around that in some cases. I'm not aware that actually ever having been done, however. Still, I do get the impression the people often confuse the purposes of assertions and exceptions. - Jonathan M Davis
Mar 17 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 17.03.2011 02:07, schrieb Andrei Alexandrescu:
 On 03/16/2011 06:45 PM, bearophile wrote:
 - Where it is used it usually doesn't give a more meaningful exception
 like WrongArgumentException, etc. I don't want a deep hierarchy of one
 hundred standard exceptions, but I think some standard exceptions for
 the most common mistakes, like wrong arguments, etc, are better than a
 generic enforce(), especially for a standard library code that is
 meant to be written with care and to give better error
 messages/exceptions.

enforce helps such idioms, does not prevent them. From the docs: =============== T enforce(T)(T value, lazy Throwable ex); If value is nonzero, returns it. Otherwise, throws ex. ===============

Really? using enforce with a custom throwable saves *one* char: enforce(foo, new BlaException("bad!")); if(!foo) throw new BlaException("bad!"); or are there other merits? But using enforce with a custom message (thus it'll just throw a standard Exception with that message), like assert, really shortens things: enforce(..., "bad!"); if(!...) throw new Exception("bad!"); So of course enforce allows to throw meaningful exceptions, but it doesn't make it considerably easier/shorter. Cheers, - Daniel
Mar 16 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/16/2011 08:50 PM, Daniel Gibson wrote:
 Am 17.03.2011 02:07, schrieb Andrei Alexandrescu:
 On 03/16/2011 06:45 PM, bearophile wrote:
 - Where it is used it usually doesn't give a more meaningful exception
 like WrongArgumentException, etc. I don't want a deep hierarchy of one
 hundred standard exceptions, but I think some standard exceptions for
 the most common mistakes, like wrong arguments, etc, are better than a
 generic enforce(), especially for a standard library code that is
 meant to be written with care and to give better error
 messages/exceptions.

enforce helps such idioms, does not prevent them. From the docs: =============== T enforce(T)(T value, lazy Throwable ex); If value is nonzero, returns it. Otherwise, throws ex. ===============

Really? using enforce with a custom throwable saves *one* char: enforce(foo, new BlaException("bad!")); if(!foo) throw new BlaException("bad!"); or are there other merits?

enforce is an expression that returns its argument so it's composable. Andrei
Mar 16 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 17.03.2011 02:55, schrieb Andrei Alexandrescu:
 On 03/16/2011 08:50 PM, Daniel Gibson wrote:
 Am 17.03.2011 02:07, schrieb Andrei Alexandrescu:
 On 03/16/2011 06:45 PM, bearophile wrote:
 - Where it is used it usually doesn't give a more meaningful exception
 like WrongArgumentException, etc. I don't want a deep hierarchy of one
 hundred standard exceptions, but I think some standard exceptions for
 the most common mistakes, like wrong arguments, etc, are better than a
 generic enforce(), especially for a standard library code that is
 meant to be written with care and to give better error
 messages/exceptions.

enforce helps such idioms, does not prevent them. From the docs: =============== T enforce(T)(T value, lazy Throwable ex); If value is nonzero, returns it. Otherwise, throws ex. ===============

Really? using enforce with a custom throwable saves *one* char: enforce(foo, new BlaException("bad!")); if(!foo) throw new BlaException("bad!"); or are there other merits?

enforce is an expression that returns its argument so it's composable. Andrei

You're right. I just realized it and wanted to reply that correction to myself but you were faster :) I agree, that *is* helpful. A side note: The documentation says the value is returned if it's "non-zero". enforce() also throws on null (for classes, probably also for pointers) and false (for bool..) - this should probably be mentioned in the docs ;-) Cheers, - Daniel
Mar 16 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 17.03.2011 06:59, schrieb Simen kjaeraas:
 On Thu, 17 Mar 2011 03:03:23 +0100, Daniel Gibson
 <metalcaedes gmail.com> wrote:

 You're right. I just realized it and wanted to reply that correction
 to myself but you were faster :)
 I agree, that *is* helpful.
 A side note: The documentation says the value is returned if it's
 "non-zero".
 enforce() also throws on null (for classes, probably also for
 pointers) and false (for bool..) - this should probably be mentioned
 in the docs ;-)

null and false are also zero. :p

Technically yes, but it'd be more clear to specifically mention them. Also "the value is returned" could imply that enforce doesn't work with references (=> objects).. I think enforce's behaviour on bools, objects and pointers would be easier to understand if null and false were mentioned :)
Mar 17 2011
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Daniel Gibson
    enforce(foo, new BlaException("bad!"));

One use of enforce is something more like this: auto fp = enforce(fopen("my file", "r"), "cant open file"); Which replaces: auto fp = fopen("my file", "r"); if(fp is null) throw new Exception("cant open file");
Mar 16 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, March 16, 2011 18:53:06 bearophile wrote:
 Andrei:
 Yum, love the enforce.

You are silly :-)
 So perhaps the language could be improved as enforce does not break
 purity.

Currently enforce() uses a lazy argument. A lazy argument is a delegate, and generally such delegate can't be pure, because the expressions you give to enforce() usually refer to variables in the scope where you call enforce(). So what kind of language improvements are you thinking about? This is an example: http://d.puremagic.com/issues/show_bug.cgi?id=5746
 - It kills inlining (with the current DMD, and I don't think this
 problem will be fixed soon);

Not a problem of enforce.

In my opinion it's not wise use widely in the standard library something that requires an optimization that the DMD compiler is not going to have soon, and that makes the code significantly slower. In some cases this almost forces me to keep a patched version of Phobos, or to add more nearly duplicated functions to my dlibs2.
 enforce helps such idioms, does not prevent them. From the docs:
 
 ===============
 T enforce(T)(T value, lazy Throwable ex);
 
 If value is nonzero, returns it. Otherwise, throws ex.
 ===============

Then why is iota() using a nude enforce() instead of the enforce() with a more meaningful exception like WrongArgumentException? I have seen the nude enforce used in other parts of Phobos. So maybe enforce() makes even the standard library writers lazy.
 enforce's specification specifies it throws. It would therefore be
 difficult for it to not throw. This complaint is non sequitur.<

I know, and I agree in some situations you want an assert (to test arguments coming from "outside"), so in some situations an enforce is acceptable. The problem is that currently enforce is used as a patch for a DMD/Phobos problem that I hope will be fixed in a short time, see below.
 I see enforce() just as a temporary workaround for a problem of Phobos
 (that it's compiled in release mode, so its asserts are vanished) that
 risks to become a permanent part of Phobos.<<

enforce is a simple abstraction of the idiom "if (!condition) throw new Exception(args)". If that idiom were rare, then occurrences of enforce would be rare and therefore there would be little need to have enforce at all.< There may be some confusion somewhere. enforce is not supposed to be a sort of assert. It is a different tool with a different charter. Use assert for assertions.<

Right. But saying just that is not enough. You have to add that such "if (!condition) throw new Exception(args)" idiom is common in Phobos because Phobos is present only in release mode. If the zip distribution of DMD contains two Phobos and dmd becomes able to use the right one according to the compilation switches, then I think that "if (!condition) throw new Exception(args)" will become more rare, and the enforce() too will be less commonly needed.

For the most part, I don't think that this is true. There was discussion of using enforce instead of assertions because of assertions being compiled out with -release, but I'm not sure that that ever actually happened. Every case that I can think of at the moment where enforce is used, an exception _should_ be used. The only question is whether enforce should be used due to the current problems with inlining it and whatnot. - Jonathan M Davis
Mar 16 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/17/11, Adam D. Ruppe <destructionator gmail.com> wrote:
 Daniel Gibson
    enforce(foo, new BlaException("bad!"));

One use of enforce is something more like this: auto fp = enforce(fopen("my file", "r"), "cant open file"); Which replaces: auto fp = fopen("my file", "r"); if(fp is null) throw new Exception("cant open file");

Well that is pretty sweet. I didn't know enforce returned the type back. Time to cut some lines in my code, yay.
Mar 16 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 17 Mar 2011 03:03:23 +0100, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 You're right. I just realized it and wanted to reply that correction to  
 myself but you were faster :)
 I agree, that *is* helpful.
 A side note: The documentation says the value is returned if it's  
 "non-zero".
 enforce() also throws on null (for classes, probably also for pointers)  
 and false (for bool..) - this should probably be mentioned in the docs  
 ;-)

null and false are also zero. :p -- Simen
Mar 16 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 16 Mar 2011 22:10:01 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 03/16/2011 08:53 PM, bearophile wrote:
 Andrei:

 Yum, love the enforce.

You are silly :-)
 So perhaps the language could be improved as enforce does not break  
 purity.

Currently enforce() uses a lazy argument. A lazy argument is a delegate, and generally such delegate can't be pure, because the expressions you give to enforce() usually refer to variables in the scope where you call enforce(). So what kind of language improvements are you thinking about?

I haven't thought through it. Clearly this is a false positive, a restriction that should be at best removed.

int x; void foo(int i) { enforce(i == 5, to!string(x = 5)); // if enforce is pure, this will mean the global x could be affected inside the function } I don't think enforce can be straight pure. It can only be pure when called from pure functions. A so-called conditional purity. If we have auto purity, then I think the compiler could sort this out. -Steve
Mar 17 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 16 Mar 2011 21:07:54 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 On 03/16/2011 06:45 PM, bearophile wrote:
 - It kills inlining (with the current DMD, and I don't think this  
 problem will be fixed soon);

Not a problem of enforce.

Why can't enforce be this: T enforce(T, string file = __FILE__, int line = __LINE__)(T value, /* lazy -- BUG: disables inlining */ const(char)[] msg = null); Until the compiler is fixed? I bet it would perform better even though the message may be eagerly constructed. Simply because in 99% of cases (I've checked) the message is a string literal. Essentially we keep saying D is on par with C for performance, and then the standard library is riddled with un-optimizable code making that claim patently false. It doesn't help to say, "well yeah, I know it's not *now* but trust me, we know what the problem is and we'll fix it in the next 1-60 months." Given that this problem has been noted and existed for over a year, and doesn't show any sign of being fixed, we should work around it until it is fixed. enforce should be pure, since it should be equivalent to if(!x) throw new Exception(msg). However, we cannot have a "function" that is the equivalent. This would all be possible with macros. The workaround is simple, replace instances of enforce in functions you want to be pure with the equivalent if (!x) throw ... All the other points, I disagree with bearophile, enforce is not assert and should not be nothrow. -Steve
Mar 17 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 All the other points, I disagree with bearophile, enforce is not assert
 and should not be nothrow.

I have never said this. I am aware that enforce can't be nothrow, and I agree that in some situations you want to raise an exception instead of using asserts. One of the things I have said (maybe wrongly) are:
You have to add that such "if (!condition) throw new Exception(args)" idiom is
common in Phobos because Phobos is present only in release mode. If the zip
distribution of DMD contains two Phobos and dmd becomes able to use the right
one according to the compilation switches, then I think that "if (!condition)
throw new Exception(args)" will become more rare, and the enforce() too will be
less commonly needed.<

Bye, bearophile
Mar 17 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-) Bye, bearophile
Mar 17 2011
next sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:

 Steven Schveighoffer:
 
 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-)

void checkArgument(bool condition, const char[] msg = null, string file = __FILE__, int line = __LINE__) pure { if(!condition)throw new ArgumentException(msg,file,line); } will this work?
Mar 17 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Kagamin:

 will this work?

Maybe msg has to be of string type. Bye, bearophile
Mar 17 2011
prev sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Thu, 17 Mar 2011 13:30:21 -0400, Simen kjaeraas 
 <simen.kjaras gmail.com> wrote:
 
 On Thu, 17 Mar 2011 18:17:08 +0100, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 On Thu, 17 Mar 2011 12:09:50 -0400, bearophile 
 <bearophileHUGS lycos.com> wrote:

 Steven Schveighoffer:

 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-)

I think this is not as much an easy fix. By changing one line in enforce, every instance becomes inlinable. By making enforce also pure, it doesn't automatically make all users of enforce pure. I thought that lazy enforce cannot be pure, but I realize now that it can, as long as the delegate is pure. However, I think the compiler won't cooperate with that.

Not currently, at least. This made me wonder. A delegate created inside a pure function would have to be pure while in the scope of that function, right? Seems to me that should be possible to implement.

As long as the delegate does not access shared/global data, it should be able to be pure. Even delegates which modify TLS data should be able to be pure (weak-pure, but still pure). This should be easy to enforce when the delegate is created automatically from an expression using a lazy call. However, we need some implicit casting rules for pure delegates into non-pure ones. -Steve

Fortunately, we don't. Delegates created via lazy are not the same as external delegates; they're an even simpler case of delegate literals. This means that at the moment that a lazy function is called, all of the code of the delegate is available. Furthermore, the caller function must access every expression inside the lazy delegate; if the caller is marked as pure, every expression inside the lazy delegate must also be pure. So the existing checks work just fine. Patch in bug 5750.
Mar 18 2011
prev sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Wed, 16 Mar 2011 21:07:54 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 On 03/16/2011 06:45 PM, bearophile wrote:
 - It kills inlining (with the current DMD, and I don't think this 
 problem will be fixed soon);

Not a problem of enforce.

Why can't enforce be this: T enforce(T, string file = __FILE__, int line = __LINE__)(T value, /* lazy -- BUG: disables inlining */ const(char)[] msg = null); Until the compiler is fixed? I bet it would perform better even though the message may be eagerly constructed. Simply because in 99% of cases (I've checked) the message is a string literal. Essentially we keep saying D is on par with C for performance, and then the standard library is riddled with un-optimizable code making that claim patently false. It doesn't help to say, "well yeah, I know it's not *now* but trust me, we know what the problem is and we'll fix it in the next 1-60 months."

I completely agree. If we make statements like "it's OK because it will be fixed soon" it has to be added to a list and prioritized. With the understanding that *it knocks something else from that list*. As I've ended up being the one who implements a large fraction of such things, I get unhappy when people casually make statements about them being implemented "soon".
Mar 17 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 17 Mar 2011 11:49:25 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:

 All the other points, I disagree with bearophile, enforce is not assert
 and should not be nothrow.

I have never said this. I am aware that enforce can't be nothrow, and I agree that in some situations you want to raise an exception instead of using asserts. One of the things I have said (maybe wrongly) are:
 You have to add that such "if (!condition) throw new Exception(args)"  
 idiom is common in Phobos because Phobos is present only in release  
 mode. If the zip distribution of DMD contains two Phobos and dmd  
 becomes able to use the right one according to the compilation  
 switches, then I think that "if (!condition) throw new Exception(args)"  
 will become more rare, and the enforce() too will be less commonly  
 needed.<


I was going off of this statement: "It doesn't allow functions to be nothrow. This is a fault, because D has Contract Programming, that is meant to be usable for nothrow functions too. D Contracts with asserts are the right tool." Sorry if I misunderstood. But enforce is a simple factoring of the if(!condition) throw Exception(msg) into an expression. It is meant to throw an exception and meant to be used in release mode. The only problem I see with it is the inline-killing. -Steve
Mar 17 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 17 Mar 2011 12:09:50 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:

 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-)

I think this is not as much an easy fix. By changing one line in enforce, every instance becomes inlinable. By making enforce also pure, it doesn't automatically make all users of enforce pure. I thought that lazy enforce cannot be pure, but I realize now that it can, as long as the delegate is pure. However, I think the compiler won't cooperate with that. If we temporarily disallow lazy and also make enforce pure, it will compile, but I'm worried one problem will be fixed and not the other, and then we are stuck with not being able to get the benefits of the lazy evaluation. I think the easiest thing to do right now is make enforce not lazy. That at least gets us inlining, which should be 90% of the performance problem with near-zero effort. If it makes sense in the future, we can also make it pure, or auto pure if that is ever supported. -Steve
Mar 17 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 17 Mar 2011 18:17:08 +0100, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Thu, 17 Mar 2011 12:09:50 -0400, bearophile  
 <bearophileHUGS lycos.com> wrote:

 Steven Schveighoffer:

 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-)

I think this is not as much an easy fix. By changing one line in enforce, every instance becomes inlinable. By making enforce also pure, it doesn't automatically make all users of enforce pure. I thought that lazy enforce cannot be pure, but I realize now that it can, as long as the delegate is pure. However, I think the compiler won't cooperate with that.

Not currently, at least. This made me wonder. A delegate created inside a pure function would have to be pure while in the scope of that function, right? Seems to me that should be possible to implement. -- Simen
Mar 17 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 17 Mar 2011 13:30:21 -0400, Simen kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Thu, 17 Mar 2011 18:17:08 +0100, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 On Thu, 17 Mar 2011 12:09:50 -0400, bearophile  
 <bearophileHUGS lycos.com> wrote:

 Steven Schveighoffer:

 The only problem I see with it is the inline-killing.

Please don't ignore the purity-killing :-)

I think this is not as much an easy fix. By changing one line in enforce, every instance becomes inlinable. By making enforce also pure, it doesn't automatically make all users of enforce pure. I thought that lazy enforce cannot be pure, but I realize now that it can, as long as the delegate is pure. However, I think the compiler won't cooperate with that.

Not currently, at least. This made me wonder. A delegate created inside a pure function would have to be pure while in the scope of that function, right? Seems to me that should be possible to implement.

As long as the delegate does not access shared/global data, it should be able to be pure. Even delegates which modify TLS data should be able to be pure (weak-pure, but still pure). This should be easy to enforce when the delegate is created automatically from an expression using a lazy call. However, we need some implicit casting rules for pure delegates into non-pure ones. -Steve
Mar 17 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2011 6:07 PM, Andrei Alexandrescu wrote:
 On 03/16/2011 06:45 PM, bearophile wrote:
 So a better solution is for the standard Phobos library to ship in two
 versions, one compiled in release and not release mode, and DMD may choose the
 right one according to the compilation switches. This removes most of the need
 of enforce(). I suggest to deprecate enforce(). Until the problem with Phobos
 compilation is solved and enforces are removed from Phobos, enforce() may
 become a private Phobos function that user code can't import.

There may be some confusion somewhere. enforce is not supposed to be a sort of assert. It is a different tool with a different charter. Use assert for assertions.

I want to emphasize Andrei's point. 1. Asserts and contracts are for detecting program BUGS. They are not for validating user input, checking for disk full, file not found errors, etc. 2. Enforce is for validating user input, checking for disk full, file not found errors, etc. Enforce is NOT for use in contracts or checking for program bugs. Any use of enforce in Phobos that is checking for program bugs is itself a bug and should be entered into bugzilla for fixing.
Mar 17 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 3/16/2011 6:07 PM, Andrei Alexandrescu wrote:
 On 03/16/2011 06:45 PM, bearophile wrote:
 So a better solution is for the standard Phobos library to ship in two
 versions, one compiled in release and not release mode, and DMD may choose the
 right one according to the compilation switches. This removes most of the need
 of enforce(). I suggest to deprecate enforce(). Until the problem with Phobos
 compilation is solved and enforces are removed from Phobos, enforce() may
 become a private Phobos function that user code can't import.

There may be some confusion somewhere. enforce is not supposed to be a sort of assert. It is a different tool with a different charter. Use assert for


 I want to emphasize Andrei's point.
 1. Asserts and contracts are for detecting program BUGS. They are not for
 validating user input, checking for disk full, file not found errors, etc.
 2. Enforce is for validating user input, checking for disk full, file not found
 errors, etc. Enforce is NOT for use in contracts or checking for program bugs.
 Any use of enforce in Phobos that is checking for program bugs is itself a bug
 and should be entered into bugzilla for fixing.

I've asked for this before and I'll ask again: Can we **please** put an alwaysAssert() function (or an abbreviation of this to make it less verbose) in Phobos? I proposed this once before and it wasn't well liked for some reason This reminded me to persist a little about it. I sometimes abuse enforce() for non-performance critical asserts that I don't want to ever be turned off, but that are semantically asserts in that they're supposed to reveal bugs, not check for within-spec errors. I know this is The Wrong Thing to do, but it's too convenient and useful to stop doing it unless I have a good alternative. The differences between enforce() and alwaysAssert() would be that alwaysAssert() throws an AssertError instead of an Exception and that they indicate different intents. alwaysAssert() could even be implemented in terms of enforce() using custom exceptions. Example implementation: void alwaysAssert(T, string file = __FILE__, string line = __LINE__) (T value, lazy string msg = null) { enforce!(T, file, line)(value, new AssertError(msg)); }
Mar 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 12:32 PM, dsimcha wrote:
 I've asked for this before and I'll ask again:  Can we **please** put an
 alwaysAssert() function (or an abbreviation of this to make it less verbose) in
 Phobos?  I proposed this once before and it wasn't well liked for some reason
 This reminded me to persist a little about it.

Not always the prettiest, but you can write: if (!condition) assert(0); The assert(0) will be replaced with a HLT instruction even in release mode.
Mar 17 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 3/17/2011 12:32 PM, dsimcha wrote:
 I've asked for this before and I'll ask again:  Can we **please** put an
 alwaysAssert() function (or an abbreviation of this to make it less verbose) in
 Phobos?  I proposed this once before and it wasn't well liked for some reason
 This reminded me to persist a little about it.

if (!condition) assert(0); The assert(0) will be replaced with a HLT instruction even in release mode.

This is better than nothing, but not enough to convince me to stop abusing enforce(). I much prefer to have a real alwaysAssert() function that gives a file, a line number and an error message.
Mar 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 1:49 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 3/17/2011 12:32 PM, dsimcha wrote:
 I've asked for this before and I'll ask again:  Can we **please** put an
 alwaysAssert() function (or an abbreviation of this to make it less verbose) in
 Phobos?  I proposed this once before and it wasn't well liked for some reason
 This reminded me to persist a little about it.

if (!condition) assert(0); The assert(0) will be replaced with a HLT instruction even in release mode.

This is better than nothing, but not enough to convince me to stop abusing enforce(). I much prefer to have a real alwaysAssert() function that gives a file, a line number and an error message.

if (!condition) { writeln("my message %s %s", __FILE__, __LINE__); assert(0); } I am strongly opposed to using enforce() for bug detection.
Mar 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/17/2011 05:03 PM, Walter Bright wrote:
 On 3/17/2011 1:49 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 3/17/2011 12:32 PM, dsimcha wrote:
 I've asked for this before and I'll ask again: Can we **please** put an
 alwaysAssert() function (or an abbreviation of this to make it less
 verbose) in
 Phobos? I proposed this once before and it wasn't well liked for
 some reason
 This reminded me to persist a little about it.

if (!condition) assert(0); The assert(0) will be replaced with a HLT instruction even in release mode.

This is better than nothing, but not enough to convince me to stop abusing enforce(). I much prefer to have a real alwaysAssert() function that gives a file, a line number and an error message.

if (!condition) { writeln("my message %s %s", __FILE__, __LINE__); assert(0); } I am strongly opposed to using enforce() for bug detection.

There's nothing wrong with encapsulating this idiom (if frequent). That's what essentially alwaysAssert does. So you're right but without contradicting dsimcha's suggestion. Andrei
Mar 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 3:08 PM, Andrei Alexandrescu wrote:
 if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
 assert(0); }

 I am strongly opposed to using enforce() for bug detection.

There's nothing wrong with encapsulating this idiom (if frequent). That's what essentially alwaysAssert does. So you're right but without contradicting dsimcha's suggestion.

Sure, but there is plenty wrong with using enforce() for bug detection even if alwaysAssert does not exist. For one thing, such uses encourage others to misunderstand and misuse enforce. Additionally, alwaysAssert is an obvious one liner. I think such things need to be very frequently used to consider them part of the standard library. Otherwise, we risk Phobos becoming a morass of trivia.
Mar 17 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 3/17/2011 7:12 PM, Walter Bright wrote:
 Sure, but there is plenty wrong with using enforce() for bug detection
 even if alwaysAssert does not exist. For one thing, such uses encourage
 others to misunderstand and misuse enforce.

 Additionally, alwaysAssert is an obvious one liner. I think such things
 need to be very frequently used to consider them part of the standard
 library. Otherwise, we risk Phobos becoming a morass of trivia.

What makes you think it wouldn't be used very frequently? It seems silly to me to turn off asserts in non-performance-critical bits of code just because I don't want bounds checking or the more expensive asserts.
Mar 17 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/17/2011 06:38 PM, dsimcha wrote:
 On 3/17/2011 7:12 PM, Walter Bright wrote:
 Sure, but there is plenty wrong with using enforce() for bug detection
 even if alwaysAssert does not exist. For one thing, such uses encourage
 others to misunderstand and misuse enforce.

 Additionally, alwaysAssert is an obvious one liner. I think such things
 need to be very frequently used to consider them part of the standard
 library. Otherwise, we risk Phobos becoming a morass of trivia.

What makes you think it wouldn't be used very frequently? It seems silly to me to turn off asserts in non-performance-critical bits of code just because I don't want bounds checking or the more expensive asserts.

To me it sounds perfectly normal that there are integrity checks that you want to keep at all times, whereas others you only want to keep in a debug build. Andrei
Mar 17 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 4:38 PM, dsimcha wrote:
 On 3/17/2011 7:12 PM, Walter Bright wrote:
 Sure, but there is plenty wrong with using enforce() for bug detection
 even if alwaysAssert does not exist. For one thing, such uses encourage
 others to misunderstand and misuse enforce.

 Additionally, alwaysAssert is an obvious one liner. I think such things
 need to be very frequently used to consider them part of the standard
 library. Otherwise, we risk Phobos becoming a morass of trivia.

What makes you think it wouldn't be used very frequently?

I don't know if it would or would not be used very frequently.
 It seems silly to me
 to turn off asserts in non-performance-critical bits of code just because I
 don't want bounds checking or the more expensive asserts.

The use case is more constrained than that. Because of the existence of: if (!condition) assert(0); the alwaysAssert is constrained to those purposes where the user feels the need for file/line/message for bug detection in released code, and also does not want to use: if (!condition) { writeln("my message %s %s", __FILE__, __LINE__); assert(0); } Furthermore, nothing prevents the user from writing his own alwaysAssert. For inclusion in Phobos, the more trivial something is, the higher utility it needs to have to justify it. Of course, there's an element of subjectivity to these judgments. One liners, though, should always be subject to significant scrutiny and justification. Once in, we'll be stuck with them for a long time.
Mar 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/11 7:16 PM, Walter Bright wrote:
 On 3/17/2011 4:38 PM, dsimcha wrote:
 On 3/17/2011 7:12 PM, Walter Bright wrote:
 Sure, but there is plenty wrong with using enforce() for bug detection
 even if alwaysAssert does not exist. For one thing, such uses encourage
 others to misunderstand and misuse enforce.

 Additionally, alwaysAssert is an obvious one liner. I think such things
 need to be very frequently used to consider them part of the standard
 library. Otherwise, we risk Phobos becoming a morass of trivia.

What makes you think it wouldn't be used very frequently?

I don't know if it would or would not be used very frequently.
 It seems silly to me
 to turn off asserts in non-performance-critical bits of code just
 because I
 don't want bounds checking or the more expensive asserts.

The use case is more constrained than that. Because of the existence of: if (!condition) assert(0); the alwaysAssert is constrained to those purposes where the user feels the need for file/line/message for bug detection in released code, and also does not want to use: if (!condition) { writeln("my message %s %s", __FILE__, __LINE__); assert(0); }

Note that you have (twice in two different posts) a bug in your code: you should have used writefln, not writeln. This humorously ruins your point, particularly because it's a bug likely to make it all the way to production (since that code path would normally not be exercised). Furthermore, the format of the message is decided with every call instead of centrally.
 Furthermore, nothing prevents the user from writing his own alwaysAssert.

Conversely, nothing prevents the library from defining a function if it deems it widely useful, even if short.
 For inclusion in Phobos, the more trivial something is, the higher
 utility it needs to have to justify it. Of course, there's an element of
 subjectivity to these judgments. One liners, though, should always be
 subject to significant scrutiny and justification. Once in, we'll be
 stuck with them for a long time.

Correct. There are also other criteria such as standardization. Primitives for logging would score strongly on the standardization scale, though they are often trivial to implement. You rose things debug and unittest all the way up to coveted keyword status because you correctly understood that, although such items could have easily been left to the implementation, everybody would have chosen their own devices creating a morass of incompatibility. I find it incongruent that you so strongly believe such success cannot be reproduced. Andrei
Mar 17 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 5:41 PM, Andrei Alexandrescu wrote:
 if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
 assert(0); }

Note that you have (twice in two different posts)

That's because I used cut & paste.
 a bug in your code: you should have used writefln, not writeln.

I made a mistake, I should have tested it.
 This humorously ruins your point,

Come on. In any case, it would print: my message %s %stest.d6 core.exception.AssertError test(6): Assertion failure and the information is still there, just badly formatted.
 Furthermore, nothing prevents the user from writing his own alwaysAssert.

widely useful, even if short.

Right. So is it so widely useful that it justifies the cognitive load of documentation of it and filling up Phobos with trivial stuff? It's not just alwaysAssert(), this particular issue comes up again and again. The last time it was for a suite of math functions that took degrees instead of radians. I think what we need in Phobos is nontrivial stuff. Things like the fast xml library, network code, database interface, etc.
 For inclusion in Phobos, the more trivial something is, the higher
 utility it needs to have to justify it. Of course, there's an element of
 subjectivity to these judgments. One liners, though, should always be
 subject to significant scrutiny and justification. Once in, we'll be
 stuck with them for a long time.

Correct. There are also other criteria such as standardization. Primitives for logging would score strongly on the standardization scale, though they are often trivial to implement. You rose things debug and unittest all the way up to coveted keyword status because you correctly understood that, although such items could have easily been left to the implementation, everybody would have chosen their own devices creating a morass of incompatibility. I find it incongruent that you so strongly believe such success cannot be reproduced.

There's a limited amount of such things one should do. Where does it stop? Each addition must be judged on its own merits, not on the merits of something else. As many have pointed out, D does not follow any of its principles 100%, because doing so will drive it into a ditch, as do all things that value adherence to principle over utility.
Mar 17 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/17/2011 06:12 PM, Walter Bright wrote:
 On 3/17/2011 3:08 PM, Andrei Alexandrescu wrote:
 if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
 assert(0); }

 I am strongly opposed to using enforce() for bug detection.

There's nothing wrong with encapsulating this idiom (if frequent). That's what essentially alwaysAssert does. So you're right but without contradicting dsimcha's suggestion.

Sure, but there is plenty wrong with using enforce() for bug detection even if alwaysAssert does not exist. For one thing, such uses encourage others to misunderstand and misuse enforce.

(I'm not sure what you even want to convey here as your statement does not contradict or oppose any other, yet is grammatically formulated as if it did. One may as well reply with "Yes, but the water's wet.") No question enforce would be wrong for bug detection. Using this would be just as wrong: if (undefinedState) throw new Exception("Hmm, odd..."); By packaging the if/throw combo, enforce becomes a notion, a part of the vocabulary, a meme if you wish. That makes it neither more nor less wrong for bug detection, but makes it plenty better for systematic error handling. Now, there is an additional issue that may confuse people on the relative roles of assert and enforce. We have faced the question, how do we validate arguments to a function in Phobos? Initially I used enforce() all over the place, under the assumption that Phobos' user and Phobos are separate entities. Therefore, any argument coming from outside Phobos would be necessarily considered I/O from within Phobos and therefore scrubbed accordingly. Then there was pressure on loss of efficiency due to checking, so I and others replaced certain instances of enforce() with assert(). This is not wrong at all. Instead, it reflects a different view of the dynamics between Phobos and its user: now Phobos + user code is considered as an entity that works together. So a failing assert in Phobos could describe a bug in Phobos itself or one in the application code that uses it. This is more ambiguous but not one bit less correct under the stated assumptions.
 Additionally, alwaysAssert is an obvious one liner. I think such things
 need to be very frequently used to consider them part of the standard
 library. Otherwise, we risk Phobos becoming a morass of trivia.

enforce() is an obvious one liner too. Size is not the only means to assess the usefulness of an abstraction. Two others are frequency of the pattern (think "writeln") and ascribing a meaningful name to it (think "unittest"). http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-12.html#%_sec_1.3 is a good read, let me paste: ========================= We have seen that procedures are, in effect, abstractions that describe compound operations on numbers independent of the particular numbers. For example, when we (define (cube x) (* x x x)) we are not talking about the cube of a particular number, but rather about a method for obtaining the cube of any number. Of course we could get along without ever defining this procedure, by always writing expressions such as (* 3 3 3) (* x x x) (* y y y) and never mentioning cube explicitly. This would place us at a serious disadvantage, forcing us to work always at the level of the particular operations that happen to be primitives in the language (multiplication, in this case) rather than in terms of higher-level operations. Our programs would be able to compute cubes, but our language would lack the ability to express the concept of cubing. One of the things we should demand from a powerful programming language is the ability to build abstractions by assigning names to common patterns and then to work in terms of the abstractions directly. Procedures provide this ability. This is why all but the most primitive programming languages include mechanisms for defining procedures. ========================= Andrei
Mar 17 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2011 5:02 PM, Andrei Alexandrescu wrote:
 [...]

I don't disagree with anything you wrote. But I am suggesting that one liners should have a high utility to be justifiably included in Phobos. --------------------------------- You mentioned wondering where we should draw the line in using asserts to check function inputs as opposed to using enforce. I suggest that line should be when a shared library/dll boundary is crossed. Statically linked libs should use assert. The reason is straightforward - a shared library/dll cannot know in advance what will be connected to it, so it should treat data coming in from an external source as untrusted input. A statically linked library, on the other hand, is inextricably bound to a specific caller and is debugged/tested as a whole. This raises the spectre about what to do with Phobos if Phobos is built as a dll.
Mar 17 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/11 7:31 PM, Walter Bright wrote:
 On 3/17/2011 5:02 PM, Andrei Alexandrescu wrote:
  > [...]


 I don't disagree with anything you wrote. But I am suggesting that one
 liners should have a high utility to be justifiably included in Phobos.

 ---------------------------------

 You mentioned wondering where we should draw the line in using asserts
 to check function inputs as opposed to using enforce. I suggest that
 line should be when a shared library/dll boundary is crossed. Statically
 linked libs should use assert.

 The reason is straightforward - a shared library/dll cannot know in
 advance what will be connected to it, so it should treat data coming in
 from an external source as untrusted input. A statically linked library,
 on the other hand, is inextricably bound to a specific caller and is
 debugged/tested as a whole.

 This raises the spectre about what to do with Phobos if Phobos is built
 as a dll.

These are all very good points and insights. We should keep them in mind. Andrei
Mar 17 2011
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-03-17 20:31:43 -0400, Walter Bright <newshound2 digitalmars.com> said:

 On 3/17/2011 5:02 PM, Andrei Alexandrescu wrote:
  > [...]
 
 
 I don't disagree with anything you wrote. But I am suggesting that one 
 liners should have a high utility to be justifiably included in Phobos.
 
 ---------------------------------
 
 You mentioned wondering where we should draw the line in using asserts 
 to check function inputs as opposed to using enforce. I suggest that 
 line should be when a shared library/dll boundary is crossed. 
 Statically linked libs should use assert.
 
 The reason is straightforward - a shared library/dll cannot know in 
 advance what will be connected to it, so it should treat data coming in 
 from an external source as untrusted input. A statically linked 
 library, on the other hand, is inextricably bound to a specific caller 
 and is debugged/tested as a whole.
 
 This raises the spectre about what to do with Phobos if Phobos is built 
 as a dll.

This would be much easier to work with if the decision about checking "in" contracts was taken at the call site. If user code is compiled with contracts, any user code calling Phobos would check the contracts too, dynamic library or not. One way to make this work is by making the compiler take the contract as a separate function to call. For instance, this function: int test(int i) in { assert(i >= 0); } body { return 100 / i; } would be split in two: int testContract(int i) { assert(i >= 0); return test(i); // could hard-code tail call optimization here } int test(int i) { return 100 / i; } If the function that calls this test function is compiled with contracts turned on, it substitutes the call to test() for a call to testContract(), and the contracts gets checked. The testContract() function does not necessarily need to be part of the library, it can be instantiated as needed at the call point. It could even work with virtual functions: if test() is virtual, testContract() would remain non-virtual and a call to the virtual function test() would be replaced with a call to the non-virtual function testContract() (which would be charged to call test). There's two concerns however: 1. the contract would be checked against the static type instead of the dynamic type as it is right now. Checking against the dynamic type would require a new slot on the vtable -- or a separate vtable, perhaps inside of the ClassInfo -- which would require contracts for public and protected functions to be part of the library at all times. 2. taking the address of a function (or a delegate) could give you the one that includes the contract if contracts are turned on, but that would mean that code compiled with contracts and code compiled without them would get different addresses for the same function inside of the same executable, which could break some expectations. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 17 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 17, 2011 18:23:51 Andrei Alexandrescu wrote:
 On 3/17/11 7:31 PM, Walter Bright wrote:
 On 3/17/2011 5:02 PM, Andrei Alexandrescu wrote:
  > [...]
 
 I don't disagree with anything you wrote. But I am suggesting that one
 liners should have a high utility to be justifiably included in Phobos.
 
 ---------------------------------
 
 You mentioned wondering where we should draw the line in using asserts
 to check function inputs as opposed to using enforce. I suggest that
 line should be when a shared library/dll boundary is crossed. Statically
 linked libs should use assert.
 
 The reason is straightforward - a shared library/dll cannot know in
 advance what will be connected to it, so it should treat data coming in
 from an external source as untrusted input. A statically linked library,
 on the other hand, is inextricably bound to a specific caller and is
 debugged/tested as a whole.
 
 This raises the spectre about what to do with Phobos if Phobos is built
 as a dll.

These are all very good points and insights. We should keep them in mind.

It also brings us back to one of Bearophile's concerns. If you want assertions to be enabled in Phobos, you need a non-release build, and Phobos is distributed in non-release build. The only way to have a non-release build is to build it yourself and replace your libphobos.a (or phobos.lib) with the non-release version. Some folks want a way to make it so that there's a release and non- release version of Phobos and dmd picks the release version when you compile with -release and picks the non-release version otherwise. - Jonathan M Davis
Mar 17 2011