#rust-lang

if they had anything like modules in mind ADL would not have made a lot of sense

oh god ADL

I think everyone uses them a little like a module system

it doesn't make a lot of sense to have your namespaces and your modules be completely unrelated to each other

I actually read up on all the rules one night trying to figure out just how hard parsing C++ would be

lol

eddyb: ADL isn't related to any parsing problems

scott: parsing depends on types

are you saying ADL is late-bound?

"in some other languages the notion of a private namespace doesn’t really exist" oh yeah, I think that's another thing that confused me but I never really got this pointed out explicitly

in most languages it's *items* that are public or private, never modules/packages/namespaces

eddyb: it might be incidentally related in the sense that any type checking is, but it's not directly related

scott: right no that's what I meant

scott: I was looking at everything that can affect it

(there are even crazier rules around templates so that you can parse them before monomorphization :P)

ADL was just one stop on the crazy train

I was about to say, I thought the template "typename" thing was the main reason you can't parse C++ at all without building a symbol table

I don't work on compilers lol

what do you use?

Ixrec: you need that stuff to parse C and C++ without templates, even

Ixrec: it's just ancient terminology

you have something more akin to a module tree

C++ templates have keywords to disambiguate because otherwise parsing the polymorphic code would be impossible

(think tree of name tables or something)

yeah, that makes more sense

I just assumed the symbol tree was using those hideous fully-qualified names you see in the error messages

anyway, my conclusion was that you can't keep all the rules in your head unless you're the kind of person trained to build rube goldberg contraptions from memory

Ixrec: oh god no

lol

a::b::c is never anything other than syntax for ['a', 'b', 'c']

even in C++?

or ((a)::b)::c, depending how you design your system

(I did assume that was the case in Rust)

Ixrec: well yeah

nothing uses the stringification of a path

I'm not sure about C++ but in Rust a, b, c and the :: between them are all distinct tokens and can thus have any number of spaces between them

C++ should be the same except who knows

I don't know for sure but I think they aren't

Ixrec: https://ideone.com/EHAYW1

I was shocked the first time someone pointed out that Rust allows that

Ixrec: again, a path is just syntax

oh, ok then

this is obvious if you think about how it allows parameters

it can't be a monolithic thing

parameters?

Vec::<T>::new()

this is valid syntax in Rust and C++ has several equivalents

hmm let me a bit clearer

std::vec::Vec::<T>::new desugars to <std::vec::Vec<T>>::new

one path with 3 identifiers and one type-dependent associated item lookup (which is always <Type>::identifier)

okay, I *think* that's how I was parsing the symbol in Rust before

C++ has more complicated Rules but they are based on individual components

where's the original internals thread corresponding to woboat's "The Rust module system is too confusing" post? I can only find the new lang-team-minutes thread

Ixrec: not sure tbh, but there might be a usable search function

I've tried, no luck with it so far

usually it's really good

they call it "scope resolution operator"

I was thinking earlier "it really is just an operator" when you pointed out the whitespace thing

my head hurts

it's not an expression or type operator but yeah

"The following Unicode character ranges are allowed in identifiers:" whaaaat

lol

scott: did you know about this?

I may be subscribed to the entire Rust repo on purpose, but I don't think I'm gonna read that much detail on C++ lookup

oh, in less flame war-y news

it's finally possible to run "cargo build" at my company!