From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 21ca4950 for ; Wed, 9 Oct 2019 08:46:12 +0000 (UTC) Received: (qmail 27973 invoked by alias); 9 Oct 2019 08:46:03 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24328 Received: (qmail 4432 invoked by uid 1010); 9 Oct 2019 08:46:03 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f53.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25594. spamassassin: 3.4.2. Clear:RC:0(209.85.166.53):SA:0(-2.0/5.0):. Processed in 3.68392 secs); 09 Oct 2019 08:46:03 -0000 X-Envelope-From: roman.perepelitsa@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.53 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xekR42brWZqThBGe3rMuytBjHFxWJTXwS826rkBncq4=; b=UbQynZLpGNZYApu+DWv/sNHTb8KIElA+VvHi27e3ssCzfO8CmLPNRVnb2VLffUGB2s GNB3+BhIGIzkY+Lgxqww7n2o91f2WWFtdQo4ydGLnAO9Amvb9xZOt5K7piDbudP03Ymv X1Rg4ZQkx7riJqs5NAwaWIIAW9mzK8at2g3tOpSh9TBmTPo33Gb+IfCe63oT/t0140SD pqfKVz8Jxih1J3rrIFpDEdCUwJrhlqdPrSGmz99zHsfTBPSzJQBy1qPMTcLGWESttHOG M3uCkK0rv5fmIjJuGm7s6Boi8sBulhUHUmt2mpRzLaq584iZ68w+by06/6Bi1KrAjGLE SQyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xekR42brWZqThBGe3rMuytBjHFxWJTXwS826rkBncq4=; b=iKINDPLay6+YBCbdQGjr3fkg6ue1yAlXVEA348NmXCd7PVb0TRqheb8TxNJ4d79Od6 Klr4H5oqLKNA6gkaShcwp7slwBVRfBtbKL8Vh+ndmR1sOwURL1kpLANwjj0DfAr5GVsr PuZbJyT+R1RT7rfBbsg32fE2GCIIiXrwF5agoR6FU4japYtBlC874z7QG2Rp5NmUynzk abM82Ti8Yv9VOJ9bCP78Ek7n09NvM5ZuF/wzA+W3f5Cql0d87h+0RAtmBSTHF7t15QQ1 z0s5xmNM+j936driffLMb9UgcQRz81HIlqCnVRYhzp61+xfHbUyGTkvceE8UXEGS4bZ4 0zbQ== X-Gm-Message-State: APjAAAUYQz3B0Vvmi/aJYXcF7FKgzsOCg/6/UWK14NQRrK/iARGg84Nc YrK7g/XjtjKvwkYsUIv4kAeLR7YSZFAIc5gnLG0= X-Google-Smtp-Source: APXvYqwdhAz8yEkBFdXgJdSlS8LQ+w1rkTmkU4l24qKoq88O85xexpPFs8kGYT3k/jBlq8QtQDmXmz12lCvXQvTsUz8= X-Received: by 2002:a92:5fd7:: with SMTP id i84mr2089847ill.151.1570610726349; Wed, 09 Oct 2019 01:45:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Perepelitsa Date: Wed, 9 Oct 2019 10:45:15 +0200 Message-ID: Subject: Re: Feature request: a new warning option To: Sebastian Gniazdowski Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 6:03 AM Sebastian Gniazdowski wrote: > > Hello, > how about detecting situations in the code like the following: > > fun() { some code possibly returning false } > (( condition )) && fun || print "Some 'else'-instruction" I've made a quick-and-dirty search over powerlevel10k source code to see how often this warning would have false positives. Here are a few examples of `x && y || z` constructs where `y` can fail and yet the code is correct. (( $+GITSTATUS_DAEMON_PID_POWERLEVEL9K )) && gitstatus_start POWERLEVEL9K || _p9k_gitstatus_disabled=1 mkdir -p ${dst:h} && cp -f $src $dst || return _p9k_cached_cmd_stdout node -v && [[ $_p9k_ret == v?* ]] || return `x && y || z` is not `x ? y : z` even though it's often abused as such. I think the solution is to use `x && y || z` when you mean it, which is to say *only* when both `x` and `y` may be falsy. The ternary can be expressed with an `if`. Compare: (( condition )) && fun || print "Some 'else'-instruction" vs if (( condition )) { fun } else { print "Some 'else'-instruction" } The latter is longer but is at least as clear. It also comes with curlies that make it easy to split the statement into multiple lines if necessary, or to add extra statements inside the branches. I myself am guilty of using `x && y || z` in place of a ternary and this leads to bugs that your proposed warning is meant to flag. However, if I were to enable this warning, I wouldn't be able to use `x && y || z` when it is the best tool for the job. Hence I'm leaning towards unlearning my current habbit and starting to use `if-else` more. What do you think? Roman.