Paul A Jungwirth <p...@illuminatedcomputing.com> writes:
> On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
>> Now, I think so name "anymultirange" is not good. Maybe better name is just
>> "multirange"
> Are you sure? This function exists to be a cast to an anymultirange,
> and I thought the convention was to name cast functions after their
> destination type.
True for casts involving concrete types, mainly because we'd like
the identity "value::typename == typename(value)" to hold without
too much worry about whether the latter is a plain function call
or a special case. Not sure whether it makes as much sense for
polymorphics, since casting to a polymorphic type is pretty silly:
we do seem to allow you to do that, but it's a no-op.
I'm a little troubled by the notion that what you're talking about
here is not a no-op (if it were, you wouldn't need a function).
That seems like there's something fundamentally not quite right
either with the design or with how you're thinking about it.
As a comparison point, we sometimes describe subscripting as
being a polymorphic operation like
subscript(anyarray, integer) returns anyelement
It would be completely unhelpful to call that anyelement().
I feel like you might be making a similar mistake here.
Alternatively, consider this: a cast from some concrete multirange type
to anymultirange is a no-op, while any other sort of cast probably ought
to be casting to some particular concrete multirange type. That would
line up with the existing operations for plain ranges.
regards, tom lane
