From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Redefining "in" "operator"
Date: Mon, 5 Feb 2018 18:48:24 -0600
Date: 2018-02-05T18:48:24-06:00 [thread overview]
Message-ID: <p5au0o$e0i$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: p5a1bq$f3v$1@dont-email.me
"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
news:p5a1bq$f3v$1@dont-email.me...
> On 02/05/2018 05:26 PM, Alejandro R. Mosteo wrote:
>>
>> Are there special reasons not to allow something like that? I think "in"
>> is not an operator in the Ada RM sense but now I'm curious why the
>> special treatment.
>
> The right side of "[not] in" is a subtype. Ada does not allow operators to
> have operands that are subtypes.
Well, Ada 2012 also allows it to be a (set) of expressions as well. But your
basic point applies: there aren't any function parameters that are subtypes
or that are sets of expressions. One could imagine allowing a pair of
expressions, but that's just "=" (and "in" in fact uses user-defined "="
when necessary).
Randy.
next prev parent reply other threads:[~2018-02-06 0:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 16:26 Redefining "in" "operator" Alejandro R. Mosteo
2018-02-05 16:39 ` Jeffrey R. Carter
2018-02-06 0:48 ` Randy Brukardt [this message]
2018-02-06 18:07 ` Jeffrey R. Carter
2018-02-05 16:43 ` J-P. Rosen
2018-02-05 17:23 ` Dmitry A. Kazakov
2018-02-05 17:41 ` Alejandro R. Mosteo
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox