[J3] Consistency in conversion functions

[Steven G. Kargl]

On Tue, Apr 04, 2023 at 11:02:40PM -0600, Ondřej Čertík via J3 wrote:
> Hi Jeff,
> 
> On Tue, Apr 4, 2023, at 1:52 AM, Jeff Hammond via J3 wrote:
> > To convert INTEGER kinds, we use INT().
> > To convert COMPLEX kinds, we use CMPLX().
> > To convert REAL kinds, we use REAL().
> > To convert LOGICAL kinds, we use LOGICAL().
> > 
> > Does this bother anyone else?
> 
> It bothers me too, and I think this is a good proposal, so I created an issue for it: https://github.com/j3-fortran/fortran_proposals/issues/295, go ahead and give it +1 if you like it.

Please add CHARACTER() to the list as a redundancy for CHAR() 
(or should that be for ACHAR()?).

> 
> In fact to this day I don't remember the difference between cmplx and complex and the `(x,y)` syntax, and another inconsistency (for me) is that real(z) will cast to a single precision if "z" is double precision real, but it will keep double precision if "z" is double precision complex. So in my code, if I write real(z), and then change "z" from complex to real, because "z" happens to be real in some case, I get single precision, which is not what I want.
> 

The standard defines CMPLX as an intrinsic subprogram and COMPLEX
as a type declaration.  These are quite different things.  As to
(x,y), that's a complex literal constant.  Again, something completely
different than a subprogram or type declaration.  If you have 
doubts about how these are specified in the Fortran standard,
then refer the standard to refresh your mind.

Why are you writing real(z) in lieu of real(z,kind(z)) or
real(z,knd) where knd=kind(z)?

> Unfortunately Fortran has many such warts, that every single newcomer hits (such as implicit typing, implied save, single/double precision mistakes, etc.). I personally think they should all be fixed (while keeping backwards compatibility). The committee and community is split on this, I personally know many both at the committee and outside of it who agree with me and many who do not agree. There are good arguments on both sides, and I tried to summarize both sides in the issue above.
> 

You cannot fix some warts and maintain backwards compatibility.
You should know this from the bi-monthly implicit none and
implicit typing posts on Fortran Discourse.

> Fortunately almost all of these can be fixed in a compiler. So it's good to have more compilers with different defaults and users can choose. I encourage you to get support for your proposal at the vendor you work for. I still think most (if not all) changes should be lead by compilers and users, and the committee should only standardize already "common practice".
> 

Well, I already stated that gfortran supports a complex() intrinsic
subprogram, which differs from the suggested behabvior.  It has
for 20 to 25 years.  It has been stated by an individual, associated
with another vendor, that he does not care about what gfortran does
because it does not match his vision.

Why bloat the language with redundancy?  Is it that hard to pick up
a standard reference about Fortran or the Fortran standard to 
refresh one's memory about INT() or CMPLX()?

-- 
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3950 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230404/32329e43/attachment.bin>