I am developing a linter (for an internal DSL that probably should have been thrown away decades ago). A core data type we are currently using is what we call a "ScriptString". This is essentially just:

struct ScriptString {
    text: String,
    source_document: Uri,
    source_range: Range,
    // Additional fields to keep track of things for error reporting and analysis
}

The issue that we are running into is that we are finding that we need to implement a bunch of the standard string methods from Str for this. Bassically, any str method that returns an &str wants to become a ScriptString method that returns a new ScriptString. Text, source_document, and source_range get populated in the obvious way; and the additional fields get set to default values.

This approach is pretty wasteful since we need to copy substrings instead of just taking a slice, but we don't really care about that.

The problem that is causing us grief is that we cannot figure out a good way to use most of the built-in str methods, so we have been manually reimplementing them with ugly and error prone index arithmethic.

The closest thing to a solution we have found would be to use substr_range, but that API is still not stable.

Is there a different solution to this problem we can try?

4 posts - 4 participants

Read full topic