[Pitch] Rename @effects to @_effects

@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:

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.


Underscore, sure.

But I think the following would be going to far for no real reason:

It would take away an opportunity to learn, and perhaps get involved in the work on the standard library etc.
An underscore is clear enough.

Currently, I have to use @_transparent at some places in my code, or I'll have to either sacrifice performance or writing (a lot) of boilerplate / unnecessarily horrible code.

These kinds of attributes can (once you learn how to use them properly) be handy while hunting down shortcoming in Swift's optimizer etc.

Yeah, that's why I put it in the alternatives considered. I'm not really a fan of privileged language features, but there is precedent for that (Builtin), so I put it out there.

1 Like

@Joe_Groff @jrose Does this actually need to go through SE? Or should I just open a PR and we can run the source capability suite and see if there's any fallout?

I'm sitting on a proposal in either case.

The Core Team discussed and we support just renaming the attribute. Please go ahead and create a pull request.


:+1: Thanks Ted. The PR should be landing later today.

1 Like

PR is up: Rename @effects to @_effects by nuclearace · Pull Request #17023 · apple/swift · GitHub


Indeed. This has settled, but I just wanna point out another reason to not limit it to the StdLib: coupling. I'd say that the more the compiler and the Standard Library are decoupled, the better -- if that doesn't restrict functionality too much :slight_smile: