3 ms·

Yes, it can be implemented basically in any language that can hide the data members so I also see nothing special about it.

surajrmal 1y ago
It's only special when you are coming from C. Kernels implemented in c++ have done this sort of thing for a long time.
- kimixa 1y ago
  There's plenty of C string libraries with opaque types. No reason why a similar thing can't be done there.
  - menaerus 1y ago
    Opaque types cannot be stack- or statically allocated.
    - kimixa 1y ago
      No, but many languages already have limitations like "strings live on the heap", even many discussed in this thread. Dynamically sized objects on the stack has always been difficult. You could argue that C special casing fixed length strings to allow that is the odd one out.
ViewTrick1002 1y ago
Not really. Hiding the data is the easy part. What makes Rust special is that you need to acknowledge the potential errors when unwrapping the type. With a standard library and culture built on exposing the edge cases at compile time. That is where the guarantees and feeling of certainty comes from.
- lock1 1y ago
  Visibility modifier as a native language feature is not the easy part. It's more like "comptime safety feeling" => "language w/ visibility modifier" but the converse is not necessarily true. Without language support, it's back to C convention or workaround again.
- menaerus 1y ago
  Show me an example. I don't understand this marketing lingo.
  - ViewTrick1002 1y ago
    Take for example working with file names and paths. In for example Linux paths are a collection and bytes and does not need to be valide unicode. Which some programming languages hides from you and subtly introduces errors. Or even worse, accepting that strings may contain invalid unicode poisoning the entire language with uncertainty. If you are iterating over the files in a directory the Rust standard library gives you paths. Not strings. To convert a path that to a regular string type which is valid unicode you need to acknowledge that the path may be invalid. Either unwrapping and panicking or handling the error. To do this the standard library gives two options: /// Yields a [`&str`] slice if the `Path` is valid unicode. /// /// This conversion may entail doing a check for UTF-8 validity. /// Note that validation is performed because non-UTF-8 strings are /// perfectly valid for some OS. pub fn to_str(&self) -> Option<&str> https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.to_str https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho... Or accept that the conversion may be lossy: /// Converts a Path to a Cow<str>. /// /// Any non-UTF-8 sequences are replaced with U+FFFD REPLACEMENT CHARACTER. pub fn to_string_lossy(&self) -> Cow<'_, str> https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.to_string_lossy https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho... You get to make a choice, and panicking/erroring is perfectly valid if you only expect valid unicode paths. As the world and your software changes if you suddenly encounter a non-unicode path then you will immediately know where the error comes from and can fix the issue. Instead of trying to pinpoint the root source of an error far exposing itself far down stream.

surajrmal 1y ago

It's only special when you are coming from C. Kernels implemented in c++ have done this sort of thing for a long time.

kimixa 1y ago
There's plenty of C string libraries with opaque types. No reason why a similar thing can't be done there.
- menaerus 1y ago
  Opaque types cannot be stack- or statically allocated.
  - kimixa 1y ago
    No, but many languages already have limitations like "strings live on the heap", even many discussed in this thread. Dynamically sized objects on the stack has always been difficult. You could argue that C special casing fixed length strings to allow that is the odd one out.

ViewTrick1002 1y ago

Not really. Hiding the data is the easy part. What makes Rust special is that you need to acknowledge the potential errors when unwrapping the type. With a standard library and culture built on exposing the edge cases at compile time. That is where the guarantees and feeling of certainty comes from.

lock1 1y ago
Visibility modifier as a native language feature is not the easy part. It's more like "comptime safety feeling" => "language w/ visibility modifier" but the converse is not necessarily true. Without language support, it's back to C convention or workaround again.
menaerus 1y ago
Show me an example. I don't understand this marketing lingo.
- ViewTrick1002 1y ago
  Take for example working with file names and paths. In for example Linux paths are a collection and bytes and does not need to be valide unicode. Which some programming languages hides from you and subtly introduces errors. Or even worse, accepting that strings may contain invalid unicode poisoning the entire language with uncertainty. If you are iterating over the files in a directory the Rust standard library gives you paths. Not strings. To convert a path that to a regular string type which is valid unicode you need to acknowledge that the path may be invalid. Either unwrapping and panicking or handling the error. To do this the standard library gives two options: /// Yields a [`&str`] slice if the `Path` is valid unicode. /// /// This conversion may entail doing a check for UTF-8 validity. /// Note that validation is performed because non-UTF-8 strings are /// perfectly valid for some OS. pub fn to_str(&self) -> Option<&str> https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.to_str https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho... Or accept that the conversion may be lossy: /// Converts a Path to a Cow<str>. /// /// Any non-UTF-8 sequences are replaced with U+FFFD REPLACEMENT CHARACTER. pub fn to_string_lossy(&self) -> Cow<'_, str> https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.to_string_lossy https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho... You get to make a choice, and panicking/erroring is perfectly valid if you only expect valid unicode paths. As the world and your software changes if you suddenly encounter a non-unicode path then you will immediately know where the error comes from and can fix the issue. Instead of trying to pinpoint the root source of an error far exposing itself far down stream.