Stream: wg-traits

Topic: design meeting 2019.12.16


Jack Huey (Dec 16 2019 at 18:31, on Zulip):

Hey @WG-traits, I think we'll mostly talk associated types and normalization. I've been working on putting down some thoughts on the Hackmd doc. I might add a few more things before the meeting starts, but feel free to add your thoughts :)

Jack Huey (Dec 16 2019 at 18:33, on Zulip):

Additionally, @nikomatsakis if it's okay with you, I would like to spend 5 minutes at the start to talk about the Chalk book and what plans are for that. And 5 or so minutes to talk about the coinduction branch and what is left to push that through

nikomatsakis (Dec 16 2019 at 18:59, on Zulip):

@Jack Huey yeah, that seems fine

nikomatsakis (Dec 16 2019 at 18:59, on Zulip):

Hey @WG-traits, design meeting starting now-ish!

nikomatsakis (Dec 16 2019 at 19:00, on Zulip):

So, we had planned to talk about "lazy normalization strategies" today, but @Jack Huey was mentioning that we could also discuss the Chalk Book (and perhaps a bit about coinduction, although I think maybe detailed discussion of that should wait)

nikomatsakis (Dec 16 2019 at 19:00, on Zulip):

I have also been thinking more about "overall roadmap" and wanted to maybe discuss that a bit, though it fits I think into the chalk book

Jack Huey (Dec 16 2019 at 19:01, on Zulip):

I just wanted to quickly go over chalk book, just because I think it would be good to have some definite ideas of what we're putting in it

Jack Huey (Dec 16 2019 at 19:01, on Zulip):

Considering it would be helpful for others :)

nikomatsakis (Dec 16 2019 at 19:01, on Zulip):

Yeah. I was thinking about it this weekend

nikomatsakis (Dec 16 2019 at 19:02, on Zulip):

in part because I was looking into how to document the plans around types and chalk-ir

Jack Huey (Dec 16 2019 at 19:02, on Zulip):

Coinduction doesn't necessarily need a discussion now. We can talk elsewhere

nikomatsakis (Dec 16 2019 at 19:02, on Zulip):

so, it seems like it should cover a few things

nikomatsakis (Dec 16 2019 at 19:02, on Zulip):
nikomatsakis (Dec 16 2019 at 19:02, on Zulip):
nikomatsakis (Dec 16 2019 at 19:02, on Zulip):
nikomatsakis (Dec 16 2019 at 19:03, on Zulip):

I think a lot of this content exists in the rustc-guide to some extent but should be moved here instead

nikomatsakis (Dec 16 2019 at 19:03, on Zulip):
nikomatsakis (Dec 16 2019 at 19:03, on Zulip):

one thing I'm toying with is how to think about e.g. the roadmap

Jack Huey (Dec 16 2019 at 19:04, on Zulip):

I'm assuming "big ideas" includes the distinction between the crates

nikomatsakis (Dec 16 2019 at 19:04, on Zulip):

I'd like for next year to have some more concrete goals outlined etc, but I'm not sure if stuff like that belongs in the book, or maybe better represented as issues, GH projects, or other such things

nikomatsakis (Dec 16 2019 at 19:04, on Zulip):

I'm assuming "big ideas" includes the distinction between the crates

in fact I started drafting such a chapter

nikomatsakis (Dec 16 2019 at 19:04, on Zulip):

I could see it being pretty useful to start by trying to write a table of contents, actually

detrumi (Dec 16 2019 at 19:05, on Zulip):

A roadmap should only be part of the book if we're fairly certain we're going to follow it

Jack Huey (Dec 16 2019 at 19:05, on Zulip):

I agree. Having a table of contents would also be good if somebody wants to help

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

A roadmap should only be part of the book if we're fairly certain we're going to follow it

agreed. :) I guess I would like to be certain :)

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

I think though that the "milestones" prob dont' belong there

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

but what might belong there

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

is documenting the end state we are shooting for

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

e.g., I could see that we could try to sketch out what we think the types should look like

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

and document that

nikomatsakis (Dec 16 2019 at 19:06, on Zulip):

and then work towards it

detrumi (Dec 16 2019 at 19:07, on Zulip):

Well, ideally there'd be some info on how to see the Chalk representation of an existing program (though of course that doesn't exist yet)

nikomatsakis (Dec 16 2019 at 19:07, on Zulip):

I'm not 100% sure what that means

nikomatsakis (Dec 16 2019 at 19:07, on Zulip):

but I think I agree ;)

