From 6258d010a1558040e7c08844b561f7f887db56ac Mon Sep 17 00:00:00 2001 From: Alexander McCord Date: Wed, 5 May 2021 14:46:36 -0700 Subject: [PATCH] Minor polish. --- rfcs/syntax-singleton-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/syntax-singleton-types.md b/rfcs/syntax-singleton-types.md index 207f78e5..4221f9f1 100644 --- a/rfcs/syntax-singleton-types.md +++ b/rfcs/syntax-singleton-types.md @@ -74,4 +74,4 @@ Additionally, we can change the type binding `boolean` to actually alias to `tru ## Drawbacks -If done naively, type checking performance could regress severely. Especially in situations where we may need to check if the providing union of constant strings is a subset of another union of constant strings that is receiving it. The time complexity of that situation is `O(m * n)`. This could be made much worse because the time complexity of `std::string::operator==` is `O(n)` making it `O(m * n * o)` which is completely unacceptable. Fortunately, the strings are meant to be constant, so we just have to hash the string exactly once and then use this hashed value to compare for the rest of type analysis, so `O(m * n * 1)` is still `O(m * n)`. None of this is an issue with booleans and numbers (not part of this proposal) because their comparisons are always `O(1)`. +If done naively, type checking performance could regress severely. Especially in situations where we may need to check if the providing union of constant strings is a subset of another union of constant strings that is receiving it. Without singleton types, the time complexity of that situation is just `O(m * n)`. This could be made much worse because the time complexity of `std::string::operator==` is `O(n)` leading to `O(m * n * o)` which is completely unacceptable. Fortunately, the strings are meant to be constant, so we just have to hash the string exactly once and then use this hashed value to compare for the rest of type analysis, so `O(m * n * 1)` is still `O(m * n)`. None of this is an issue with booleans and numbers (not part of this proposal) because their comparisons are always `O(1)`.