@Jens recently opened a pretty interesting thread about his attempt at using the @effects attribute to help with performance sensitive code. However, @effects is a very low level attribute that applies LLVM level annotations to code. These attributes require the user to know very specific implementation details of how the Swift compiler/runtime treats memory, something the general Swift programmer is unlikely to know.
You can read about the attribute here
To borrow the example from Jens' thread:
@effects(readnone)
func f<T>(_ a: T) -> T { return a }
let x = f(123)
print(x) // Prints 0, not 123
This seemingly mundane example demonstrates unintuitive results. This example does not work because unconstrained generic functions pass their arguments through memory, and so can never be @effects(readnone).
As @Joe_Groff points out, this attribute should probably always have been @_effects, but was missed.
I'm currently in the process of writing up a SE proposal as well as working on the implementation.
Some alternatives I've thought of is that in addition to renaming, we restrict the use of this attribute to the standard library, as it's not really meant for use outside of it, much like Builtin provides access to LLVM primitives but is restricted to the standard lib. I'm going to leave that in the alternatives considered unless there's a strong consensus here that is what we should do.
Thanks Ted. The PR should be landing later today.