September 19, 2020
On 9/18/20 4:13 AM, Timon Gehr wrote:
> On 17.09.20 23:55, Andrei Alexandrescu wrote:
>>
>> Flag!"each" each(Range) (
>>    Range r
>> )
>> if (!isForeachIterable!Range && (isRangeIterable!Range || __traits(compiles, typeof(r.front).length)));
> 
> So `each` says it works for types that cannot be iterated with `foreach` but whose `front` has a `length` member? :-)
> 
> Turns out it does not:
> 
> ----
> import std.algorithm;
> struct S{
>      struct T{
>          struct Q{}
>          Q length;
>      }
>      T front;
> }
> 
> void main(){
>      S().each!((x){});
> }
> ----
> std/algorithm/iteration.d(966): Error: template `std.range.primitives.empty` cannot deduce function from argument types `!()(S)`, candidates are:
> ...
> ----
> 
> https://issues.dlang.org/show_bug.cgi?id=21264

Thanks. It's interesting that those who opined the constraints are pretty easy to read didn't even notice this one's wrong. If you think it's easy and got it wrong, it's not easy!

Second, the same argument applies to assert. Why provide a string with the assert when all it does is it repeats the expression in human language? Yet most asserts do provide explanatory strings, and I can only assume many people find those useful.

The mechanics is not the design.
September 19, 2020
On Saturday, 19 September 2020 at 14:44:18 UTC, Andrei Alexandrescu wrote:
> Why provide a string with the assert when all it does is it repeats the expression in human language?


I'm not necessarily against providing a string - indeed, in my proposal, you would provide strings, plural - but the questions of what they are, how they got there, and when they are specified are inadequately answered by this DIP.

> Yet most asserts do provide explanatory strings, and I can only assume many people find those useful.

this is apples and oranges anyway because with asserts you can't see the original source and values that failed without extra steps. "foo.d:3 Assertion failure" isn't exactly great.
September 19, 2020
On 9/19/20 10:55 AM, Adam D. Ruppe wrote:
> "foo.d:3 Assertion failure" isn't exactly great.

Huh. I was sure D includes the failing expression a la C. Apparently I haven't seen a bald assert in a long time.
September 19, 2020
On Saturday, 19 September 2020 at 14:55:09 UTC, Adam D. Ruppe wrote:
> On Saturday, 19 September 2020 at 14:44:18 UTC, Andrei Alexandrescu wrote:
>
> this is apples and oranges anyway because with asserts you can't see the original source and values that failed without extra steps. "foo.d:3 Assertion failure" isn't exactly great.

Huh, you are aware of -checkaction-context right?

We should just make it the default for all non-release builds.
September 19, 2020
On Saturday, 19 September 2020 at 15:17:50 UTC, Seb wrote:
> Huh, you are aware of -checkaction-context right?

Of course, that's why I said "without extra steps".

If it was the default, I suspect the amount of strings we see would decrease.

> We should just make it the default for all non-release builds.

yeah, the message is a lot nicer since it even prints out the values!
1 2 3 4
Next ›   Last »