Hi Yuao,
Yuao Ma wrote:
The first cond-expr patch has been committed as r16-3848-gaf53cfeb8352b1.
This patch inspired me to work on an even clearer feature: allowing
cond-expr to use characters. The change is small; we just need to
conditionally fill the string_length.
...
Maybe OK for trunk?
LGTM. Thanks!
* * *
Just some mumbling when reading the patch:
In terms of accepting types, I bet that BT_VOID (i.e. type(c_ptr) and
type(c_funptr)) are fine as well as is BT_UNSIGNED (-funsigned; GCC
extension based on a Fortran 2026 proposal). – I think Hollerith should
be fine as well, but I don't know whether it is possible to enter it;
likewise for BOZ as extension (standard Fortran requires it to be
wrapped in intrinsics like INT). BT_ASSUMED ("type(*)") should also be
fine, I think.
The list could be trivially be extended or we do it later …
For actual arguments to procedures, I wonder whether a procedure name or
procedure pointer (BT_PROCEDURE) could appear or not; for a normal
expression, I think it cannot. (And I'd expect already now an error).
For actual arguments, it requires carefully reading the wording whether
it is permitted or not.
For BT_DERIVED:
(i) The type needs to be the same – or compatible ('SEQUENCE' attribute)
(ii) If there are kind arguments, it needs to be the same. →
Parameterized derived types (PDT); there are kind and len arguments, but
only "kind" matters (and is a always compile-time constant – similar to
'integer(kind=4)').
BT_CLASS: Similar, except some more potential gotchas.
Probably makes sense to defer.
Tobias
PS: Already with the current code, we may run into the issue of passing
an actual argument like '(cond ? "abc" : "cdfg")' to 'class(*)' – and I
am not sure whether we handle this correctly or not.
