Uh oh!
There was an error while loading. Please reload this page.
RFC: abstract struct and abstract enum - #10
Conversation
There was a problem hiding this comment.
is a word I did find but didn't think is better. Perhaps other people have different opinions?
chris-morgan
commented
Mar 17, 2014
Just a note on formatting—you don't appear to be fond of second-level headings? Going from h1 to h3 doesn't make sense semantically. |
glaebhoerl
commented
Mar 17, 2014
@chris-morgan The semantic content of document markup is not something I've been thinking about. I couldn't tell you why I did it this way because I literally didn't have a single conscious thought about it. For some reason I felt like it. If I want to rationalize, then maybe I wanted to better emphasize the separation between the levels (I also went from h3 to h5). In any case, noted for the future. (Aside: going from h1 to h3 to h5 is perfectly sensible if you're a rook.) |
alexcrichton
commented
Mar 17, 2014
As a side note, can you format the document to an 80-character width? |
There was a problem hiding this comment.
Disallowing fine-grained field privacy seems quite unfortunate. While rare, it has some crucial use-cases (such as the fmt::Formatter struct).
There was a problem hiding this comment.
This isn't an expressiveness question, just a convenience question. You can still accomplish the same thing by making a separate abstract struct with the private fields and including it as a field of the non-abstract struct. As I commented elsewhere, I'm also perfectly fine with adding back pub fields if people think it's used frequently enough to be worth having.
glaebhoerl
commented
Mar 17, 2014
OK, will do. |
huonw
commented
Mar 17, 2014
(If we were to do sentence-per-line, or at least, new sentences start a new line; then the diffs might be nicer as we edit as they won't include epic rewrapping due to a 2 word addition at the start of a paragraph?) |
glaebhoerl
commented
Mar 18, 2014
I'm more concerned by the fact that after I pushed the updated version, @alexcrichton's earlier comments got hidden as "commented on an outdated diff". Given that the most important part of these RFC PRs is supposed to be the discussion, this seems unfortunate. |
nikomatsakis
commented
Mar 18, 2014
On Tue, Mar 18, 2014 at 01:45:18AM -0700, Gábor Lehel wrote:
I think best practice is not to force push RFCs (that is, do not use |
pnkfelix
commented
Mar 18, 2014
Filed as issue #14 against RFC 0001. |
glaebhoerl
commented
Mar 18, 2014
@nikomatsakis I deliberately avoided touching the existing commit (force pushing), and instead added a new one. The issue is that even so, GitHub now hides diff comments on the previous commit by default. They are still there and can be expanded by clicking on them, but they're collapsed by default, even though their content is no less relevant than it was. |
pnkfelix
commented
Mar 18, 2014
There are bookmarklets one can use to dynamically expand collapsed comments. See e.g. https://coderwall.com/p/akdgoq (But I guess you might have to install such a bookmarklet locally on your own browser, since it seems like github's markdown renderer strips out |
nikomatsakis
commented
Mar 18, 2014
On Tue, Mar 18, 2014 at 04:26:04AM -0700, Gábor Lehel wrote:
Oh. That is certainly something to be aware of. |
brson
commented
Mar 25, 2014
This was discussed along with #1 in today's meeting: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-03-25.md#private-fields-by-default The consensus was that this approach has a broader and less understood impact than simply flipping the defaults per #1; we'll continue with that approach and not this one. Thank you. |
more fixed typos in the documentation
[RTN] Fix typo: "h" -> "hc" & "ds" -> "s"
No description provided.