nikomatsakis (Dec 16 2019 at 19:07, on Zulip):

e.g., I could see that we could try to sketch out what we think the types should look like

let me clarify what I mean here

nikomatsakis (Dec 16 2019 at 19:08, on Zulip):

I was imagining a diagram like

nikomatsakis (Dec 16 2019 at 19:08, on Zulip):

hmm how to convey :)

nikomatsakis (Dec 16 2019 at 19:08, on Zulip):

kind of two columns, where the left-hand side shows types like TyData<TF> and the right-hand side shows the TypeFamily associated types

nikomatsakis (Dec 16 2019 at 19:08, on Zulip):

trying to show the connections between them

nikomatsakis (Dec 16 2019 at 19:09, on Zulip):

to say "here is how chalk represents types, and these are the 'customization points' that can be used by a type family"

nikomatsakis (Dec 16 2019 at 19:09, on Zulip):

and then talking a bit about how to map rustc types to that

nikomatsakis (Dec 16 2019 at 19:09, on Zulip):

(in a subsection)

nikomatsakis (Dec 16 2019 at 19:09, on Zulip):

this is effectively a "Design proposal" that we can take to the broader team

nikomatsakis (Dec 16 2019 at 19:09, on Zulip):

and it also serves as the kind of documentation of what we are shooting for

nikomatsakis (Dec 16 2019 at 19:10, on Zulip):

Anyway, so as not to use the whole meeting on this,

nikomatsakis (Dec 16 2019 at 19:11, on Zulip):

maybe we should say that a good goal is to create a hackmd and play with a table of contents there?

nikomatsakis (Dec 16 2019 at 19:11, on Zulip):

( and/or a PR )

nikomatsakis (Dec 16 2019 at 19:11, on Zulip):

I gotta figure out a good way to organize all these documents...

nikomatsakis (Dec 16 2019 at 19:11, on Zulip):

chalk-book table of contents draft hackmd

Jack Huey (Dec 16 2019 at 19:11, on Zulip):

sorry, distracted for a bit

Jack Huey (Dec 16 2019 at 19:15, on Zulip):

so normalization and associated types?

nikomatsakis (Dec 16 2019 at 19:16, on Zulip):

yep, sorry, I was updating the hackmd above a bit :)

nikomatsakis (Dec 16 2019 at 19:16, on Zulip):

So...where exactly to start :)

nikomatsakis (Dec 16 2019 at 19:16, on Zulip):

Maybe sketch out what we do now and what some of the problems with it are

nikomatsakis (Dec 16 2019 at 19:17, on Zulip):

Not sure if everybody is familiar who's attending?

nikomatsakis (Dec 16 2019 at 19:17, on Zulip):

