Leaf Petersen

@lrhn I got pretty lost in the above, maybe because of the level of abstraction. I don't really understand what problem you're worried about, so maybe a concrete example would...

> Is it? It doesn't seem like that much of a burden. Do we have data supporting this? @Hixie It is absolutely a burden for library maintainers, and we have...

> However, if we maintain that the addition of a private member should not cause an error to occur in a different library This principle, while a nice thing to...

What do the two implementations do? I think from the linked issue, at least the analyzer follows the old spec? So this is a breaking change? No objection to the...

> statically distinguishable in some way e.g. by declaring them `private` or `protected` or something like that? ;)

There are no current plans to work on this. It is something we might consider in the future, but currently we have a pretty full slate of things to work...

> It can only ever become a runtime error in dynamic calls, since no function type has a named parameter with a private name. This isn't true. The code below...

> That doesn't contradict that it can only give a runtime error for a dynamic invocation. Sorry, I misunderstood you to be saying that every such dynamic call must result...

We talked about this today. There is a general consensus that a way to express binary literals would be very useful. There is some sense (not universally held) that octal...

@lrhn I think this is still on your wishlist, but I don't think we really need this to track the feature do we? Feel free to re-open if you want...