New member to the list im no genius but am looking for a replacement for c for system programming.
1) Great work on UTF8 strings and USC4 chars ( I do some work with chinese chars and USC-2 just doesn't work here) . BTW why null terminated strings if you have arrays . Any c interop will require conversion to Unicode chars anyway fr a generic lib ( and for most IO the perf cost of a copy is pretty irrelevant) , Speaking of which its very useful in strings keeping the char count as well as the byte length mainly so you can go if ( str->length == str->count) to avoid any Unicode parsing when you convert to ascii. ( you could use a flag or the high bits of a int64 ) - or use a subtype stating its ASCII. 2) Does Rust have anything like bitc HasField ,? BitC introduced has field constraint and this was very useful , the field could be a function or property but you can then put on a method that the type HasField x and like an interface it hides the implementation , you could use any type with met the constraint. . It also meant encapsulated types and the associated "this" pointer / vcall issues could possible be avoided since the method only specified what filed it used the rest would be private ( for that method) .To me this greatly reduced the need of having private fields/members which existing c programmers will just follow as they find it hard to pick up type classes initially. You may be able to use hashfield for a fascade to further effect to hide internals . Since you guys are now considering this and objects I would read the below comments very carefully. BitC also had a major issues working with type classes and objects namely that it was very confusing whether to use traits( type classes) or classes for polymorphism , there was a huge dichotomy which was confusing and classes with private members made this worse.. Obviously the main issue was cross unit compilation with multiple types but I believe you guys have an answer to that.. Here is what Shap wrote about has field in his summary.. "In BitC, we introduced a built-in type class *has-field*. If struct S has field *f* with type *T*, then has-field(S, f, T). This was a bit of a kludge, in that the language doesn't admit atoms in general, but that's minor and fixable. The interesting point is that it generalizes readily to member functions and to structure methods (which we *did* have). Which means that it can provide something very similar to a subclass relation at parameters. To the extent that this works, *has-field* subsumes inheritance. What *has-field* does *not* subsume is virtual member functions, though it can actually be made to serve there. The problem is that without some form of encapsulated This type, we end up with parametricity rather than encapsulation. In most cases this is okay, but in some cases we really need encapsulation. The single inheritance pattern, whatever its flaws, provides a nicely controlled form of encapsulation. So this isn't a critique of type classes as much as it is an observation that type classes and object classes aren't the same thing and aren't interchangeable. The catch is that you are now forced to contemplate the introduction of object classes and inheritance. Once you do that, you end up in a place where *almost* everything done by type classes and type class instances can now be done by classes and object instances. The only thing missing, really, is a way to get the deep constant and compile-time constant properties captured so that we can inline things aggressively enough to use this approach at ground operators. And *that* actually seems to me like something that could be done. In the end, I'm left wondering what purpose general type classes would still serve in such a system. The built-in classes continue to have value as a way to capture, trace, and manage constraints within the compiler implementation, but that's quite different from user-extensible classes." Ben _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
