#rust-lang

/

      • woboats
        centril: no doubt its *possible* to have a different resolution algorithm for methods
      • centril
        woboats: so I already think it isn't that intuitive, given traits, which are based on scope and type
      • woboats
        centril: I'd rather postpone this conversation
      • centril
        woboats: I'm saying more than that; I'm saying that it would be a good idea to make method syntax work for free functions; and then you can also allow: foo.path::to::fun(args..) and foo.<Type as Trait>::method(args..);
      • woboats: alright :)
      • woboats
        right, I think that's not a good idea
      • sunjay has quit
      • and I don't think we have bandwidth to hash that out in our current phase
      • so your UMMS and the postfix macro RFCs should be postponed, in my personal opinion
      • *RFC, I know UMMS isn't an RFC
      • centril
        woboats: postponement seems reasonable :)
      • cramertj
        woboats: I really just liked the idea of getting stable postfix type ascription so we could settle that once and for all
      • centril
        cramertj: ehhehe :P I think type ascription deserves better syntax than that
      • cramertj
        .type(String) seems pretty decent to me
      • I guess w/ the macro rfc it'd be `.type!(String)`
      • it's just in that awkward "this is like nothing else in the language" zone
      • centril
        cramertj: I guess it is not too shabby, but Personally, expr : Ty warms my heart; but it has some problems?
      • (technical problems...)
      • cramertj
        it just conflicts with so many things
      • centril
        cramertj: hmm, I thought it was a rather limited list of things it conflicts with?
      • I know 'pat : ty' doesn't work because it is interpreted as 'pat : binding' (this would not work for .type!(..) either?). Then we also have MyType { field: Type } in which for literals 'Type' is also interpreted as a binding and the same is true for patterns... but { expr : type } should work
      • the syntax MyType { field: field: Type } could work but is kinda weird..
      • varkor
        centril: it’s also really confusing
      • because common types like u32 are not reserved keywords
      • centril
        varkor: what's confusing? MyType { field: field: Type } ?
      • varkor
        centril: yes, because someone’s going to forget the extra : and wonder why field: u32 isn’t working
      • (well, the error would make it clear, but even then, it’s not very intuitive)
      • centril
        varkor: right; it's pretty unfortunate... tho field: value / field: binding is really the culprit here
      • varkor
        yeah
      • centril
        should have been field = value
      • varkor: any ideas for alternative syntax re. field : type => ?
      • cramertj: btw, what are the plans re. existential type Type: Trait; ?
      • woboats
        i dont think type ascription is worth the trouble
      • varkor
        centril: personally, I’d be happy with any other syntax — the issue is that it’s not backwards compatible to change now, so it’s not feasibly going to be changed
      • centril
        woboats: how come?
      • woboats
        if it were easy, sure why not have it
      • but since syntactically its difficult
      • its just not worth it
      • i have felt like darnit i wish i had type ascription exactly 0 times
      • centril
        woboats: I suppose; however the workaround with let-bindings is worse than the cure for people who like more pointfree code :)
      • (or "pointless" ^,-)
      • woboats
        oh well
      • letting you write point free code when it would be type ambiguous without a type annotation is not worth the amount of time we have already put into it
      • centril
        woboats: I'm happy with .type!(Foo) as a substitute :)
      • woboats
        but we have other reasons not to do that
      • varkor
        this is the same issue that’s blocking (x: u32, y: u32) instead of (x, y): (u32, u32), isn’t it?
      • maybe a slightly more restricted version works for tuple patterns, but not in general
      • centril
        woboats: sure
      • varkor has quit
      • keeper has quit
      • keeper joined the channel
      • keeper has quit
      • keeper joined the channel
      • Ericson2314 has quit
      • Zoxc joined the channel
      • Noldorin joined the channel
      • Noldorin
        rkruppe, actually it's the semantics causing a lot of the concerns
      • regarding method-like dispatch, etc.
      • emerentius has quit
      • emerentius joined the channel
      • cp joined the channel
      • WindowsBunny1 joined the channel
      • WindowsBunny has quit
      • PeterRabbit has quit
      • PeterRabbit joined the channel
      • WindowsBunny1 is now known as
      • Noldorin has quit
      • psychoslave_ joined the channel
      • netrino joined the channel
      • psychoslave_ has quit
      • psychoslave joined the channel
      • scott
        centril: .type!(Foo), if we can make it work nicely, is actually a lot nicer in a certain way. e.g. i can do `foo.iter().map(...).collect().type!(T).bar()` without any whole-chain-wrapping parens. this was a problem with try!(), is with async, and would be with `x: T`
      • it's also a problem with `x as T` although i'm unsure whether people run into that in practice
      • given the ability to define .foo!() macros, a user could just define .as!(T) themselves anyway
      • emerentius has quit
      • eddyb
        scott: except for as being a keyword :P
      • scott
        oh yeah oops
      • eddyb
        woboats: heh, the variadic thing is probably from reusing FnDecl between `extern` FFI import declarations and regular function definitions
      • we actually are in the process of implementing defining FFI-variadic Rust functions, so that's exciting :D
      • I don't even know what the RFC chose for syntax
      • nagisa joined the channel
      • psychoslave has quit
      • psychoslave joined the channel
      • skeuomorf joined the channel
      • nagisa has quit
      • AstralSorcerer has quit
      • nagisa joined the channel
      • nagisa has quit
      • chill joined the channel
      • varkor joined the channel
      • fabiim joined the channel
      • varkor has quit
      • nagisa_m joined the channel
      • skeuomorf has quit
      • kennytm has quit
      • netrino has quit
      • netrino joined the channel
      • nagisa__m joined the channel
      • nagisa_m has quit
      • nagisa__m has quit
      • cp has quit
      • WindowsBunny1 joined the channel
      • PeterRabbit has quit
      • PeterRabbit joined the channel
      • WindowsBunny1 is now known as
      • Zoxc
        eddyb: Is that another Rust discord?