www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - assert or throw in range members?

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Should range members front() and back() assert() or throw() on 
emptyness?

If it should assert() doesn't that lead to unsafer code in 
release mode?

What's the consensus here?
Aug 05 2016
next sibling parent Cauterite <cauterite gmail.com> writes:
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
 Should range members front() and back() assert() or throw() on 
 emptyness?
I'm pretty sure it's assert() here. The contract is that the caller is responsible for checking emptiness beforehand, and the whole of Phobos is coded around that contract. I think.
 If it should assert() doesn't that lead to unsafer code in 
 release mode?
That's the point of release mode. Omitting superfluous checks based on the assumption that your code is correct (e.g. assumption that the emptiness contract is respected).
Aug 05 2016
prev sibling next sibling parent ag0aep6g <anonymous example.com> writes:
On 08/05/2016 12:25 PM, Nordlöw wrote:
 Should range members front() and back() assert() or throw() on emptyness?

 If it should assert() doesn't that lead to unsafer code in release mode?

 What's the consensus here?
It's an error in the program when front/back is called on an empty range. Every program must be written so that this cannot ever happen. assert is for catching programming errors. So assert is ok here. Not checking at all would be ok, too, but assert is a bit nicer to the user of the range, of course.
Aug 05 2016
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
 Should range members front() and back() assert() or throw() on 
 emptyness?

 If it should assert() doesn't that lead to unsafer code in 
 release mode?

 What's the consensus here?
if you can and it is not costly, do `assert(false, "BOOM!");` there. as it is UB anyway, you can make programmer's life little easier. ;-) also, `assert()` doesn't break nogc, if somebody cares.
Aug 05 2016
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, August 05, 2016 10:25:42 Nordlw via Digitalmars-d-learn wrote:
 Should range members front() and back() assert() or throw() on
 emptyness?

 If it should assert() doesn't that lead to unsafer code in
 release mode?

 What's the consensus here?
It is a programming error for any range members other than empty, length, or save to be called when a range is empty. So, it definitely should not be an exception. Phobos asserts on such things, though if you're paranoid about it, you can always explicitly throw an Error of some kind (e.g. RangeError). But that will incur a performance hit in release mode, and it's perfectly normal for checks like this to not be enabled in release mode. Testing is supposed to catch such problems before you actually release your code. Regardless, throwing an Exception is the wrong behavior, because it's considered a programming error for those functions to be called when a range is empty. Nothing should ever result in front or back being called when the range is empty. - Jonathan M Davis
Aug 05 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
 If it should assert() doesn't that lead to unsafer code in 
 release mode?

 What's the consensus here?
It is unsafer, the rationale is that your code should be debugged to comply with the assumption of the release mode that there are no bugs. The consensus is that it's ok that the assumption is backed by a hope (there were bugs that would be caught by asserts and bound checks, but weren't).
Aug 05 2016
prev sibling next sibling parent reply H.Loom <loom grossnet.az> writes:
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
 Should range members front() and back() assert() or throw() on 
 emptyness?

 If it should assert() doesn't that lead to unsafer code in 
 release mode?

 What's the consensus here?
nothing, but examples exist in pbobos such as front() on narrow strings.
Aug 05 2016
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Friday, August 05, 2016 15:50:50 H.Loom via Digitalmars-d-learn wrote:
 On Friday, 5 August 2016 at 10:25:42 UTC, Nordlw wrote:
 Should range members front() and back() assert() or throw() on
 emptyness?

 If it should assert() doesn't that lead to unsafer code in
 release mode?

 What's the consensus here?
nothing, but examples exist in pbobos such as front() on narrow strings.
That's because of invalid Unicode, not because the string was empty. It asserts that the string is non-empty. No code anywhere should ever be calling front or back on an empty range, and it is a programming error if it does, not a recoverable error. We obviously don't have control over what everyone else does with their code, but Phobos does not throw an exception in such cases - it asserts if it does anything - and it is definitely the consensus of the main devs that you're not using the range API correctly if code ever calls front or back on an empty range. It is a bug to do so. There were even some recent updates to the documentation to make some of the basic rules around the range primitives clearer, though since it was in the documenation for std.range, it won't be up until the next release: https://github.com/dlang/phobos/pull/4511 - Jonathan M Davis
Aug 05 2016
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/5/16 6:25 AM, Nordlöw wrote:
 Should range members front() and back() assert() or throw() on emptyness?

 If it should assert() doesn't that lead to unsafer code in release mode?

 What's the consensus here?
If the code is safe, then it should trigger an error if you try to do unsafe things, regardless of asserts. If you mark front or back or whatever safe, and do unsafe things, then you will have to mark it as trusted. In this case, instead of asserting, use if(cond) assert(0), or use enforce, as you can't allow unsafe behavior in a trusted function based on the -release switch. -Steve
Aug 05 2016