put reflection in format strings behind a feature gate or mark it with #[experimental]

[thestinger]

This is an ABI stability hazard as it makes the entire internal representation of a type part of the public ABI. The standard library modules are now marked experimental, but this warning doesn't trigger when they're used via the format macros.

[alexcrichton]

Nominating.

[thestinger]

An alternative would be adding a lint warning for this mentioning the ABI stability hazard. That way, it's very easy to use for debugging but relying on it to make the application/library work requires making the informed decision to silence the warning or ignore it.

[alexcrichton]

A wacky idea would be to make this a lint that's allow-by-default at O0 and deny-by-default at O1+.

[sfackler]

I would personally lean towards a lint as opposed to a feature gate.

[nikomatsakis]

cc me

[pnkfelix]

Assigning P-backcompat-lang, 1.0 blocker. (For making decisions about this and reflection more generally)

[brson]

We're not relying on this much anymore, can potentially remove reflection.

[lilyball]

I am in favor of a lint. It's very useful to keep for debugging purposes, but I wouldn't go so far as to deny it outright for non-debug builds. A lint that warns by default seems like a reasonable compromise.

[thestinger]

@kballard: It's a lot less useful now that it can't look inside vectors. Applications making good use of data structures like maps and sets are also unable to get much from it in many cases. It might make sense to just discard this kind of reflection.

[lilyball]

@thestinger It's useful for custom user-defined data structures.

I wish there was a hybrid reflection, which would use Show for types that implement it and Poly for types that don't, but there's no way to make this work for collections without implementing the hybrid directly for them (because collections implement Show in terms of their elements, which must implement Show as well, but what I really want is to be able to print a vector of non-Show-able objects).

I don't suppose it would be possible to have a macro impl_debug_show!(MyType) that implements Show by returning the output of Poly, and having a lint be able to find invocations of that? This would require the lint being able to see through generic implementations of Show::fmt() and tell that they're calling a concrete implementation that's been flagged as a debug show, and I don't know if lints have that capability.

The idea here is that I could do something like

struct Foo {
    a: int,
    b: ~str
}
impl_debug_show!(Foo)

fn foos() -> ~[Foo] {
    ~[Foo { a: 3, b: ~"test" }, Foo { a: 4, b: ~"hello" }]
}

fn main() {
    let x = foos();
    println!("{}", x);
}

and get something like

[Foo { a: 3, b: ~"test" }, Foo { a: 4, b: ~"hello" }]

printed out, along with a lint warning during compilation pointing at the println!() call informing me that I'm relying on a debug Show.

[lilyball]

I suppose we could add a hybrid show trait after all, implement it for all Rust-provided collections, and live with it using Poly for any user-defined collections that don't explicitly implement this, because at least it will still work with vectors and hash maps (which are probably the most important collections to be able to print).

[nikomatsakis]

Why would impl_debug_show! be better than #[deriving(Show)]?

[lilyball]

@nikomatsakis You mean a #[deriving(DebugShow)]? I suggested the macro because you could insert that somewhere else in your crate in order to turn on debug-printing of a struct, whereas deriving needs to be done at the struct definition, but this is all so hacky anyway.