C# Pure Function Keyword to Mark No Side Effects Or External Dependencies

[wcrowther]

Be able to mark a method as having no side effects or external dependencies, ie: it does not change any state outside the inputs or outputs. Any code that attempts to do this would throw an exception. My thought was that the keyword could be "functional", "pure" (as in a "pure functions" mentioned in some Msdn documentation ), "purefunction", or even "nosideffects".

See https://msdn.microsoft.com/en-us/library/bb669139.aspx for some current naming conventions and reasons for this feature.

[sharwell]

❓ Considering we already have [Pure], which is very short and doesn't require new keywords be added, what additional benefit(s) would this proposal bring?

📝 Note that I'm not necessarily against this proposal. I'm just trying to get some more context. 😄

[HaloFour]

If the compiler were to start enforcing method purity through the addition of new warnings or errors than a new keyword might be necessary in order to avoid breaking changes.

private int x;

public void Unpure() {
    x++;
}

[Pure]
public void Pure1() {
    Unpure(); // legal, no change to existing code
}

public pure void Pure2() {
    x++; // compiler error, side effects
    Unpure(); // compiler error, method not marked as pure
    Pure1(); // legal, method marked as pure (even if it might not be)
}

An analyzer that could issue warnings based on PureAttribute would probably be a good start, though.

[alrz]

Doesn't pure imply "always evaluating the same result value given the same argument value"? I think C++ const would be more familiar; e.g. void M() const { }. or whatever dotnet/csharplang#2543 would use.

[orthoxerox]

I like this idea, but how do we verify that a function has no side-effects, recursively? Does memoizing count as a side-effect? If not, how can that be verified? Even if #49 is implemented so we can encapsulate that ConcurrentDictionary instance inside the function, we cannot mark GetOrAdd() as [Pure], because it isn't.

[alrz]

@orthoxerox I think it needs an immutable map, and yet map itself is a mutating state, probably needs a state monad or something? Then recursion is off the table, I guess.

[orthoxerox]

@alrz One option would be to add Memoized as a new parameter to [Pure]. This new parameter would force the compiler to rewrite the function into something like this if the original function was verifiably pure.

[Pure(Memoize=true)]
modifiers return_type name(args)
{
    body;
}

[Pure(SkipVerification=true)]
modifiers return_type name(args)
{
    return_type mangled_name(args) {
        body;
    }
    static let memos = new ConcurrentDictionary<ValueTuple<args_types>, return_type>();
    static let locks = new ConcurrentDictionary<ValueTuple<args_types>, object>();

    return_type result;
    let a = ValueTuple.Create(args);

    if (!memos.TryGetValue(a, out result)) {
        var l = locks.GetOrAdd(a, new object());
        lock (l) {
            result = memos.GetOrAdd(a, mangled_name);
        }
        locks.TryRemove(a, out l);
    }
    return result;
}

[leppie]

Just comment.

If a method returning void is marked as pure, the compiler should be able to remove it as it has no side-effects.

[sharwell]

@leppie Common cases where you may want code that doesn't affect program state but don't need to return a value:

• Benchmarking
• Unit tests - here exceptions could be considered a meaningful return value, which means even pure methods marked as void can have a return value of sorts

Removing the following would probably not be desirable, yet it's arguably a pure method:

public class Requires
{
  [Pure]
  public static void NotNull<T>(T value, string paramName)
    where T : class
  {
    if (value == null)
      throw new ArgumentNullException(paramName);
  }
}

[leppie]

@sharwell The presence of a possible throw, hardly makes it 'pure' :) But I get what you saying. Perhaps pure is not the best word here.

[alrz]

@orthoxerox Memoization wouldn't make it to the language. (already proposed in #5205).

[MgSam]

The existing [Pure] attribute is not particularly helpful, as it doesn't even produce a squiggle if you write to fields. I'm all in favor of a better way to mark methods that shouldn't have side effects. Right now I am often forced to try to use static methods for this purpose, but that only goes so far because sometimes you need static fields and there's nothing to stop you from writing to them.

[sharwell]

The existing [Pure] attribute is not particularly helpful, as it doesn't even produce a squiggle if you write to fields.

This could be implemented as an analyzer. However, it's a bit complicated.

• Writing to non-static fields of instances directly or indirectly created by the pure method would probably be allowed. This means a pure method can in some cases call a non-pure method, without removing its effective purity.
• Writing to instance fields of a struct which is passed as a parameter would probably be allowed, unless the parameter uses ref. Writing to a struct parameter with ref can be fine as long as the reference points to a stack-allocated struct in a caller
• Creating instances is generally OK, as long as the constructor is also pure. Unlike other methods, pure constructors can write to their own instance fields.
  • Constructors of types which have user-defined finalizers (including in a base type) cannot be pure unless the finalizer is also pure.