On Monday, July 10, 2017 1:28:44 PM MDT Jacob Carlborg via Digitalmars-d wrote:
> On 2017-07-08 04:13, Jonathan M Davis via Digitalmars-d wrote:
> > I tend to agree - in many cases, the error message is completely redundant - but a number of folks seem to think that you should never have an assertion without a message, and it tends to get complained about if you have an assertion without a message if it's not in a unit test, so I'm a bit surprised that the OP ran into one in Phobos.
>
> I think it's extremely useful to have, especially in a code base you're not familiar with or is complicated. It has happened to me quite often that I hit asserts in DMD when I develop on that code base. It would help me a lot if all those asserts had descriptive messages.

That only helps if there's something to describe. Often, it's something like

assert(!range.empty);

in which case, there really isn't much to say. I totally agree that assertion messages can be helpful when there's something to explain, but there often really isn't, and all a message is going to do is repeat the condition being checked in English, which is just pointless text.

- Jonathan M Davis

On 2017-07-10 15:45, Jonathan M Davis via Digitalmars-d wrote:

> That only helps if there's something to describe. Often, it's something like
> 
> assert(!range.empty);
> 
> in which case, there really isn't much to say. I totally agree that
> assertion messages can be helpful when there's something to explain, but
> there often really isn't, and all a message is going to do is repeat the
> condition being checked in English, which is just pointless text.

Well, in this case it could include why the range cannot be empty. But in the case of ranges it's pretty clear, if you know how the whole range concept works.

-- 
/Jacob Carlborg

On Monday, 10 July 2017 at 13:52:22 UTC, Jacob Carlborg wrote:
> On 2017-07-10 15:45, Jonathan M Davis via Digitalmars-d wrote:
>
>> [...]
>
> Well, in this case it could include why the range cannot be empty.

If either the name of the function was non-descriptive or the function's documentation string (and assert messages are also just documentation) doesn't make it obvious why, sure.

> But in the case of ranges it's pretty clear, if you know how the whole range concept works.

Even if you don't know about ranges, the function's name (pop*, remove*, extract*, etc.) virtually always implies a state mutating operation removing something.