proposal: spec: read-only types
I propose adding read-only types to Go. Read-only types have two related benefits: 1. The compiler guarantees that values of read-only type cannot be changed, eliminating unintended modifications that can cause subtle bugs. 2. Copying as a defense against modification can be reduced, improving efficiency. An additional minor benefit is the ability to take the address of constants. This proposal makes significant changes to the language, so it is intended for Go 2. All new syntax in this proposal is provisional and subject to bikeshedding. **Basics** All types have one of two _permissions_: read-only or read-write. Permission is a property of types, but I sometimes write "read-only value" to mean a value of read-only type. A type preceded by `ro` is a read-only type. The identifier `ro` is pronounced _row_. It is a keyword. There is no notation for the read-write permission; any type not marked with `ro` is read-write. The `ro` modifier can be applied to slices, arrays, maps, pointers, structs, channels and interfaces. It cannot be applied to any other type, including a read-only type: `ro ro T` is illegal. It is a compile-time error to * modify a value of read-only type, * pass a read-only slice as the first argument of `append`, * use slicing to extend the length of a read-only slice, * or send to or receive from a read-only channel. A value of read-only type may not be immutable, because it may be referenced through another type that is not read-only. Examples:
Posted by jba on Nov 25, 2017, 12:49 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
proposal: spec: read-only types
I propose adding read-only types to Go. Read-only types have two related benefits: 1. The compiler guarantees that values of read-only type cannot be changed, eliminating unintended modifications that can cause subtle bugs. 2. Copying as a defense against modification can be reduced, improving efficiency. An additional minor benefit is the ability to take the address of constants. This proposal makes significant changes to the language, so it is intended for Go 2. All new syntax in this proposal is provisional and subject to bikeshedding. **Basics** All types have one of two _permissions_: read-only or read-write. Permission is a property of types, but I sometimes write "read-only value" to mean a value of read-only type. A type preceded by `ro` is a read-only type. The identifier `ro` is pronounced _row_. It is a keyword. There is no notation for the read-write permission; any type not marked with `ro` is read-write. The `ro` modifier can be applied to slices, arrays, maps, pointers, structs, channels and interfaces. It cannot be applied to any other type, including a read-only type: `ro ro T` is illegal. It is a compile-time error to * modify a value of read-only type, * pass a read-only slice as the first argument of `append`, * use slicing to extend the length of a read-only slice, * or send to or receive from a read-only channel. A value of read-only type may not be immutable, because it may be referenced through another type that is not read-only. Examples:
Comments (0)
No comments yet. Start the discussion.