assume, assert, enforce, @safe

Sean Kelly via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 1 15:59:19 PDT 2014


On Friday, 1 August 2014 at 21:42:07 UTC, Jonathan M Davis wrote:
> On Friday, 1 August 2014 at 14:10:14 UTC, Sean Kelly wrote:
>> On Friday, 1 August 2014 at 08:21:28 UTC, Kagamin wrote:
>>> On Thursday, 31 July 2014 at 21:29:59 UTC, Sean Kelly wrote:
>>>> So effectively, any factor occurring at runtime.  If I 
>>>> create a
>>>> library, it is acceptable to validate function parameters 
>>>> using
>>>> assert() because the user of that library knows what the 
>>>> library
>>>> expects and should write their code accordingly.  That's 
>>>> fair.
>>>
>>> He should, but what if he doesn't and the library is phobos 
>>> or druntime (which are compiled in release mode)? BTW, 
>>> druntime can't use enforce and doesn't verify its input.
>>
>> Druntime uses contracts and asserts in places. Which are of 
>> course removed because we ship only a "release" build.  Once 
>> again, the worst naming for a compiler switch ever. What I 
>> really want is a way to ship release and non-release builds 
>> (ie. checked and unchecked) and have the proper one chosen at 
>> link time based on build flags. Basically toss the -defaultlib 
>> and -debuglib and replace it with -checkedlib and 
>> -uncheckedlib.
>
> Well, to be fair, it's pretty standard practice to remove all 
> assertions in release builds in other languages. If anything, 
> leaving them in is highly abnormal. Sure, there are reasons to 
> do it, but most folks don't. So, while I can see why you don't 
> like the switch being called -release, it's behavior matches 
> what most people would do for release builds.

But is it what they *should* do?  Quoting Matthew Wilson's "The
Nuclear Reactor and the Deep Space Probe"
(http://www.artima.com/cppsource/deepspaceP.html):

"Assertions in C and C++ tend to be included in debug builds
only, and elided in release builds for performance reasons.
However, as the programming community appreciation for contract
programming grows, there is increasing interest in using contract
enforcement in release builds. Indeed, as we'll see in part 4 of
this article, there is a very good argument for leaving contracts
in released software, since the alternative may be worse,
sometimes catastrophically so."

I wish the rest of the series were available online.  I think I
had copies of later versions but can't find them.


More information about the Digitalmars-d mailing list