Some security-sensitive libraries do this, e.g. https://www.javadoc.io/doc/com.google.common.html.types/type...

Allowed you to? You could do that in C++ quite happily, it's just not useful enough. To bother implementing, at least.

It's absolutely useful enough, it's just that it's awful in C++ due to language limitations as opposed to other languages such as Haskell, where it is standard.

How would be awful in c++? It seems trivial to do, basic_string is already templated and distinct instantiations are not mutually compatible by default. In fact wstring, u8string, u16string, u32string exist today in the language simply as distinct instatiantions of basic_string. You can crate your own by picking a new char type. Algorithms can be and are, generic and work on any string type.

They're not worth the effort in C++ because it doesn't have strictly enforced affine/dependent types. The GP is invisioning a language that does.

Why do you need them to enforce that only escaped strings are passed to functions?

     html::append(html::string text);

with an constructor

     html::string(std::string)

that handled escaping seems like it'd work just fine.

Not quite at that level, but rust does have OsStrings (managed the same way as the OS, often but not always utf8), and CStrings (basically just byte buffers - just like c likes). There are special rules around inclusion of nulls and null terminators. It'll give the benefits of the behaviour you mentioned - not allowing an invalid string type for a function call.

The sqlx crate for rust also has a macro called query!, which (at compile time) validates the SQL and created a value of type "record". Similar idea there, since you'll get early exceptions thrown by the compiler if you write sql with errors in it.

Cf. newtype in Python and Haskell.

Go is like that. Not the "mixed within" part, though html/template's AST understands the context where you're using a value and escapes it differently. For example, https://golang.org/pkg/html/template/#HTML

Failing that, you could also adopt a naming convention with prefixes to indicate what sort of thing it is you're storing there:

hsCode = hsFromUs(usInputBuffer);

ssStoredCode = ssFromHs(hsCode);

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

Yes. But having the compiler enforce it is your first line of defense. If it doesn't compile, you know there is an actual problem. In modern IDEs, you see these compile errors as quickly as you type them.

You would probably like Java 1.4

This pattern (newtyping) is a huge weakness of Java in general, and even more so older Java, and people who like newtyping are not going to like java.

Because creating newtypes in Java is

1. verbose, defining a trivial wrapper takes half a dozen lines before you've even done anything

2. slow, because you're paying for the overhead of an extra allocation and pointer indirection every time, unless you jump through unreadable hoops making for even more verbose newtypes[0]

It is a much more convenient (and thus frequent) pattern in languages like Haskell. Or Rust.

[0] https://gist.github.com/jbgi/d6b677d084fafc641fe01f7ffd00591...

I use Java 14 now. Java 11 in production.

Try Pascal (free pascal or Delphi)

I used Pascal for the 80's and part of the 90's. Currently use Java. I almost tried Delphi, but my shop moved on to something else between Pascal and Java.

AFAIK they just provide type name aliases, which do not enforce or warn of you if you mix the “types”.

They have changed it

Now the string types have an encoding and the string themselves, too. When you assign a string to a string variable with a type of a different encoding, the string is automatically converted.

But it is causing a huge mess. Especially with existing code. When you have a library using utf-8 and one library using the default codepage, that is not valid anymore. Although you can manually override the encoding for each string, so any string might have any encoding regardless of its type.

Here is an example of the mess:

I have a benchmark of various maps in freepascal. The benchmark creates strings of random bytes to use as keys.

A classic key-value store is the sorted TStringList.

Now the benchmark of the TStringList fails. Apparently, because it now assumes the keys are valid utf-8 when using the utf-8 codepage as default codepage.

The default codepage can be changed. When I start the benchmark with LANG=C .. it works with the random byte keys. On Windows, the default codepage is usually latin1, so it would work there, too.