(ps, cc @David Barsky if you're around)

nikomatsakis (Dec 16 2019 at 19:18, on Zulip):

In short, we have these two goals, ProjectionEq and Normalize

nikomatsakis (Dec 16 2019 at 19:18, on Zulip):

one of the questions that @Jack Huey has raised is why there are two

nikomatsakis (Dec 16 2019 at 19:18, on Zulip):

to be honest I don't entirely remember, maybe we'll uncover the reason

nikomatsakis (Dec 16 2019 at 19:18, on Zulip):

the idea is that when you have to unify a projection type like <T as Iterator>::Item with some other type X,

nikomatsakis (Dec 16 2019 at 19:19, on Zulip):

you convert that into a goal to be solved, written ProjectionEq(<T as Iterator>::Item = X)

nikomatsakis (Dec 16 2019 at 19:19, on Zulip):

there are exactly two rules by which we can solve such a goal

nikomatsakis (Dec 16 2019 at 19:19, on Zulip):

(both of them created from lowering the trait Iterator definition)

nikomatsakis (Dec 16 2019 at 19:19, on Zulip):
forall<A, B> {
  ProjectionEq(<A as Iterator>::Item = B) :- Normalize(<A as Iterator>::Item -> B)
}
Jack Huey (Dec 16 2019 at 19:19, on Zulip):

ProjectionEq clauses are generated for trait and Normalize clauses are generated for the impls

nikomatsakis (Dec 16 2019 at 19:19, on Zulip):

and

nikomatsakis (Dec 16 2019 at 19:20, on Zulip):
forall<A, B> {
    ProjectionEq(<A as Iterator>::Item = (Iterator::Item)<A>)
}
nikomatsakis (Dec 16 2019 at 19:20, on Zulip):

this last one makes use of the concept of a "projection placeholder", which I denoted here as (Iterator::Item)<A>

nikomatsakis (Dec 16 2019 at 19:20, on Zulip):

the idea is that sometimes you know that there is some Item (say) of an iterator, but you don't know what it is

nikomatsakis (Dec 16 2019 at 19:21, on Zulip):

so e.g. in a case like fn foo<T: Iterator>() { .. }

nikomatsakis (Dec 16 2019 at 19:21, on Zulip):

if you ask "what is T::Item? the answer is just ... T::Item

nikomatsakis (Dec 16 2019 at 19:21, on Zulip):

we can't say anything more specific than that

nikomatsakis (Dec 16 2019 at 19:21, on Zulip):

so yeah the two rules break down into:

nikomatsakis (Dec 16 2019 at 19:22, on Zulip):

one challenge here is that the second rule always applies, even when we have a normalization

nikomatsakis (Dec 16 2019 at 19:22, on Zulip):

that is partly a "consequence" of using a relatively simple logic

nikomatsakis (Dec 16 2019 at 19:22, on Zulip):

i.e., we can say things that are true, but we can't give "preferences" between them

nikomatsakis (Dec 16 2019 at 19:22, on Zulip):

and it's kind of .. complicated to decide when the normalization is better

Jack Huey (Dec 16 2019 at 19:23, on Zulip):

I sort of brought this up in the doc, but we could only generate the placeholder type if there are no impls

nikomatsakis (Dec 16 2019 at 19:23, on Zulip):

well..

nikomatsakis (Dec 16 2019 at 19:23, on Zulip):

but how do you decide if there are no impls? it's not always clear

nikomatsakis (Dec 16 2019 at 19:23, on Zulip):

e.g., consider

Jack Huey (Dec 16 2019 at 19:24, on Zulip):

that conflicts with well-formed goals too

nikomatsakis (Dec 16 2019 at 19:24, on Zulip):
ProjectionEq(<i32 as Foo<?U>>::Bar = V)
nikomatsakis (Dec 16 2019 at 19:24, on Zulip):

now maybe we have an impl impl Foo<u32> for i32

nikomatsakis (Dec 16 2019 at 19:24, on Zulip):

that applies, but it's not required that ?U = u32

nikomatsakis (Dec 16 2019 at 19:25, on Zulip):

there could also be impls (that we can't see, maybe provided by downstream crates) that do impl Foo<SomeOtherType> for i32

nikomatsakis (Dec 16 2019 at 19:25, on Zulip):

there are other problems too

nikomatsakis (Dec 16 2019 at 19:25, on Zulip):

e.g., I debated something like

nikomatsakis (Dec 16 2019 at 19:26, on Zulip):
ProjectionEq(<T as Iterator>::Item = (Iterator::Item)<T>) :-
    not { exists<X> { Normalize(<T as Iterator>::Item -> X) } }
nikomatsakis (Dec 16 2019 at 19:26, on Zulip):

I think this is one way to try to capture the intution you were giving

nikomatsakis (Dec 16 2019 at 19:26, on Zulip):

i.e., you can use the placeholder, but only if we can't normalize

nikomatsakis (Dec 16 2019 at 19:27, on Zulip):

but one tricky part about that is -- sometimes normalizing T::Item might have a cyclic requirement to test whether T::Item is equal to something

nikomatsakis (Dec 16 2019 at 19:27, on Zulip):

this might work out, I guess it's worth spelling out some examples, but it could also lead to negative cycles

nikomatsakis (Dec 16 2019 at 19:28, on Zulip):

(which wouldn't be the end of the world, I actually think they have a ton in common with the mechanisms we are building for coinduction, and we may already have that problem thanks to specialization, as I realized recently)

nikomatsakis (Dec 16 2019 at 19:28, on Zulip):

(Does this all make sense so far?)

nikomatsakis (Dec 16 2019 at 19:31, on Zulip):

I think overall what might be good here is to do a bit more experimentation

nikomatsakis (Dec 16 2019 at 19:32, on Zulip):

Like, I'd like to start expanding this document by trying some of the alternative strategies

nikomatsakis (Dec 16 2019 at 19:32, on Zulip):

and (using rust-analyzer, or whatever means) seeing what happens

nikomatsakis (Dec 16 2019 at 19:32, on Zulip):

I think stepping back it's worth saying what's wrong with current design, I see two problems

nikomatsakis (Dec 16 2019 at 19:32, on Zulip):
nikomatsakis (Dec 16 2019 at 19:33, on Zulip):
nikomatsakis (Dec 16 2019 at 19:33, on Zulip):

in particular, in some cases, it will try to solve problems both with the normalized and placeholder form

nikomatsakis (Dec 16 2019 at 19:33, on Zulip):

and that can be silly

nikomatsakis (Dec 16 2019 at 19:33, on Zulip):

however, if we could solve the first one, we might find the second one is not such a big problem -- and we might be able to attack it in practice quite a bit

Jack Huey (Dec 16 2019 at 19:33, on Zulip):

The experimenting that I've done with my branches have gotten me close

nikomatsakis (Dec 16 2019 at 19:33, on Zulip):

e.g. maybe by eschewing the placeholder in the easy cases

Florian Diebold (Dec 16 2019 at 19:34, on Zulip):

I'd be happy to try out alternative strategies with rust-analyzer btw, I think this problem is responsible for quite a few of the remaining cases where we can't infer types currently

nikomatsakis (Dec 16 2019 at 19:34, on Zulip):

(one nice thing about the current setup is that it is conceptually fairly simple)

nikomatsakis (Dec 16 2019 at 19:34, on Zulip):

The experimenting that I've done with my branches have gotten me close

say a bit more

Jack Huey (Dec 16 2019 at 19:34, on Zulip):

Let me try to put thoughts together

Jack Huey (Dec 16 2019 at 19:35, on Zulip):

So, some things that I've been experimenting with locally:

Jack Huey (Dec 16 2019 at 19:35, on Zulip):

Mentioned this last week a bit, but I think the big thing that my branch does is maintain a sense of "projection"

Jack Huey (Dec 16 2019 at 19:36, on Zulip):

so, for the test in #234

Jack Huey (Dec 16 2019 at 19:36, on Zulip):

The answer is not just u32, it's (Trait1::Type)<S> as u32

Jack Huey (Dec 16 2019 at 19:36, on Zulip):

where the latter means "that projection normalized to u32"

nikomatsakis (Dec 16 2019 at 19:37, on Zulip):

oh, right

Jack Huey (Dec 16 2019 at 19:38, on Zulip):

I've also experimented with removing Normalize and ProjectionEq, which I think is fine. Since really Normalize is only a layer of indirection from ProjectionEq (except for the placeholder, but if we don't use the placeholder, it doesn't serve much use)

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

yeah, I'm not sure what I think about this approach, as I said earlier :)

Jack Huey (Dec 16 2019 at 19:38, on Zulip):

right

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

I don't see much benefit to removing normalize/projection-eq, but also little harm

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

I can see it being useful sometimes

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

to be able to say you just want Normalize

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

i.e., in the monomorphiation phase of the compiler

nikomatsakis (Dec 16 2019 at 19:38, on Zulip):

we want to get the types from impls only

Jack Huey (Dec 16 2019 at 19:39, on Zulip):

I don't think I've tried to test the former changes without removing Normalize yet

Jack Huey (Dec 16 2019 at 19:39, on Zulip):

I guess one design question to think about is what is the "correct" answer for the "With inference variables" case from the Hackmd doc

Jack Huey (Dec 16 2019 at 19:40, on Zulip):

Would we rather have "ambiguous" or ?0 = ^0, ?1 = <?0 as Trait1>::Type

nikomatsakis (Dec 16 2019 at 19:40, on Zulip):

Yeah, so,

nikomatsakis (Dec 16 2019 at 19:40, on Zulip):

this is a good consideration too

Jack Huey (Dec 16 2019 at 19:41, on Zulip):

(or I guess a third answer could be ?0 = ^0, ?1 = ?2

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

I have to check the compiler's current behavior but

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

it definitely guesses sometimes

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

but what it does not presently do

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

though chalk could do it

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

is to handle cases like ProjectionEq(<A as Foo<?B>>::Bar = i32)

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

i.e., maybe knowing the target type

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

would allow us to infer ?B

nikomatsakis (Dec 16 2019 at 19:41, on Zulip):

where you couldn't otherwise

nikomatsakis (Dec 16 2019 at 19:42, on Zulip):

chalk doesn't draw any distinction between the 'role' of the type

nikomatsakis (Dec 16 2019 at 19:42, on Zulip):

but the compiler today does

nikomatsakis (Dec 16 2019 at 19:42, on Zulip):

I guess that's a separate question

Jack Huey (Dec 16 2019 at 19:42, on Zulip):

Can you rephrase that?

nikomatsakis (Dec 16 2019 at 19:43, on Zulip):

Would we rather have "ambiguous" or ?0 = ^0, ?1 = <?0 as Trait1>::Type

as far as this inference goes, I don't see this result as being all that useful (i.e., knowing that it's the projection of something, but not what)

nikomatsakis (Dec 16 2019 at 19:43, on Zulip):

let me try to write out an example

nikomatsakis (Dec 16 2019 at 19:45, on Zulip):
trait Id { type Output; }

impl Id for i32 {
    type Output = i32;
}

impl Id for u32 {
    type Output = u32;
}
nikomatsakis (Dec 16 2019 at 19:45, on Zulip):

Given ProjectionEq(<?X as Id>::Output = i32), can we infer that ?X = i32?

nikomatsakis (Dec 16 2019 at 19:46, on Zulip):

The compiler today cannot

nikomatsakis (Dec 16 2019 at 19:46, on Zulip):

In part because it doesn't use this strategy for handling associated types

nikomatsakis (Dec 16 2019 at 19:46, on Zulip):

It uses a 'normalization' strategy where you just say "for a given projection, what is its normalized form?"

nikomatsakis (Dec 16 2019 at 19:46, on Zulip):

so it only has <?X as Id>::Output at hand

nikomatsakis (Dec 16 2019 at 19:46, on Zulip):

it doesn't know what you want to be equal to

Jack Huey (Dec 16 2019 at 19:47, on Zulip):

Hmm

nikomatsakis (Dec 16 2019 at 19:47, on Zulip):

(from what I understood of "that haskell paper" that I've mentioned, they too took an approach like this, but a different and more iterative one, where they apply normalization strategies repeatedly and in various orders to derive a normalized form for some projection)

nikomatsakis (Dec 16 2019 at 19:47, on Zulip):

it doesn't know what you want to be equal to

however, people have sometimes requested this sort of inference.

nikomatsakis (Dec 16 2019 at 19:48, on Zulip):

(otoh, every time we get smarter, we also make it so that people are more likely to rely on some random pattern that existing impls happen to exhibit)

nikomatsakis (Dec 16 2019 at 19:48, on Zulip):

we could however

nikomatsakis (Dec 16 2019 at 19:48, on Zulip):

easily encode some of these st.. well, easily? maybe easily

nikomatsakis (Dec 16 2019 at 19:48, on Zulip):

I was going to say "easily encode some of these strategies" but I'm not sure how true that is

nikomatsakis (Dec 16 2019 at 19:49, on Zulip):

I guess we could force ourselves to never take the output type into account if we wanted

nikomatsakis (Dec 16 2019 at 19:49, on Zulip):

by tweaking how we canonicalize the goals in such a case

nikomatsakis (Dec 16 2019 at 19:49, on Zulip):

i.e., kind of like truncation, we could force an inference variable

nikomatsakis (Dec 16 2019 at 19:50, on Zulip):

hmm no that wouldn't work :)

nikomatsakis (Dec 16 2019 at 19:50, on Zulip):

anyway, I think this is maybe a secondary consideration.

nikomatsakis (Dec 16 2019 at 19:50, on Zulip):

It uses a 'normalization' strategy where you just say "for a given projection, what is its normalized form?"

what I don't like about this (contra the chalk strategy) is that it's a new fundamental thing

nikomatsakis (Dec 16 2019 at 19:50, on Zulip):

i.e., it's a "function" or something

nikomatsakis (Dec 16 2019 at 19:51, on Zulip):

it also makes cycles harder to reason about

nikomatsakis (Dec 16 2019 at 19:51, on Zulip):

so we're 51 minutes in

Jack Huey (Dec 16 2019 at 19:51, on Zulip):

right

nikomatsakis (Dec 16 2019 at 19:51, on Zulip):

I doubt we'll reach a final answer :)

Jack Huey (Dec 16 2019 at 19:52, on Zulip):

so, this is a difficult problem :)

nikomatsakis (Dec 16 2019 at 19:52, on Zulip):

one thing I wanted to mention: I've been working on some branches of chalk, one of which is trying to make this change:

Jack Huey (Dec 16 2019 at 19:52, on Zulip):

Is there something we're sure about?

nikomatsakis (Dec 16 2019 at 19:52, on Zulip):

which doesn't really change anything fundamental

nikomatsakis (Dec 16 2019 at 19:52, on Zulip):

or really anything at all :)

Jack Huey (Dec 16 2019 at 19:52, on Zulip):

Which branch is that?

nikomatsakis (Dec 16 2019 at 19:52, on Zulip):

it's called "placeholder"

nikomatsakis (Dec 16 2019 at 19:53, on Zulip):

my motivations are rather different

nikomatsakis (Dec 16 2019 at 19:53, on Zulip):

I want to explore an alternative idea for region ifnerence, which requires that I be able to distinguish syntactic from semantic equality,

nikomatsakis (Dec 16 2019 at 19:53, on Zulip):

I also want to solve the problem that we should not request impls with a self type that is some "unnormalized projection"

nikomatsakis (Dec 16 2019 at 19:54, on Zulip):

I am also kind of cleaning up TyData a bit in that branch, which is what had me thinking about documenting the desired "end state" for how types look

Jack Huey (Dec 16 2019 at 19:54, on Zulip):

maybe I should take a look at your PR

Jack Huey (Dec 16 2019 at 19:55, on Zulip):

I just don't know a ton about the direction for the recent TypeFamily and related changes

nikomatsakis (Dec 16 2019 at 19:55, on Zulip):

Is there something we're sure about?

I guess I still kind of feel like I'd like to push a bit harder on the current approach, and in particular I'm curious if we can improve the "aggregator" here to discard some of the duplicates; I guess I should look more at your branch, I remain sort of skeptical about having types that mean "this was the result of normalization" -- in part because I think it'll potentially create duplicate work as well, though I should come up with an example (i.e., if we can derive u32 both via normalization and maybe some other means? not sure if that's realistic) but just in general because it means that types are carrying a kind of "history" with them, versus just their 'meaning'

nikomatsakis (Dec 16 2019 at 19:55, on Zulip):

I just don't know a ton about the direction for the recent TypeFamily and related changes

another reason for me to try and document a full proposal, I guess

Jack Huey (Dec 16 2019 at 19:57, on Zulip):

yeah, I understand the concern with having the "history" of the type in them

nikomatsakis (Dec 16 2019 at 19:57, on Zulip):

maybe what we can say for sure is that there are a few directions we can explore:

nikomatsakis (Dec 16 2019 at 19:57, on Zulip):
nikomatsakis (Dec 16 2019 at 19:57, on Zulip):
nikomatsakis (Dec 16 2019 at 19:57, on Zulip):
nikomatsakis (Dec 16 2019 at 19:57, on Zulip):

the last one may lead to more floundering

nikomatsakis (Dec 16 2019 at 19:57, on Zulip):

but that might be ok

nikomatsakis (Dec 16 2019 at 19:58, on Zulip):

those all seem pretty "actionable"

nikomatsakis (Dec 16 2019 at 19:58, on Zulip):

(I also plan to do a bit of "reaching out" to some folks who may have suggestions for related work to follow up on)

Jack Huey (Dec 16 2019 at 19:58, on Zulip):

I think the aggregator/antiunifier could definitely be improved

Jack Huey (Dec 16 2019 at 19:59, on Zulip):

the not might be the easiest to try

Jack Huey (Dec 16 2019 at 20:01, on Zulip):

I'll also work a bit on my branch(es) and see if I can get all the tests to pass

nikomatsakis (Dec 16 2019 at 20:01, on Zulip):

I think it is the easiest to try

Jack Huey (Dec 16 2019 at 20:02, on Zulip):

I think I'm close, but we'll see

David Barsky (Dec 16 2019 at 20:21, on Zulip):

Hello, sorry for missing this. Is there a Google Calendar (or whatever) that I can subscribe to I can be present for these going forward?

Jack Huey (Dec 16 2019 at 20:21, on Zulip):

I think there is a calendar invite link in the wg-traits repo

Jack Huey (Dec 16 2019 at 20:21, on Zulip):

But it's every Monday at 2PM EST

Jack Huey (Dec 16 2019 at 20:22, on Zulip):

https://calendar.google.com/calendar/r/eventedit/copy/MnFmbmdkaGV0aXE3Zjc4cjlpNWVjNDRoZXMgNnU1cnJ0Y2U2bHJ0djA3cGZpM2RhbWdqdXNAZw/amFja2g3MjZAZ21haWwuY29t?sf=true

David Barsky (Dec 16 2019 at 21:19, on Zulip):

Thanks very much!

nikomatsakis (Dec 16 2019 at 21:35, on Zulip):

@David Barsky I can invite you if you like

David Barsky (Dec 16 2019 at 21:41, on Zulip):

@nikomatsakis that'd be handy! You should have my email on file :)

Last update: Jun 07 2020 at 10:35UTC