Clarify language and add notes what types of allocation patterns are acceptable. #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
atilaneves
reviewed
Jan 3, 2024
|
|
||
| Enormous troubles and inefficiencies stem from general purpose library code allocating memory as the library sees fit. This makes the library code far less usable. Memory allocation strategies should be decided upon by the user of the library, not the library. | ||
|
|
||
| The easiest way to achieve this is to design the library to not use memory allocation at all. For example, std.path assembles paths from parts without doing allocations - it returns Voldemort ranges that the user can then use to emit the result into a buffer of the user's choosing. | ||
|
|
||
| Library routines may allocate memory internally, but not in a way that affects the user. | ||
| In cases where allocation is necessary, Library routines may allocate memory internally, in such a way that it does not effect the user. Additionally, allocation patterns that use internal allocations, such as Dependency Injection, may be used to allocate. Note that this may require compiler support to fully implement. |
There was a problem hiding this comment.
s/effect/affect/.
What requires compiler support?
There was a problem hiding this comment.
I am just leaving the door open to potential future cases.
|
|
||
| Exceptions are inefficient and use the GC. Of course, they cannot be used in `nothrow` code. Examine each use of an Exception to see if it can be designed out of existence, like the Replacement Character method above. Design the return value such that an error is not necessary - for example, a string search function can return an empty string if not found rather than throw an Exception. | ||
| Investigate the use of Option types for error returns. | ||
|
|
||
| Investigate the use of "Option" or "Sum" types for error returns. |
There was a problem hiding this comment.
The problem with this is that bubbling up errors becomes a pain.
There was a problem hiding this comment.
Indeed, value type exceptions aka zero cost exceptions would be the option here as it'll bubble up.
Waiting on sumtypes before continuing that DIP work.
There was a problem hiding this comment.
The problem with this is that bubbling up errors becomes a pain.
How about polymorphic variants? That's a good idea from OCaml. See: https://keleshev.com/composable-error-handling-in-ocaml
There was a problem hiding this comment.
I don't think we need to wait for built-in sum types to address this. Ideally, any solution we come up with for the error-bubbling problem would apply equally well to built-in types and library types (like how Rust's ? operator can be overloaded by implementing the Try trait).
|
Value type exceptions like I've designed them will automatically combine
between different sets. That is the only advantage I can see from that
link.
…On Sat, Feb 3, 2024, 12:15 Mengu Kagan ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In Design.md
<#2 (comment)>
:
>
Exceptions are inefficient and use the GC. Of course, they cannot be used in `nothrow` code. Examine each use of an Exception to see if it can be designed out of existence, like the Replacement Character method above. Design the return value such that an error is not necessary - for example, a string search function can return an empty string if not found rather than throw an Exception.
-Investigate the use of Option types for error returns.
+
+Investigate the use of "Option" or "Sum" types for error returns.
The problem with this is that bubbling up errors becomes a pain.
How about polymorphic variants? That's a good idea from OCaml. See:
https://keleshev.com/composable-error-handling-in-ocaml
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSL45M7ZCN7UUJG6LGXQDYRVXQDAVCNFSM6AAAAAA76RJ7HCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNRQGYYTANRQGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@WalterBright This does not include my thoughts on relaxing allocation rules for non "Core" packages as that would be dependent on going with my proposed split-root design (which I am still working on).