Comment by sharpercoder | Hacker News Reader

Comment by sharpercoder | Hacker News Reader

I personally think we should make a plentyfold of datastructures respresenting strings. Sure, I want a geenric fits-all structure to represent text as provided in many libraries and frameworks, such as .NET's String class. However, I have many situations where using that same String class is pure overkill and prone to security bugs. For instance, I want a DigitsOnlyString, representing only the numbers [0-9]. But I also want a NumbersOnlyString, representing the digits [0-9] but also all other number characters there are in Unicode. The same for e.g. emoji's, latin characters ([azAZ]), extended latin ([azAZ], plus a subset of diacritics) Chinese characters, and I can go on for quite some more examples (Password anyone? Don't allow a lot of Unicode edgecases). These classes will have the benefit of really efficient encoding in bits, being more secure, more clarity to programmers and most important of all clear reasoning. I bet 80% of String uses can be moved to a more constrained type.

All those are is a set of verification functions tied to strings ... we really dont need native data types representing this. Im not sure why you are not able to find a lib/function that easily verifies such things. Programing languges are the basic foundation which should be concerned with performance , organization and making sure freedom is given to the programmer. These are all specific edge cases for the programmer to define not for the programing language to worry about.

Would you rather they speed up the compiler/interperter or add edge case string classes? Its not like there isnt a trade off. This is a bottom of the barrel concern.

> Programing languges are the basic foundation which should be concerned with performance , organization and making sure freedom is given to the programmer.

This is one view, but there are others. For example, instead of focusing on performance and freedom, the programming language could focus on safety or formal properties.

E.g. there should never be code that compiles but is unsafe, or which can have certain classes of common bugs.

That’s a valid view, but it would definitely be powerful if the language’s type system could express restricted character sets, right? You can already do something like this with e.g. Ada’s constrained subtypes, like encoding the length of a string or the range of a number into the type, making it statically impossible to accept invalid input. That’s really cool!

For what purpose would you disallow certain unicode sequences in a password? I'd expect the user's input to be treated as a sequence of bytes which gets passed directly to your hashing function.

Reply on news.ycombinator.com