If Statement with Declaration

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Fri Nov 4 12:26:23 PDT 2016


On 11/4/16 1:46 PM, Jerry wrote:
> On Friday, 4 November 2016 at 16:15:21 UTC, Steven Schveighoffer wrote:
>> It's just a strawman type, I'm sure there's ways to handle these
>> things, I just didn't put a lot of effort into all the cases.
>>
>> But really it's just syntax to separate the bool check from the value
>> itself. You can get more elaborate if you want with the comparison.
>> The difficult thing is having a type that you use normally, but that
>> when you use in an if statement, it gives what you want. And declaring
>> that type in the if clause itself (which is allowed in restricted
>> circumstances).
>>
>> This also isn't exactly ideal for things like int, as if(i) would now
>> be unexpected.
>
> It is just a basic type but ultimately you will probably need more than
> one type with a different way of operating to get the same behavior.
> That and having part of the code as a string which makes it harder to
> read and no syntax highlighting for the code in text editors/ides.
>
> What do you mean if(i) would be unexpected?

I mean something like:

if(auto i = func.cond("==0"))
{
    assert(i == 0);
    if(i)
    {
       writeln("oops!");
    }
}

>> Sure, it doesn't look great. But my expectation is that your proposal
>> doesn't pull enough weight to be integrated into the language. There
>> are enough ways to solve this problem that don't involve language
>> changes.
>>
>
> It follows the same rules for an if statement condition which an if
> statement allows "if(auto i = foo())".

Right, I'm just saying syntax changes like this generally need a high 
motivation and perceived improvement to justify the undertaking.

For instance, we have trusted escapes via this construct:

auto foo = (() @trusted => systemFunc(x))();

It's ugly, verbose, confusing. But it works, and it works today. I'd 
much rather have this look like:

auto foo = @trusted(systemFunc(x));

or something similar, but how much benefit are we going to get from 
this? Is it going to change productivity? Is it going to make code so 
much easier to write that the time taken to implement was worth it? I 
don't know the answer to that. Often the answer to requests for such 
improvements is "yeah, but you can just do it this way, and that's good 
enough". That's all I'm trying to say.

> It's syntactic sugar, most of the existing language features don't serve
> a functional purpose. They simply serve to simplify another syntax.
> Every "foreach" statement could be written as a for-statement. Every
> for-statement could be written as a while-statement. And so on so forth.
> It doesn't add anything that new either. It follows the same syntax as a
> for-statement.

Existence of current sugar is not justification of adding more. Those 
already exist (and BTW have existed for a long long time), there is no 
cost to continuing to have them. There is a cost to adding new features, 
that we must weigh against the benefits.

One thing that could work in your favor is if the change is easy to 
implement in the compiler. That I definitely don't know the answer to.

> I think it makes it easier to read and it fits with how the
> for-statement operates. I write code everyday that could utilize this
> if-statement syntax, so I thought I might as well bring it up. But if
> there isn't that much interest in it then I won't bother with a DIP.

Please bear in mind that I'm not the gatekeeper, so what I say may not 
be what the actual ones in control think. It's possible that Walter and 
Andrei like the idea and would implement if someone fleshed out the 
proposal. In my experience, I have not encountered too many cases 
(definitely not zero though) where I needed such a feature. I can see 
the utility, and I wouldn't be opposed to it.

-Steve


More information about the Digitalmars-d mailing list