From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1328 invoked by alias); 15 Nov 2016 21:18:54 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39951 Received: (qmail 7023 invoked from network); 15 Nov 2016 21:18:54 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f53.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.53):SA:0(-0.0/5.0):. Processed in 1.222921 secs); 15 Nov 2016 21:18:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.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.213.53 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=nhr/LhQUluKhrgTnvgy63YPD8AN+d1kGzss60+7gXWs=; b=epaGlu6O+cJOmN8eM71cpwv4lT5IbV8zhPmoxMvxZIe64ZzFgJ3pgICV1XaHj+6kc9 5H7vD1UdN3dWabnAPpgeEUnhpgKfHYMUShjm/FGu2knYLpEXorymI7WA2chg2sObs2E3 aUuems39SDLxH2K8bdF9kaJ8qNlVKLVZhqIUMyWk5B4qbcC+HMu6HyF0eTqCldfUvv6T BXSYxN3RDhVdCO68Pj+XASwc/747yyi41X6u991TsgtyckVOLsdH2+xwsjXeq77eqS9H Yee02VAJz675xPmsFctIbTgZRD5FI5SHtWiRIot3OEd3c0niQpUJX+qffvjFtXeZ57QW twug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=nhr/LhQUluKhrgTnvgy63YPD8AN+d1kGzss60+7gXWs=; b=O+VrN+vfTtrfF4yBLqUdtZNkoBY7GhuhJPDN+bTOFNXBo+Es/L+IzyfzGriadPytp7 D3SXx6vg5KCrzdS8OmUM2Mvn5NPYY9vdT3LoqrJHDPfkHLXZIrPjBkFDFd0F5vMCy7jz hwta7l0X9UptNyYUx1QjAEfJH93pKFPYZPcyZPnf7d/25Iahckgdy9UCI3e6itgsyU3Y gJLVNrXiDA/pEN0cnZiOxlzH8wr9D0074Se9eoC4KrPCg+puU+VReqlyiF+Zuqc4FFeh JwKBxIfdd74YqkcX1ELu5FZGdseOPTT2zmGy+6uf4/Or1k/81EaA2jFZBTE8Q9mj2rin GpYQ== X-Gm-Message-State: ABUngveFjHZHxHTxMd4ABMLuzfp1zt88FvCoCJURDkT5PoDMVNwloD2H48UP4ZzCquWJQA== X-Received: by 10.31.173.144 with SMTP id w138mr8338351vke.153.1479244306421; Tue, 15 Nov 2016 13:11:46 -0800 (PST) From: Bart Schaefer Message-Id: <161115131156.ZM11136@torch.brasslantern.com> Date: Tue, 15 Nov 2016 13:11:56 -0800 In-Reply-To: <20161115195721.43648236@ntlworld.com> Comments: In reply to Peter Stephenson "Re: [PATCH] Optimization of getarrvalue()" (Nov 15, 7:57pm) References: <1478635899.1897979.781551353.05792438@webmail.messagingengine.com> <20161109114207.6b929440@pwslap01u.europe.root.pri> <161109080328.ZM6075@torch.brasslantern.com> <20161115195721.43648236@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "zsh-workers@zsh.org" Subject: Re: [PATCH] Optimization of getarrvalue() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 15, 7:57pm, Peter Stephenson wrote: } } > But then "make check" fails in two tests (D04parameter and } > Y01completion). } } The parameter test is testing } } setopt rcexpandparam } local -A hash=(X x) } print LOST key=$hash[(I)y] val=$hash[(R)Y] } } outputs LOST with the arguments removed. With your change you get an } array wth an empty element and that doesn't happen. An array with an empty element would be wrong in either of those caes. (Sebastian reported the same thing when he tried removing s[0]=NULL from one branch in his original patch.) } I guess the differences are to do with the way the value of the end } index is used, with the hash case apparently behaving more like an } array slice than an invidivudal index Yes, intentionally so -- (I) and (R) are defined on hashes to return *all* the possible matches for the pattern, so the result is an array even if there is only one matching element. If you want a single element, use (i) or (r). Hashes don't have an ordering, so it's meaningless to distinguish between the "first" and "last" elements. ("First" just means "most easily identified".) } and the latter being the odd one out } (but also the most commonly used case). It may be too late to } disentangle this. Semantically, I don't think there's anything to disentangle? As for the implementation it might be nice not to have to reduce a hash to an array of either keys or values quite so frequently, as that might have avoided this confusion by never treating a hash as though it has any numeric indices.