Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 2. The notation t(x) will be taken to mean x::t if there's no
>> function t() taking x's type, but there is a cast from x's type
>> to t.
>> I think if I had to pick a proposal, I'd say we should disable #2
>> for the specific case of casting a composite type to something
>> else.
> Well, then let's do that. It's not the exact fix I'd pick, but
> it's clearly better than nothing, so I'm willing to sign on to it
> as a compromise position.
It seems a bad idea to have so many different syntaxes for identical
CAST semantics, but there they are, and it's bad to break things.
One of the reasons #2 seems like the place to fix it is that it's
pretty flaky anyway -- "it will be taken to mean x unless there no y
but there is a z" is pretty fragile to start with. Adding one more
condition to the places it kicks in doesn't seem as good to me as
dropping it entirely, but then I don't have any code which depends
on type(value) as a cast syntax -- those who do will likely feel
differently.
So, I'd rather scrap #2 entirely; but if that really would break
much working code, +1 for ignoring it when it would cast a composite
to something else.
-Kevin