On 10/02/2015 02:31 AM, Per Nordlöw wrote:
On Thursday, 1 October 2015 at 19:04:51 UTC, Andrei Alexandrescu wrote:
* I don't think we need a new flag, just make the new behavior work.
So you mean that extra diagnostics should kick in when extra overloads
are made visible via import of, for instance, `core.assert`?
* Should the lowering happen only on the function called if the
assertion actually fails? Then no more need for laziness and other
complications.
Could explain what you mean by *lowering*, please?
Rewrite proposed constructs into simpler constructs that already exist.
That way we don't need to invent semantics, just "see lowering".
I'm currently unsure whether
in L lhs
or
lazy L lhs
That's why I think it's better to go with calling the function only
after the assertion has failed. E.g.,
assert(e1 == e2)
could be lowered into:
{
auto a = e1, b = e2;
if (a == b) return;
onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__, __MODULE__);
}()
or something similar (I'm glossing over the details). Point is the
expressions are only evaluated once and then passed into onAssertFailed.
There'd be a default definition of onAssertFailed in object.d.
should be used and whether or not we should use
version(assert)
Yah, all expansions related to assert() are only in effect if assertions
are used. Otherwise, assert disappears and that's not configurable.
See the added example at
http://wiki.dlang.org/DIP83
* Extend to other expressions (!=, ordering etc).
How should we categorize expressions? Like this
- Unary: assert(x UNOP y)
- Binary: assert(x BINOP y)
- Function Calls: assert(f(x,y))
- Other: assert(x)
Does it suffice to just mention these or should I be explicit exactly
about which operators for each category that should be included?
I think you should use the names of the grammatical constructs, e.g.
http://dlang.org/expression.html#EqualExpression.
Andrei
