Even when asking for standard conformance, an invalid use of a unary + or - in front of a logical is not always diagnosed:
program p print *, (+(.true.)) ! Warning (OK) print *, [ integer :: +(.true.)] ! No warning (not OK) end program p
With ifort 2021.7.0 I get:
% ifort ifort-type-mismatch.f90 -stand f18 ifort-type-mismatch.f90(2): warning #6139: Fortran 2018 does not allow arithmetic operations in an expression involving LOGICAL(s). print *, (+(.true.)) ! Warning (OK) --------------------------^
So one case is detected, but not the other. Same with replacing 'integer' by 'real' or 'complex'.
Using Visual Studio 2022 if I turn on standard sematics with IFX I get second picture and if I turn it off I get third picture. I tried /stand f18 and got the same as third picture. Could not generate a warning?
So you lost me a bit. I had ten minutes to spare whilst downloading file. Sorry I only use Visual Studio - long habit.
My interest is why the difference in answers, the -1 does not make semantic sense, the others do in a weird ok strange mathematics way.
Conversion between logical and numeric types is an artifact of an old DEC extension from the VAX/VMS days. On VMS, condition codes (status values) use the low two bits to indicate severity. 0=warning, 1=success, 2=error, 3=informational, 4=severe. Note that the low bit is 0 if something went wrong, 1 if not. It was typical in VAX FORTRAN (uppercase) to do logical tests on statuses, such as:
integer ret ret = SYS$somesystemcall() ! returns integer if (.not. ret) then ! report error
So, then you need a value for .TRUE. and .FALSE. that match this convention, hence -1 for .TRUE. and 0 for .FALSE. This was well before C existed, which would have 0 and non-zero as true and false. Intel Fortran does support the C convention if you use the /fpscomp:logicals option (because Microsoft Fortran PowerStation used it), and this is now implied by /standard-semantics because the Fortran standard now implies a potential correspondence between logical types and C's bool.
The situation was worse in the past, in that there was free conversion between logical and numeric in list-directed and namelist I/O. I successfully lobbied for that to change, though there is a compile option to still allow it.
For a bit more on this topic, see Doctor Fortran in "To .EQV. or to .NEQV., that is the question", or "It's only LOGICAL" - Doctor Fortran (stevelionel.com)
The compiler should have offered a standards warning for both of the uses in the original post. I was providing some background as to why ifort allows you to use an arithmetic operator on a logical value. I'd be quite happy if this extension was turned off by default, as it is a continued source of confusion and errors.
> I'd be quite happy if this extension was turned off by default, as it is a continued source of confusion and errors.
I would support that, as well as more consistent behavior. Why should the array constructor make a difference in the first place...?