I'm seeing another idiom that seems to become fashionable. Consider this excerpt from https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:

            auto opSlice(size_t low, size_t high)
            in
            {
                assert(low <= high);
            }
            body
            {
                import std.range : take;
                return this[low .. $].take(high - low);
            }

which of course trivially boils down to:

            auto opSlice(size_t low, size_t high)
            {
                assert(low <= high);
                import std.range : take;
                return this[low .. $].take(high - low);
            }

What advantage could possibly be in transforming a 5-liner into a 9-liner? Are we really aiming at writing the maximum possible lines of code here and using as many language features as possible everywhere?

I think we should dust off that Phobos contributors' guide. Sadly, there is little we can do against the more subtle issues.


Andrei

On 5/02/2015 1:24 p.m., Andrei Alexandrescu wrote:
> I'm seeing another idiom that seems to become fashionable. Consider this
> excerpt from
> https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
>
>
>              auto opSlice(size_t low, size_t high)
>              in
>              {
>                  assert(low <= high);
>              }
>              body
>              {
>                  import std.range : take;
>                  return this[low .. $].take(high - low);
>              }
>
> which of course trivially boils down to:
>
>              auto opSlice(size_t low, size_t high)
>              {
>                  assert(low <= high);
>                  import std.range : take;
>                  return this[low .. $].take(high - low);
>              }
>
> What advantage could possibly be in transforming a 5-liner into a
> 9-liner? Are we really aiming at writing the maximum possible lines of
> code here and using as many language features as possible everywhere?
>
> I think we should dust off that Phobos contributors' guide. Sadly, there
> is little we can do against the more subtle issues.
>
>
> Andrei

So are we recommending against contract based programming for simple getter type methods?
Personally I think those auto's are more important to get rid of in this code. They actually do harm for anyone reading the docs.

Andrei Alexandrescu:

>             auto opSlice(size_t low, size_t high)
>             in
>             {
>                 assert(low <= high);
>             }
>             body
>             {
>                 import std.range : take;
>                 return this[low .. $].take(high - low);
>             }
>
> which of course trivially boils down to:
>
>             auto opSlice(size_t low, size_t high)
>             {
>                 assert(low <= high);
>                 import std.range : take;
>                 return this[low .. $].take(high - low);
>             }
>
> What advantage could possibly be in transforming a 5-liner into a 9-liner?

Contracts can be read by tools, and they are part of the function signature. Contracts should be encouraged and increased, not discouraged.

Bye,
bearophile

On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
> Contracts can be read by tools, and they are part of the function signature. Contracts should be encouraged and increased, not discouraged.


I agree. Moreover, if the assert fails in the contract, in theory, we can point the error at the user's code. An assert inside the function is the function's responsibility. An assert in an in contract is the caller's responsibility. They're semantically different (even if dmd treats them the same way)

On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>>            auto opSlice(size_t low, size_t high)
>>            in
>>            {
>>                assert(low <= high);
>>            }
>>            body
>>            {
>>                import std.range : take;
>>                return this[low .. $].take(high - low);
>>            }
>>
auto opSlice(size_t low, size_t high)
    in { assert(low <= high); }
body
{

}

On 2/4/15 4:30 PM, Rikki Cattermole wrote:
> So are we recommending against contract based programming for simple
> getter type methods?

The shorter version is as contract based as the other.

> Personally I think those auto's are more important to get rid of in this
> code. They actually do harm for anyone reading the docs.

That would be a separate discussion.


Andrei

On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
> Contracts can be read by tools, and they are part of the function signature. Contracts should be encouraged and increased, not discouraged.
>
> Bye,
> bearophile

Not to mention that contracts can be removed by the compiler at compile time. i.e.

x.opSlice(i, i+1);

The assert can be compiled away since i+1 is always >= i. That's one of the great benefits of contracts.

On 2/4/15 4:35 PM, bearophile wrote:
> Contracts can be read by tools, and they are part of the function
> signature.

The signature part matters only for overridable functions. I agree the part about tooling has merit. -- Andrei

On 2/4/15 4:40 PM, Jonathan Marler wrote:
> On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
>> Contracts can be read by tools, and they are part of the function
>> signature. Contracts should be encouraged and increased, not discouraged.
>>
>> Bye,
>> bearophile
>
> Not to mention that contracts can be removed by the compiler at compile
> time.

Same about asserts. -- Andrei

On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
> On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
>> Contracts can be read by tools, and they are part of the function
>> signature. Contracts should be encouraged and increased, not discouraged.
>
>
> I agree. Moreover, if the assert fails in the contract, in theory, we
> can point the error at the user's code. An assert inside the function is
> the function's responsibility. An assert in an in contract is the
> caller's responsibility. They're semantically different (even if dmd
> treats them the same way)

Yah I concede this is a good point. Yet we're looking at an actual liability and are supposed to look at some vague possible future benefit. -- Andrei