October 01, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On 10/01/2015 01:19 PM, Per Nordlöw wrote:
> On Thursday, 1 October 2015 at 14:37:55 UTC, Andrei Alexandrescu wrote:
>> Whoever wants to work on better assert expression printing: make sure
>> you specify which grammar constructs are supported, and how the parts
>> involved are printed. Expressing semantics via lowering would be
>> great. Write a DIP, discuss, implement. I'll have your six.
>>
>>
>> Andrei
>
> A first version:
>
> http://wiki.dlang.org/DIP83
A good start. Few thoughts:
* I don't think we need a new flag, just make the new behavior work.
* Should the lowering happen only on the function called if the assertion actually fails? Then no more need for laziness and other complications.
* Extend to other expressions (!=, ordering etc).
Andrei
|
October 01, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
>
> I encourage making assert smarter seeing (a) it's already used
> everywhere so the benefits will come for free and (b) it's a built-in.
> -- Andrei
About (b): I'm surprised to see that you seem to have so fundamentally changed your attitude towards magical semantics for built-ins.
|
October 01, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 10/01/2015 06:41 PM, Timon Gehr wrote:
> On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
>>
>> I encourage making assert smarter seeing (a) it's already used
>> everywhere so the benefits will come for free and (b) it's a built-in.
>> -- Andrei
>
> About (b): I'm surprised to see that you seem to have so fundamentally
> changed your attitude towards magical semantics for built-ins.
I haven't - I still think making "assert" a built-in and ascribing a keyword to it was a minor mistake. But then that sail has shipped, so let's make the best use of the situation. -- Andrei
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 10/02/2015 01:33 AM, Andrei Alexandrescu wrote:
> On 10/01/2015 06:41 PM, Timon Gehr wrote:
>> On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
>>>
>>> I encourage making assert smarter seeing (a) it's already used
>>> everywhere so the benefits will come for free and (b) it's a built-in.
>>> -- Andrei
>>
>> About (b): I'm surprised to see that you seem to have so fundamentally
>> changed your attitude towards magical semantics for built-ins.
>
> I haven't - I still think making "assert" a built-in and ascribing a
> keyword to it was a minor mistake. But then that sail has shipped, so
> let's make the best use of the situation. -- Andrei
>
Ok, but if assert gets special error printing capabilities that are not available at the same level of convenience to e.g. enforce, then this is a roughly analogous situation to having e.g. B[] : const(A)[] for B : A, which cannot currently be simulated in the library in a satisfactory way. Those situations usually add friction. They tend to result in frustration and often culminate in proposals for new, often ad-hoc language features. IMHO, there ought to be a better way, but I don't have a very strong opinion about this particular case.
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 1 October 2015 at 23:33:39 UTC, Andrei Alexandrescu wrote:
> I haven't - I still think making "assert" a built-in and ascribing a keyword to it was a minor mistake. But then that sail has shipped, so let's make the best use of the situation. -- Andrei
Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | On Friday, 2 October 2015 at 00:25:18 UTC, jmh530 wrote:
> Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.
It could, for example, still be in object.
— David
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Friday, 2 October 2015 at 00:05:33 UTC, Timon Gehr wrote:
> On 10/02/2015 01:33 AM, Andrei Alexandrescu wrote:
>> On 10/01/2015 06:41 PM, Timon Gehr wrote:
>>> On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
>>>>
>>>> I encourage making assert smarter seeing (a) it's already used
>>>> everywhere so the benefits will come for free and (b) it's a built-in.
>>>> -- Andrei
>>>
>>> About (b): I'm surprised to see that you seem to have so fundamentally
>>> changed your attitude towards magical semantics for built-ins.
>>
>> I haven't - I still think making "assert" a built-in and ascribing a
>> keyword to it was a minor mistake. But then that sail has shipped, so
>> let's make the best use of the situation. -- Andrei
>>
>
> Ok, but if assert gets special error printing capabilities that are not available at the same level of convenience to e.g. enforce, then this is a roughly analogous situation to having e.g. B[] : const(A)[] for B : A, which cannot currently be simulated in the library in a satisfactory way. Those situations usually add friction. They tend to result in frustration and often culminate in proposals for new, often ad-hoc language features. IMHO, there ought to be a better way, but I don't have a very strong opinion about this particular case.
On the other hand, changing the language to provide access to this as library would require something macro like, and both Andrei and Walter seems to be really against it.
As we are on assert, 2 things :
- Before considering adding more magic, can we get line numbers in stack traces ? It really seems to me like improving the message no stack trace is available is not focusing on impact.
- assert already have a fair amount of magic, notably assert(0) change the way control flow works. Having it as an expression is making everything very convoluted for no reason.
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On Friday, 2 October 2015 at 00:33:13 UTC, David Nadlinger wrote:
> On Friday, 2 October 2015 at 00:25:18 UTC, jmh530 wrote:
>> Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.
>
> It could, for example, still be in object.
Yeah. We already have that with several symbols (e.g. size_t and string), and arguably we should do it with a few others (like the range primitives for arrays). So, if we'd made new and assert into library functions instead of built-ins like we arguably should have been, then they'd probably be in object.d, but that shipped has long since sailed.
- Jonathan M Davis
|
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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? I'm currently unsure whether in L lhs or lazy L lhs should be used and whether or not we should use version(assert) 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? |
October 02, 2015 Re: Improving assert-printing in DMD | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | On Thursday, 1 October 2015 at 17:33:51 UTC, Jack Stouffer wrote:
> Bikesheading: could you change "being" in "([1,2,3][2] being 3) != ([1,2,4][2] being 4)" and the other examples to "is"?
Done.
|
Copyright © 1999-2021 by the D Language Foundation