Zig’s lack of a string type & invalid values

[lunacookies]

@Sze

If Zig adds some possibility to have distinct types, then I think it would be good to have a distinct type that is a valid UTF-8 encoded string in the standard library, but personally I don’t really want that type to be a special builtin type.

If we had a type like that, I would want it to be implemented with language features, so that other libraries can create similar types, which then for example add specific iterators that operate on grapheme-clusters etc.

Just adding one hard-coded distinct type seems more like a hack to me, giving up on finding a good solution that is expressible in user space and instead giving the user a half baked, builtin solution. Personally I think it wouldn’t give enough benefits and isn’t a satisfying solution to me.

I think I actually agree with this. Making the language simpler by pushing features into user code is often a good idea. And the point about it not being super beneficial is fair, too.

@Sze

What I would find potentially interesting, would be if we could create custom string literal types, something like this:

This is actually such a great idea, I’m kinda kicking myself for not thinking of it myself! :‌D Even if you don’t have the special string literal syntax from your post, writing u("Hello World") isn’t much more annoying than "Hello World". I wonder if something like this has a place in the standard library? For something like this to be effective (i.e. make std.fmt and std.json treat strings and u8 slices differently) it has to be adopted throughout a codebase.