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 84ed50e8 for ; Wed, 9 Oct 2019 11:57:25 +0000 (UTC) Received: (qmail 17127 invoked by alias); 9 Oct 2019 11:57:15 -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: 24330 Received: (qmail 23769 invoked by uid 1010); 9 Oct 2019 11:57:15 -0000 X-Qmail-Scanner-Diagnostics: from mail-vs1-f52.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.217.52):SA:0(-2.0/5.0):. Processed in 4.049511 secs); 09 Oct 2019 11:57:15 -0000 X-Envelope-From: sgniazdowski@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.217.52 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=uFKLmNDutzDXb8aUGCN9oddHKoIr/LN9P7JldXLxSeY=; b=OZbUp1eswt1hr65cL62x++WGJbqsVoCfnWzX6UjJZu8Us7BkaE4uTs5EMzgGdD5W4g 1cXuzOvQVnPkEJPRye8tjjKuNyYwUsSCpOxL8tzh7vH9Dbe7p+qIdjscfj3RBumMfAgy lgIMxdqtkSoNsG2WbDZdbZvWKXVMoMwHluwpdyz9tVa/u5ae05w3wW+JMJasrZ5GFRnO 7CxJs1/y5DgKC07eVTV/tlFVOiPwPJhst8o8fM+aXZrwvsnVx676zabFNRX1Hqb6U84R hUHkXfZOa9htr3Rc0Jzc8uR4Q/suH6mu+WDX9wcvMJcllgoxd2k4dFSobo9t/vuguAAN xqHw== 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=uFKLmNDutzDXb8aUGCN9oddHKoIr/LN9P7JldXLxSeY=; b=CFNX0U/IvtUe6iZcUAVg8xY8405FAchuADvlwr9YuoWUXXyp21kwfp/txnB8hPQk+s ND+fZ8GpoJwfemD4/4ghy0zJu3SM42Z0eXo1RpTtLDBET7WpxduaUhk6Q0h3ntXOUh+v 0rbY3IM5Y8MbVWV6I7BLpdIw2p/KIh+LDOiORRcj2idLaHkE3ZiY3/J641l3ZmQxo36q +BGdC1K/NjTBnMLe22OdJiiZgJaeGFphdxOHB2K6kgUiFb1dKCRoePdPALI45Cd0gPKJ 1y4DNlgOJjD0lMf5cHltO2X881k9q0ELRm8mxfYOrtaqvpkuYn14nPonJV0WVj6YY9qn KLTg== X-Gm-Message-State: APjAAAXlJK0z6uEnDpCPhE2VxNbox7VeiA36voOeDcELeguTD3bJY32M FNtGcE3O4aZF1ctPavsQW/WcGgdh2XjVdphLl54= X-Google-Smtp-Source: APXvYqwzN1PmG02H8f4Hs4LVIvx0ZWt42m1pVJasV/cc2j8YTNbXCw3ijsxu1kfF5rZV9fjkl68BPcfah6g7Q5lIPos= X-Received: by 2002:a67:c783:: with SMTP id t3mr1542057vsk.113.1570622197104; Wed, 09 Oct 2019 04:56:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sebastian Gniazdowski Date: Wed, 9 Oct 2019 13:56:28 +0200 Message-ID: Subject: Re: Feature request: a new warning option To: Roman Perepelitsa Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" On Wed, 9 Oct 2019 at 10:45, Roman Perepelitsa wrote: > 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? I like the ternary-use of &&/||. I format the code as follows: (( condition )) && \ code || \ code I even use the ((1)) addition to the code || often. However, I might get onto the alternate syntax-way you've proposed, it looks nice. As for the non-ternary, i.e. symmetric-and-still-correct use of &&/|| I would say: the code that is needy of using &&/|| in such a way can skip this hypothetical new warning option. Covering 8 out of 10 functions with it is still a good result (this reminds me the previous discussion we've had). I in general am a very happy user of warn_create_global and I see how much warning-options can give, hence the feature request. I however don't use warn_nested_var, I'm now starting to wonder why, as even that I've sometimes write code using variables from upper scope, the "covering 8 out ouf 10 functions..." point would apply here too. It's however a recent option, not forever-present like the warn_create_global. I wonder if a very much compressed way of enabling warn_nested_var only on shells that have it exists. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org