On Thursday, 20 July 2017 at 14:05:36 UTC, Iakh wrote:
> It is not about reduce number of lines. It is about binding
> related things in one statement.

Even so, it's already been shown in this thread that the same effect can be achieved via a block statement (doing exactly what it was designed for) or with a for loop.

It's an small increase in terseness for a decrease in readability and an increase in complexity.

On Thursday, 20 July 2017 at 14:18:48 UTC, Jack Stouffer wrote:
> On Thursday, 20 July 2017 at 14:05:36 UTC, Iakh wrote:
>> It is not about reduce number of lines. It is about binding
>> related things in one statement.
>
> Even so, it's already been shown in this thread that the same effect can be achieved via a block statement (doing exactly what it was designed for)

This decreases readability by splitting up parts that (the programmer wants to) semantically belong together.

> or with a for loop.

Which is a hack decreasing readability, because it works opposite to what one generally expects when reading a looping control structure.

>
> It's an small increase in terseness for a decrease in readability and an increase in complexity.

W.r.t to the `with` solution only: It's a noticeable increase in readability for a minor increase in complexity.

On 07/19/2017 09:30 AM, sontung wrote:
[snip]

This post: http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw@forum.dlang.org seems to be identical to one on November 3, 2016: http://forum.dlang.org/post/dejodpslmjdovstdiwfz@forum.dlang.org.

Hat tip for persistence!

Regarding the feature itself: it seems to be fancied by the new languages, and C++ added it, too. I must be old school because I don't see much benefit in it, and don't quite find it natural. It's bizarre even lexically: "If the following ... oh wait let me insert some stuff ... as I was saying, if the following condition happens..." Conversely, I find the let/letrec syntax in functional languages a bit more convivial.

The suggested enhancement of "with" seems to sit well on the page:

with (auto x = fun())
if (x > 0)
{
   ...
}

and offers some additional flexibility such as:

if (!r.empty)
with (auto x = r.front)
{
   ...
}

and also "for free" variations such as:

while (!r.empty)
with (auto x = r.front)
{
   ...
}

and

with (auto r = makeMeARange())
if (!r.empty)
{
   ...
}

Of course there's always the opportunity to go bananas :o).

with (auto r = makeMeARange)
if (!r.empty)
with (auto x = r.front)
{
   ...
}


Andrei

On Friday, 21 July 2017 at 21:32:48 UTC, Andrei Alexandrescu wrote:
> 
> It's bizarre even lexically: "If the following ... oh wait let me insert some stuff ... as I was saying, if the following condition happens..."

(excuse me for muddying the waters)
We do have a construct like that already:
```
static if (is(E V == enum)) { // this inserts "V"
   V v;
}
```

-Johan

On Friday, July 21, 2017 17:32:48 Andrei Alexandrescu via Digitalmars-d wrote:
> On 07/19/2017 09:30 AM, sontung wrote:
> [snip]
>
> This post: http://forum.dlang.org/post/vfjlpvpwuyfqoljvpkkw@forum.dlang.org seems to be identical to one on November 3, 2016: http://forum.dlang.org/post/dejodpslmjdovstdiwfz@forum.dlang.org.
>
> Hat tip for persistence!
>
> Regarding the feature itself: it seems to be fancied by the new
> languages, and C++ added it, too. I must be old school because I don't
> see much benefit in it, and don't quite find it natural. It's bizarre
> even lexically: "If the following ... oh wait let me insert some stuff
> ... as I was saying, if the following condition happens..." Conversely,
> I find the let/letrec syntax in functional languages a bit more convivial.

I would have thought that it was a fairly obvious extension given how for loops work (especially since you can already declare variables in if statements; you just can't do it and then use something else for the condition), and it's less verbose than doing something with with, though I suppose that getting with to work like this would be better than nothing. It does seem unnecessarily verbose in comparison though.

- Jonathan M Davis

On Friday, 21 July 2017 at 21:32:48 UTC, Andrei Alexandrescu wrote:
>
> with (auto r = makeMeARange)
> if (!r.empty)
> with (auto x = r.front)
> {
>    ...
> }
>
>
> Andrei

I'm being real nitpicky, but this in particular just seems like a slightly worse way to write

    with (auto r = makeMeARange)
    if (!r.empty)
    {
        auto x = r.front;
        ...
    }

But yeah, it's cool construct that lends itself to pretty neat chaining.

On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
> We do have a construct like that already:
> ```
> static if (is(E V == enum)) { // this inserts "V"
>    V v;
> }
> ```

Yes, but this is a bit different as the goal is to avoid repeating V (as it may be complex). Repeating a local variable name (using e.g. `with...if`) isn't a problem as the variable should have a short identifier. With the above `is` expression it's unavoidable to have a test and a declaration combined. That said, the syntax could be much clearer:

static if (is(E == enum; alias V)) { // this inserts "V"
   V v;
}

This syntax clearly separates the test from the declaration, and makes the declaration obvious due to the alias keyword. The test comes first as it logically should, as the alias is not being used until the following statement. It extends to the other `is` expression forms:

is(T; alias A)
is(T : U; alias A)
is(T : U!V, U, V; alias A)
is(T == U!V, U, V; alias A)

(http://dlang.org/spec/expression.html#IsExpression)

Whenever I want to use the identifier variant I always end up checking the spec. When I see it in code I usually have to stop what I was thinking about to parse the `is` expression.

On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
> On Friday, 21 July 2017 at 21:50:02 UTC, Johan Engelen wrote:
>> static if (is(E V == enum)) { // this inserts "V"
>>    V v;
>> }
>> ```
>
> Yes, but this is a bit different as the goal is to avoid repeating V

Sigh. Repeating E. (unintentional ironic mistake)

On Monday, 24 July 2017 at 13:12:17 UTC, Nick Treleaven wrote:
> static if (is(E == enum; alias V)) { // this inserts "V"
>    V v;
> }
>
> The test comes first as it logically should, as the alias is not being used until the following statement.

Hmm, it can be used in the test:

is(Abc U : U*)
is(AA A : A[B], B : int)
is(AA T : T[U], U : const char[])

So the alias part would come first instead:

is(alias U; Abc : U*)
is(alias A; AA : A[B], B : int)
is(alias T; AA : T[U], U : const char[])

Note: The spec page needs to use CamelCase for types (abc -> Abc, bar -> Bar), especially as the construct is difficult to read anyway. Maybe I'll do this soon. (I think other parts of the spec contravene this too).