Thin UTF8 string wrapper

[Jonathan Marler]

On Friday, 6 December 2019 at 16:48:21 UTC, Joseph Rushton 
Wakeling wrote:
> Hello folks,
>
> I have a use-case that involves wanting to create a thin struct 
> wrapper of underlying string data (the idea is to have a type 
> that guarantees that the string has certain desirable 
> properties).
>
> The string is required to be valid UTF-8.  The question is what 
> the most useful API is to expose from the wrapper: a sliceable 
> random-access range?  A getter plus `alias this` to just treat 
> it like a normal string from the reader's point of view?
>
> One factor that I'm not sure how to address w.r.t. a full range 
> API is how to handle iterating over elements: presumably they 
> should be iterated over as `dchar`, but how to implement a 
> `front` given that `std.encoding` gives no way to decode the 
> initial element of the string that doesn't also pop it off the 
> front?
>
> I'm also slightly disturbed to see that 
> `std.encoding.codePoints` requires `immutable(char)[]` input: 
> surely it should operate on any range of `char`?
>
> I'm inclining towards the "getter + `alias this`" approach, but 
> I thought I'd throw the problem out here to see if anyone has 
> any good experience and/or advice.
>
> Thanks in advance for any thoughts!
>
> All the best,
>
>      -- Joe

Good questions. I don't have answers to them all but I hope this 
information is helpful.

I use wrapper structs to represent properties in this way as 
well.  For example my  "mar" library has the SentinelPtr and 
SentinelArray types which guarantee that the underlying pointer 
and/or array is terminted by some value (i.e. like a 
null-terminated C string).

If I'm creating and use these wrapper types inside a 
self-contained program then I don't really care about API 
compatibility so I would use a simple powerful mechanism like 
"alias this".  For libraries where the API boundary is important 
I implement the most limited API I can.  The reason for this, is 
it allows you to see all possible interaction with the type.  
This way, when you need to change the API you know all the 
existing ways it can be interacted with and iterate on the API 
design appropriately.  This is the case for SentinelPtr and 
SentinelArray.  For this case I only implement the operations I 
know are being used, and I made this easy by creating a simple 
module I call "wrap.d" 
(https://github.com/dragon-lang/mar/blob/master/src/mar/wrap.d).

If you have a struct that wraps a string and guarantees it's UTF8 
encoded, wrap.d lets you declare that it's a wrapper type and 
allows you to mixin the operations you want to expose like this:

struct Utf8String
{
     private string str;
     import mar.wrap;

     // this verifies the size of the wrapper struct and the 
underlying field
     // are the same, and creates the wrappedValueRef method that 
the other
     // wrapper mixins use to access the underlying wrapped value
     mixin WrapperFor!"str";

     // Now you can mixin different operations, for example
     mixin WrapOpCast;
     mixin WrapOpIndex;
     mixin WrapOpSlice;
}


On the topic of immutable(char)[] vs const(char)[]. If a function 
takes const data, I take it to mean that the function won't 
change the data.  If it takes immutable data, I take it to mean 
that the function won't change it AND the caller must ensure data 
won't change while the function has it.  However in practice, 
functions that require immutable data sill declare their data be 
"const" instead of "immutable".  I think this is because 
declaring it as immutable would require extra boiler-plate all 
over your code to cast data to immutable all the time.  So most 
functions end up using const even though they require immutable.