Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Eduardo Bustamante <dualbus@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Should [[ -v 1 ]] be supported?
Date: Thu, 27 Dec 2018 17:09:48 -0800
Lines: 38
Approved: bug-bash@gnu.org
Message-ID: <mailman.6425.1545959657.1284.bug-bash@gnu.org>
References: <CABrM6wmrn2gi8_HgmRg67B5nsgGNFRn8Bn-r20MvC-_2LJHZ0g@mail.gmail.com> <5dac2cf2-2fac-0fd1-058f-6a84a3271738@case.edu> <abd86dbc-f6e2-62bd-e9dc-f959e2dbff9f@inlv.org> <CABrM6wkGwVbPdrXTetVsFCiwDPg5JnK4KRh49WqACsKhrrMMdA@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Martijn Dekker <martijn@inlv.org>, bug-bash <bug-bash@gnu.org>
To: Peng Yu <pengyu.ut@gmail.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CABrM6wkGwVbPdrXTetVsFCiwDPg5JnK4KRh49WqACsKhrrMMdA@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:14974

On Thu, Dec 27, 2018 at 4:50 PM Peng Yu <pengyu.ut@gmail.com> wrote:
(...)
> What I meant in my original email is that I want something for testing
> if there is a command line argument (one or more, the exact number
> does not matter). $# gives more than that info, because it tells not
> only whether is any command line argument, but also how many. This
> could lead to slower performance if the goal is to just test if there
> is an argument.
>
> [[ -z ${1+s} ]] does something also more than necessary too, because
> it not only tests for whether $1 is set, it also replaced with a
> string "s". This also does more than just testing whether $1 is set.
>
> So both cases would be slower than [[ -v 1 ]] if it were supported.
>
> As of now, because (($#)) or [[ -z ${1+s} ]] are not consistently
> faster than the other, there is no way to write a program that is
> consistently fastest. To achieve this goal, one has to implement [[ -v
> 1 ]] or something similar that just test whether $1 but no more.

Out of curiosity: What kind of software are you writing in bash that
you invest so much time in shaving those extra micro-seconds?

a) If you're doing this for fun, then I think you might understand why
it might be counter-productive to bloat Bash for a use case that is
uncommon?
b) If you're building real-world applications in bash that require
that level of performance, can you share what these applications do on
a general level and why you chose bash as the run-time? When arguing
for a feature, I think that explaining the expected use cases make a
much better argument.



Also, why do you expect an unimplemented feature to be a better option
to achieve more performance than two implementations that are already
available and can benefit from some optimizations?