#rust-lang

e.g., prefer exhaustive matches, etc

nox: that was just a quick example... consider a more complicated default value

Then write Default::default()?

trait _ { fn _() -> Self; }

_::_()

nox: This was predicated on repeating Default::default() being annoying

eddyb: -> _ you mean

centril: Annoying to write ≠ bad to have.

anywho... let's get started?

nox: ^

Wait a sec,

sorry r#_

k, i'll go make some tea

isn't there a RFC to write struct with named fields as struct tuples?

Or am I crazy?

nox: like this? struct Foo { bar: usize, baz: u8 } Foo(0, 1) ?

Yeah.

centril: Doesn't matter anyway.

nox: are you in favor of that?

centril: Nah,

aight

I was just wondering if Foo { .. } could be confusing,

don't think so

if it could be written as Foo(..) when the first field is RangeFull,

but Default::default() for RangeFull returns .. anyway so it's not like it would matter.

but it is good to think about

centril: Imma relocate to home (I'm in a café) and then we can discuss the RFC.

Boxing nox in a nox box effing rocks

best rap evar

Now that's my kind of highlights.

Usually being highlighted by my name in technical stuff means someone said a Debian package name that has no X support.

hah

=P

nox is a pretty rhymable nick

and X it's the coolest consonant

s/t'//

the ks sound generally

(well, two)

coolest letter and coolest two consonants

nox, rocks, socks, docks, pox, clocks, box, Xerox, fox, glocks, flocks, locks, detox

Good job avoiding one of them.

nox: what did I avoid? =P

Lalala.

Obviously meant avoiding MOx because nuclear energy is bad.

nox: https://hackmd.io/CwMzFNWBaECYCsBOawBscDM0CGCAM...

centril: "T: Debug" in there requires a different RFC, that's not even currently parsed.

yea but we have to consider it for future compat

centril: I also don't understand what that means in bound,

if bound takes a list of traits that is.

centril: Real world code called, btw.

nox: hmm? =P

centril: I am patching some CSS stuff, just saying I'm not giving you the cold shoulder. :P

nox: ah, np =)

centril: Want me to slim down my stuff using the associated type from a trait?

nox: if you think that is best for understanding =)

centril: Slimmed down: https://play.rust-lang.org/?gist=92141d2ed7ae5f...

centril: It's just a complex enough to show that #[no_bound] is obviously necessary in that case.

-a

nice

centril: And main doesn't actually use NumberOrPercentage because… I can't implement Debug for it.

centril: Oh I guess I should write the impl by hand anyway to show what no_bound+bound should produce.

Recursive was actually a really neat example

since F should not have Debug but B should

centril: Interesting, I just hit a rustc limitation that makes #[bound] etc not help me as much as I would like to minimise the sample. :(

:(

we can discuss it perhaps in a limitations section if you like

centril: https://play.rust-lang.org/?gist=5ace3e63927658...

Grep for XXX

Somehow the type alias (that isn't passed any generic type) isn't resolved there.

interesting

eddyb, nmatsakis: https://play.rust-lang.org/?gist=fe8399c0216537...

Line 36 is equivalent to line 37, but with line 36 it doesn't compile.

centril: This definitely looks like a bug, right?

sec, have to think =P

It chokes with Phase: Phasing<<Specified as Phasing<SpecifiedNumber>>::Output> even though <Specified as Phasing<SpecifiedNumber>>::Output == SpecifiedNumber.

centril: I'm most confused by the fact that it chokes only in the impl and not the enum definition.

1. assume: type Number<Phase> = <Phase as Phasing<SpecifiedNumber>>::Output; , impl<T> Phasing<T> for Specified { type Output = T; } 2. Number<Specified> ==> SpecifiedNumber 3. Phasing<Number<Specified>> == Phasing<SpecifiedNumber>

feels like it should work by simple substitution

Yep.

centril: And that bound is necessary on the enum definition,

so the fact that it doesn't choke there isn't just a matter of trait bounds being ignored on type items or whatever.

Right?

Feels like a bug, but then again, when you say such things someone always comes along and shows that you that you are wrong =P

I've been told nmatsakis is the trait bound master, let's just wait for him to wake up.

This is correct

"Trait bound master",

somehow that reminds me of…

trait bound master vs. bound trait master vs. bound master trait vs. master-bound trait vs. trait-master bound

english is fun

nox: I've been thinking that #[no_bound] should be permitted on fields as well

centril: Why?

nox: scroll to where I am

Oh.

centril: "Bound for all traits, but not those ones?"

nox: it means: "ignore this field when adding bounds to type parameters"

I'm confused.

centril: Ah, if T appears only in fields with #[no_bound], T doesn't get a bound?

exactly

That sounds more complex to implement syntactically,

you now need name resolution.

I would rather we limit ourselves to things that don't require that.

(For now at least.)

sure, you'd need to scan all fields and see if a type parameter is referenced

but we can simplify that with helper crates

the upside is that it reads better in complex cases

centril: Sure, but name resolution is complicated and will get more complicated.

I'm also not sure that type macros are expanded before derive macros,

and type params aren't hygienic.

nox: hmm; let's put this as an unresolved question then?

macro_rules! Foo { () => { T } }

struct Bar<T>(Foo!());

What does that do?

This builds, *wonderful*.

there are proposals that allow derive to type macros at will

to expand type macros*

I'm not sure I parse that correctly.

Oh.

centril: Unresolved it is.

but it could get hairy...

=)

We don't really need the use case for now.

centril: But what do you think of my interpretation btw?

of?

#[bound] #[no_bound(Clone)], with #[derive(PartialEq, Clone, PartialOrd)]

what are the semantics?

centril: Adds a PartialEq + PartialOrd bound for that field type.