[J3] Consistency in conversion functions

[Dan Nagle]

Hi,

My $0.02

The proposed COMPLEX was to eliminate the appearance
of an uglifying kind type parameter.  While small, this is good.

This appears to have been overtaken by having a programmer-settable
default kind per intrinsic type per scope.



> On Apr 6, 2023, at 21:41, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> I recall that one objection to the previous proposal for a COMPLEX intrinsic was that the previous proposal was complicated for the functionality it provided.  I would be surprised if gfortran implemented that proposal.  If the committee chooses to add a COMPLEX intrinsic, someone should determine what gfortran does.
> 
> Bob Corbett
> 
>> On Apr 6, 2023, at 6:07 AM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> On 4/6/2023 4:09 AM, Jeff Hammond via J3 wrote:
>>> I appreciate Kurt’s suggestion and I’ll just do that in the future, since I would like the conversion intrinsic name to match the type, consistent with REAL(), LOGICAL() and C.
>>> 
>>> I would support Malcolm’s #3 if someone proposes it.  Perhaps Steve will be happy with this one too.
>> 
>> I'm just one vote here, nothing more. The 2008 Tokyo meeting (J3/WG5), where a COMPLEX intrinsic was discussed, was only my second standards meeting. I don't recall that I had any issues with the proposal, but I was still learning standards issues. I don't recall what the objections to it were then, but I would be inclined to support it for 202Y.
>> 
>> Checking my notes, I see that in 2014 Bob Corbett proposed (https://j3-fortran.org/doc/year/14/14-204.txt) that CMPLX be enhanced to allow CMPLX(X,KIND=) where X is complex; that made it into F2018.
>> 
>> Steve
>> 
>> 
> 


--

Cheers!
Dan Nagle