On Wednesday, 28 October 2020 at 15:25:18 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 October 2020 at 15:05:19 UTC, Paul Backus wrote:
>> You can add an initial value outside of the fold expression:
>>
>>     false || Tup == 10 || ...
>
> Ok, but the problem is in generic code. You could adopt init as the initial value for fold, but it fails miserably for floats as they don't have 0 as the init, but NaN...
>
> Will it work with overloads so that the initial value can be a completely different type? (If you want to trap empty tuples, but have no unused value.)

Generic code can deal with this the same way std.algorithm.reduce does: by taking the initial value as a parameter, or by requiring that the tuple be non-empty.

On Wednesday, 28 October 2020 at 15:30:28 UTC, Paul Backus wrote:
> Generic code can deal with this the same way std.algorithm.reduce does: by taking the initial value as a parameter, or by requiring that the tuple be non-empty.

What I meant is what if the library author provided a function for "numbers", but never tested the code with floats. If the initial value is required then the library author would have remembered to set the initial value to "cast(T)0" for addition or "cast(T)1" for multiplication.

On Wednesday, 28 October 2020 at 15:43:24 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 October 2020 at 15:30:28 UTC, Paul Backus wrote:
>> Generic code can deal with this the same way std.algorithm.reduce does: by taking the initial value as a parameter, or by requiring that the tuple be non-empty.
>
> What I meant is what if the library author provided a function for "numbers", but never tested the code with floats. If the initial value is required then the library author would have remembered to set the initial value to "cast(T)0" for addition or "cast(T)1" for multiplication.

The library author could just as easily use `T.init` as the initial value, and if the code is never tested with floats, it will appear to work just fine. So requiring an initial value does nothing to prevent this hypothetical bug.

On Wednesday, 28 October 2020 at 17:48:21 UTC, Paul Backus wrote:
> The library author could just as easily use `T.init` as the initial value, and if the code is never tested with floats, it will appear to work just fine. So requiring an initial value does nothing to prevent this hypothetical bug.

No, it is common to fold with 0 for addition and 1 for multiplication. Anyone that has some programming background will use that when the think about initial value.

Or "zero" and "identity", which in my view should be traits for numbers. In my own lib for generic programming I use those. Then you can write generic code that work for matrices etc.

On Wednesday, 28 October 2020 at 17:52:41 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 October 2020 at 17:48:21 UTC, Paul Backus wrote:
>> The library author could just as easily use `T.init` as the initial value, and if the code is never tested with floats, it will appear to work just fine. So requiring an initial value does nothing to prevent this hypothetical bug.
>
> No, it is common to fold with 0 for addition and 1 for multiplication. Anyone that has some programming background will use that when the think about initial value.

The bug you described in your previous post can only ever occur if the programmer uses an incorrect initial value, not if he or she forgets to include an initial value. If you are willing to assume that the programmer will not use an incorrect initial value, then the bug you are (supposedly) worried about will never occur in the first place.

On Wednesday, 28 October 2020 at 18:00:15 UTC, Paul Backus wrote:
> The bug you described in your previous post can only ever occur if the programmer uses an incorrect initial value, not if he or she forgets to include an initial value. If you are willing to assume that the programmer will not use an incorrect initial value, then the bug you are (supposedly) worried about will never occur in the first place.

No, the bug I described is when you take an empty tuple. What will the value be when nobody provided an initial value?

Say, for a matrix.

On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> 
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

The DIP brings compile-time improvements, but this is a feature relatively reserved for the standard library so perhaps the blocker is that is also has an easy syntax;
Being an operator it brings many new questions such as precedence, syntax compatibility, whereas if it was a compiler intrinsic like __mapTuple (very bad name) the quantity of debate would be less perhaps?
Possibly it could remain "niche" and with loud syntax and we would still gain the compile-time improvements.

On Wednesday, 28 October 2020 at 22:42:16 UTC, Guillaume Piolat wrote:
> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
>> 
>> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> The DIP brings compile-time improvements, but this is a feature relatively reserved for the standard library so perhaps the blocker is that is also has an easy syntax;
> Being an operator it brings many new questions such as precedence, syntax compatibility, whereas if it was a compiler intrinsic like __mapTuple (very bad name) the quantity of debate would be less perhaps?
> Possibly it could remain "niche" and with loud syntax and we would still gain the compile-time improvements.

As is amply evident from the history of __traits, making something ugly on purpose will not stop people from using it, it will just cause needless aggravation for them when they do.

If this is worth doing, it's worth doing right.

On Wed, Oct 28, 2020 at 11:39:08PM +0000, Paul Backus via Digitalmars-d wrote:
> On Wednesday, 28 October 2020 at 22:42:16 UTC, Guillaume Piolat wrote:
[...]
> > The DIP brings compile-time improvements, but this is a feature relatively reserved for the standard library so perhaps the blocker is that is also has an easy syntax;
[...]
> As is amply evident from the history of __traits, making something ugly on purpose will not stop people from using it, it will just cause needless aggravation for them when they do.
> 
> If this is worth doing, it's worth doing right.

+1.  I think it's a mistake to differentiate between "user code" and "standard library code"; IMO properly-designed code generally should be >95% library and <5% driver-specific code.  Meaning that if a feature is useful for the standard library, then it's useful for user code, and should be designed with that in mind.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.

On Thu, Oct 29, 2020 at 8:45 AM Guillaume Piolat via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 27 October 2020 at 10:54:07 UTC, Mike Parker wrote:
> >
> > Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> The DIP brings compile-time improvements, but this is a feature
> relatively reserved for the standard library so perhaps the
> blocker is that is also has an easy syntax;
> Being an operator it brings many new questions such as
> precedence, syntax compatibility, whereas if it was a compiler
> intrinsic like __mapTuple (very bad name) the quantity of debate
> would be less perhaps?
> Possibly it could remain "niche" and with loud syntax and we
> would still gain the compile-time improvements.
>

I'm not sure what you mean it's reserved for the standard library? That is
definitely not the case.
This is intended to be used by users who want to write good code.