Rename fmt::Default to fmt::Format

[brendanzab]

This is in preparation for adding a #[deriving(Format)] and removing the ToStr trait, as discussed in #9806.

[brendanzab]

Ok, it seems the use of a free function for to_str is contentious. Please wait for discussion on this. cc. @alexcrichton @thestinger

[alexcrichton]

I'm having second thoughts about this again, which I guess was a little inevitable. I very much like the name Default and I don't think that the name Format is correct for the {} format string. The reasoning as I understood it for renaming is:

• deriving(Default) is silly, and deriving(Format) makes total sense, yet it is convention that the name of the string passed to deriving is the same as the name of the trait
• My initial suggestion of deriving(FmtString) is apparently not sufficient because no one uses {:s} (although I'm still very much in favor of this route)
• Because this will likely be deriving(Format) much more often than impl fmt::Format for T, the deriving-format should be favored.

I'm still a little uneasy about this reasoning (as I was before). I'd ideally like to discuss this further to figure out how to keep the name fmt::Default (or find a better name). I still think that the ToStr trait needs to go away, but I have still yet to be totally convinced that deriving(Format) is the best way to do it.

[metajack]

Why not copy Haskell here and call it Show or even Display.

[brendanzab]

Ok, removed the to_str function addition for now.

[brendanzab]

@metajack Because it needs to be consistent with the naming convention of the other format traits.

@alexcrichton I agree with your reasoning. It is a shame we can't have paths in deriving. Then you could have:

use std::fmt;

#[deriving(fmt::Default)]
struct MyStruct;

The global-ness and hard-wiredness of deriving trait names is as concerning as it is with macro identifiers. Won't this also be an issue once we allow clients to create their own deriving implementations? What happens when you have two crates that implement deriving for two different traits of the same name?

[huonw]

That's a good point re user-implementable deriving; it would be nicer to be able to register a deriving mode for a specific trait (say foo::bar::Trait), and then any of the following could work (and only properly qualified paths like the following would work):

#[deriving(::foo::bar::Trait)] struct Struct;

use foo;
#[deriving(foo::bar::Trait)] struct Struct;

use foo::bar;
#[deriving(bar::Trait)] struct Struct;

use foo::bar::Trait;
#[deriving(Trait)] struct Struct;

use new_name = foo::bar;
#[deriving(new_name::Trait)] struct Struct;

but, #[deriving] is a syntax extension, and doesn't have access to anything other than the AST; no info from resolve (and foo::bar::Trait could even be a trait created by a macro/syntax extension... i.e. it might not even exist in the AST when the deriving is being expanded).

[huonw]

Needs a rebase.

[alexcrichton]

I'm adding this to the meeting agenda.

[alexcrichton]

We decided in today's meeting to call this trait Show, and then we can have deriving(Show).

If you're out of time, I can take over this patch as well.

[brendanzab]

What concerns me is that this rename is not being done because fmt::Default is a bad name, it's being done specifically due to limitations with deriving. It's treating the symptoms, not the problem. If library authors are going to be able to implement their own derivable traits in the future, there will inevitably be name clashes. We have a module system for a reason - let's not head down the path of C-style namespacing (ie. prefixed names).

I guess what I'm saying is, can we try to think of creative design solutions for deriving rather than resorting to renaming perfectly good trait names? From exchanges on IRC and @huonw's posts above it seems that this is a very challenging problem, but solving it could help syntax extensions in general - not just for deriving.

[alexcrichton]

It's a tough problem to process paths in deriving. These two mechanisms (use statements and deriving modes) operate very differently. Everything with deriving happens in the expansion phase whereas everything with use statements happens as part of the resolve phase. I suppose we could run resolve twice, but it seems like things could get complicated quickly.

I think that there's two reasons for me for Default => Show. The first is that Default isn't really a great name for what it's used for, and the second is because of the deriving issue.

It is an interesting concern though about deriving essentially having a global namespace, but the question is whether to resolve the deriving(Show) missing functionality now, or do we punt it to later as we ponder the deriving namespace problem?

[brendanzab]

Ok, I'm going to close this for now.

[brendanzab]

It's a tough problem to process paths in deriving. These two mechanisms (use statements and deriving modes) operate very differently. Everything with deriving happens in the expansion phase whereas everything with use statements happens as part of the resolve phase. I suppose we could run resolve twice, but it seems like things could get complicated quickly.

Yeah, it's a tricky problem. But I also worry about macros living in the global namespace too. The fact that you can't do pub on them or access them via paths (eg. std::io::println!) seems weird from a user's perspective, even if it is hard to do on the compiler side of things. Apparently tis is also related to these issues with deriving?