ValueSemantic protocol

[anandabits (Matthew Johnson)]

@dabrahams

But then that would be a different type from an ordinary function type that we have today.

Chris was already talking about introducing something different than ordinary function types with @actorSendable.

@dabrahams

But a first-class language feature that makes a category of pure function types would be lots cleaner to use, would allow us to type check the composition of pure functions, and could handle inout .

I agree this would be great. Do you imagine that these functions would conform to ValueSemantic? Fwiw, I inout would work fine with my suggestion. Only mutable captures would need to be banned.

@dabrahams

You can do that without any language features

Sure, but then you lose all of the language support for function types.

@dabrahams

Oh, I think not, unless you want to say the behavior of the function is independent of its value! There's no way to compare the behaviors of two functions for equality.

I don't see why it is a problem to say the value of the function is related to source identity. If we take the C++ approach and view closures as syntactic sugar for anonymous structs then equality becomes clear. It looks like @Joe_Groff thinks this is a reasonable idea.

@dabrahams

once you get to built-in function types in Swift there's no way to control the semantics that they expose, and I don't think we'll ever be able to compare them reliably.

What specific problems do you see with the above approach?

@dabrahams

Yeah, sure, design away! That sounds great. Could get messy though; you might need to represent safe in the type system too.

Unfortunately I don't have time for this exercise right now. I hope we can have ValueSemantic function values someday though.

@Chris_Lattner3

It is more precise to say that Never should conform to protocols without init and static requirements. I think that ValueSemantics is an example of this.

Agree.

@dabrahams

Stage 2: Allow ValueSemantic conformance to be inferred for tuples, structs, and enums of ValueSemantic -conforming types.

If that's what you mean, sure. I'm all for staging, although I don't see a huge advantage in this case because stage 2 is pretty trivial.

I also think this inference should be supported from the start. I'm hoping Chris has something more in mind related to enforcing safety.