Actually, Fortran defines "storage association" rules, so code that doesn't obey them isn't conforming Fortran. I'm not sure about the error-prone, though, from long experience and users arguing with a compiler maintainer. One problem is lack of static checking.
Numeric code rarely (almost never, actually) requires aliasing, so defaulting to no-alias is less error prone for those users. If you’re writing an OS or runtime library, you want aliasing support and static checking, but that’s mostly out-of-scope for Fortran today.
The Fortran standard just doesn't talk about "aliasing" (in that context), and "defaulting" suggests you can turn off the storage association rules somehow.
I maintain from long research computing experience (at least back to the days of Alliant) that the rules are highly error prone in practice for users, who frequently deny they even exist, and blame the compiler bugs. (I'm surprised if that's not the case more generally.) I'm not saying they shouldn't exist, or that code needs to contravene them.
Yeah, I'm using the C nomenclature ("aliasing" vs "association") because HN commenters are broadly unfamiliar with Fortran.
What I mean by "default" is that if I declare a function with two array arguments in Fortran, with the simplest possible syntax, the compiler assumes that they do not alias (are not associated). By contrast, if I declare a function with two pointer arguments in C, with the simplest possible syntax, the compiler assumes that they may alias (are associated in some unspecified manner).
The C semantics are certainly safer, but they lead to lots of "Fortran is faster than C" blog posts by people who either don't know about or simply don't want to use the annotations.
