September 6th, 2024

C2y Proposal: Essential Effects for C

The proposal "Essential Effects for C" by Alex Celeste aims to enhance C with a type and effect system for better side effect management, categorizing effects into Local, Persistent, and Control groups.

Read original articleLink Icon
C2y Proposal: Essential Effects for C

The proposal titled "Essential Effects for C" by Alex Celeste suggests enhancing the C programming language by integrating a type and effect system. This system would require functions and blocks to declare the classes of effects resulting from their evaluation, thereby improving composability in metaprogramming and facilitating the definition of MISRA-style restrictions. The proposal outlines a formalized effect system that tracks side effects at a granular level, combining it with the type system to ensure that specific effects occur or do not occur in designated contexts. The proposed system categorizes effects into three groups: Local, Persistent, and Control, with a focus on static effect tracking rather than dynamic handling. The document details how effects propagate within scopes and how they can be combined, emphasizing that effects are distinct from types. The proposal also raises questions about additional useful effect classes and the potential for a notation system for effect annotations. Overall, the proposal aims to enhance the safety and reliability of C programs by providing a structured way to manage side effects.

- The proposal aims to integrate a type and effect system into C for better effect tracking.

- It categorizes effects into Local, Persistent, and Control groups.

- The system focuses on static effect tracking without dynamic handling.

- It emphasizes the distinction between effects and types in programming constructs.

- The proposal invites feedback on additional effect classes and notation systems.

Link Icon 7 comments
By @Joker_vD - about 1 month
Could someone explain to me how effects are radically different from types? Every time I see them introduced, it's always "type and effect system", not just "extending the type system with effect types", yet the rules the effects obey seem to be fundamentally the same that e.g. the constrained generics follow.
By @hgs3 - about 1 month
As the proposal points out there are already a number of projects for adding an effect system to C. There are also other approaches to aid in correctness, from formal methods to coding standards like MISRA. I think merging any approach into the C standard would be problematic because (1) it limits perceived choice by “blessing” one approach over others and (2) it standardizes an approach which history might prove to be flawed. I would encourage the authors to consider implementing their effect system as a separate tool and observe its practical reception.
By @dmpk2k - about 1 month
How about some basic hash table support in the standard library first? I know this is snarky, but ISO's priorities over the past couple decades... :(
By @swiftcoder - about 1 month
Is there a hope in hell of the C committee actually accepting an effects system (not necessarily this particular proposal)? I have the impression that they are quite a conservative group en masse, and this feels like a very uphill battle
By @EPWN3D - about 1 month
Syntactically, I'm not sure why you wouldn't use attributes on the type or function. The syntax in the proposal's examples seems extremely disruptive and unfriendly to macro-ification.
By @noobermin - about 1 month
So...uh, how could a compiler actually check for this? Is this merely a way to hint to the compiler to make certain optimisations? C is not known to be for these kind of things. I mean, you could always add attributes, no?
By @JonChesterfield - about 1 month
ISO C should love this. It's really complicated. It adds ad hoc compile time guards to stuff. C++ doesn't have this yet so they get to lead the way for a moment.

I hate it but whatever - my love for C ended sharply after C99 fno-strict-aliasing anyway.