From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 89D321FF0AB for ; Wed, 23 Sep 2026 10:02:49 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 55D692132E; Wed, 23 Sep 2026 10:02:47 +0200 (CEST) Message-ID: <27de4f32-7ea2-4b48-952f-041ea957c056@proxmox.com> Date: Wed, 23 Sep 2026 10:02:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH proxmox 01/29] add new proxmox-match-expression crate To: Arthur Bied-Charreton , Lukas Wagner References: <20260709115716.299836-1-l.wagner@proxmox.com> <20260709115716.299836-2-l.wagner@proxmox.com> <8541226a-c1de-49b0-8468-b623167cb5b1@proxmox.com> <5srhv7xnzfrwp6m7tlq7qii663dmjdmdkrp6ut53a6dvzj4mkf@pnw43sbh5unw> Content-Language: en-US, de-AT From: Robert Obkircher In-Reply-To: <5srhv7xnzfrwp6m7tlq7qii663dmjdmdkrp6ut53a6dvzj4mkf@pnw43sbh5unw> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790150563489 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.528 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: MSF3EUTCZVZIV3MQV5URKJ3R4Z4ISB2W X-Message-ID-Hash: MSF3EUTCZVZIV3MQV5URKJ3R4Z4ISB2W X-MailFrom: r.obkircher@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 22.09.26 10:58, Arthur Bied-Charreton wrote: > On Tue, Sep 22, 2026 at 10:56:59AM +0200, Lukas Wagner wrote: >> On Fri Sep 4, 2026 at 2:25 PM CEST, Robert Obkircher wrote: >>> On 04.09.26 11:48, Lukas Wagner wrote: >>>>>> [..] >>>>>> + pub fn evaluate(&self, data: &D) -> Result, E> { >>>>>> + let evaluated_expression = match self { >>>>>> + Expression::AllOf(expressions) => { >>>>>> + if expressions.is_empty() { >>>>>> + // 'all-of' without any sub-expressions is *not* a match >>>>>> + EvaluatedExpressionWithResult { >>>>>> + expression: EvaluatedExpression::AllOf(Vec::new()), >>>>>> + matches: false, >>>>>> + } >>>>> this probaly does not matter too much as long as it's documented, but >>>>> intuitively (and based on implementations for all-expressions in >>>>> other languages like rust and python) i would expect all([]) to evaluate to >>>>> true. >>>> Yeah, I see where you are coming from, but after some consideration I've >>>> decided that I'd like to keep it this way. >>>> >>>> For non-coders, all([]) being true is not very intuitive, and I'd prefer >>>> to just say "hey, all combinators eval to false if they have no >>>> children" in the docs. >>> Even non-coders understand why all of my Ferraris are red :) >>> >>> Would it be possible to forbid the empty lists entirely? e.g. by >>> rewriting all([]) to true when someone saves an empty list. >>> >> I'm not sure if I'm a fan of automatically rewriting rules, I think this >> is counter-intuitive for users. What I had in mind was offering Always/Never as choices alongside AllOf/AnyOf, but I agree that automatically switching between them might be confusing. >> >> But, giving this another thought: >> >> - since proxmox-match-expression is supposed to be generic, keep it 'mathmatically' correct, >> so let all([]) eval to true I was specifically worried that not(all([])) could bite us in the future. >> - disallow creating empty all-of/any-of/one-of rules in the UI and API >> >> What do you think? It would make sense to allow them while editing. Maybe it would be sufficient if we annotate known constant expressions with their value? That wouldn't interfere with editing and it could be extended to cover cases like all([x, false]) or maybe even all([x, not(x)]). > sounds good to me! >> >> >>