On Mon, Nov 11, 2013 at 6:55 AM, spir <[email protected]> wrote:
> Hello,
>
> Well, I wonder if we could exchange those formats. Here is how they work:
>
> fn main () {
> struct P {i:uint, j:uint};
> let (b, u, i, x, c, s, a, p) =
> (false, 1u, -1, -1.11, 'c', "abc", [1,2,3], P{i:1,j:2});
> let z : Option<uint> = None;
>
> // Poly
> println!("{:?} {:?} {:?} {:?} {:?} {:?} {:?} {:?} {:?}",
> b, u, i, x, c, s, a, p, z);
> // ==> false 1u -1 -1.11 'c' "abc" [1, 2, 3] main::P{i: 1u, j: 2u}
>
> // Standard
> println!("{} {} {} {} {} {}",
> b, u, i, x, c, s);
> // ==> false 1 -1 -1.11 c abc
> }
>
> The format 'Poly" {:?}:
> * works for all types, including app defined, does not require trait
> definition or declaration
> * just does the right thing, telling the programmer all what is needed
> in an exact and complete manner (except "main::" is too much maybe)
>
> The format 'Standard' {}:
> * requires definition of trait 'Standard' for complex types (arrays,
> structs, enums), as well as its declaration for type variables
> * is ambiguous about chars and strings, as well integers (signed?)
>
> In other words, 'poly' gives us back the notation of data, as we (would)
> have noted them in code. Also, its tells us the type, if implicitely,
> except for the exact size of a number. This information is what we need in
> the general case for all kinds of feedback in program testing, diagnosis,
> debugging... The standard notation of data is not always the best possible
> form, but it always does the job and we are used to it. I guess we'll
> constantly use it for our own feedback.
>
> For this reason, I'd like to exchange the notations of these formats: have
> Poly be {} so that we are less annoyed at typing it. And call with a
> meaningful name, such as Notation, Literal or... Standard.
>
> I have no idea what the other format (the one currently noted {} and
> called Standard) is good for. I'd say it can be used as part of user
> output, but we already have good type-specific formats for that. Maybe this
> format is a polyvalent form of those specialised formats, so that we don't
> need to choose: then call *this one* "poly"... Also, noting this one {:?}
> would make sense.
>
> Denis
>
The reflection-based `{:?}` doesn't follow the privacy rules, so it will
never be a format with a stable output. The low-level implementation
details of a type aren't a sensible format for any application to be using.
I don't think `std::reflect` and `std::repr` should even be available
outside of debug builds because they're a huge backwards incompatibility
hazard and prevent Rust from exposing a stable ABI for a reasonable subset
of the standard library.
I think the following is a great example:
```
use std::hashmap::HashMap;
fn main() {
let mut xs = HashMap::new();
xs.insert(5, 5);
println!("{:?}", xs);
}
```
The output is not even usable for debugging, unless what you're debugging
is the hash table implementation:
```
std::hashmap::HashMap<int,int>{k0: 16592526953366606085u64, k1:
12349690536349946653u64, resize_at: 24u, size: 1u, buckets: ~[None, None,
None, None, None, None, None, None,
Some(std::hashmap::Bucket<int,int>{hash: 10818539429618494536u, key: 5,
value: 5}), None, None, None, None, None, None, None, None, None, None,
None, None, None, None, None, None, None, None, None, None, None, None,
None]}
```
Any type containing a hash table or a tree is going to have totally
unusable output too. It quickly becomes unusable for anything that's not a
thin wrapper around primitive types.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
