On 11/11/2013 01:18 PM, Daniel Micay wrote:
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.
Provided it goes on doing the right thing, meaning ~ reproducing data notation,
I'm happy with it.
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.
It is for programmer feedback anyway. If 'poly' is removed, I cry. It promises
to be the best and most common tool Rust provides to programmers.
A way to solve that issue, preventing this format to be mis-used for app output,
may be to have funcs specific for programmer feedback, which in standard use
'poly' [1]. Other writing funcs, for app output, would not normally use it.
More generally, it may be a good idea to (more) clearly separate "meta" features
for programmer help from app modelling features.
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:
You are right. But the reason for a programmer to print out a hashmap should be
to debig it. Else, we should ask for different or more precise data (eg, its
size, or the buckets).
```
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.
As said, it cannot be perfect in all cases. At times, we will need custom
formats even for programmer feedback. Alternative: change the 'poly' format for
hashtables. (But as it is, is looks good to me: it says what we need, and can
barely be made more compact or readable.)
What I would change is presenting structs (maybe arrays as well) in multiline
format whenever some of their fields (items) are complex. This would give:
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]
}
Denis
[1] When the language lets me do it, such a programmfeedback func is the first
utility I write. I call it "note" (as they write data notation) or note* when I
can have several of them.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
