Stream: wg-traits

Topic: meeting 2019-03-18


nikomatsakis (Mar 18 2019 at 18:00, on Zulip):

Hey @WG-traits -- meeting soon?

nikomatsakis (Mar 18 2019 at 18:00, on Zulip):

Our goal for this meeting was to setup some sprint-like goals

nikomatsakis (Mar 18 2019 at 18:03, on Zulip):

Maybe a good start to try and enumerate the projects for which we might setup goals. I feel like our current projects have been

nikomatsakis (Mar 18 2019 at 18:06, on Zulip):

Don't all speak up at once ;)

Aaron Turon (Mar 18 2019 at 18:06, on Zulip):

hahaha, wasn't clear that you wanted us to speak yet :P

nikomatsakis (Mar 18 2019 at 18:06, on Zulip):

Yeah, I know :P

nikomatsakis (Mar 18 2019 at 18:06, on Zulip):

I guess the first question is -- am I forgetting things :)

Aaron Turon (Mar 18 2019 at 18:06, on Zulip):

that list seems to cover all the topics, but personally i am perpetually a bit confused as to how GATs, chalks + rustc, and lazy norm relate

Aaron Turon (Mar 18 2019 at 18:07, on Zulip):

that is, i think it's possible that they are all the "same" project

nikomatsakis (Mar 18 2019 at 18:07, on Zulip):

well, that's part of what we're here today to discuss

nikomatsakis (Mar 18 2019 at 18:07, on Zulip):

that is, i think it's possible that they are all the "same" project

correct

nikomatsakis (Mar 18 2019 at 18:07, on Zulip):

they could be

tmandry (Mar 18 2019 at 18:07, on Zulip):

chalk/RLS integration is another thing, but not sure if that's under this wg at all

nikomatsakis (Mar 18 2019 at 18:07, on Zulip):

I put it on the list, I definitely think it's under this WG

nikomatsakis (Mar 18 2019 at 18:07, on Zulip):

I mean it may be a joint effort :)

tmandry (Mar 18 2019 at 18:08, on Zulip):

oh it's there, that's what I get for not drinking coffee

Sunjay Varma (Mar 18 2019 at 18:08, on Zulip):

There was a task in a document somewhere you asked me if I was interested in. Is that encompassed in that list?

nikomatsakis (Mar 18 2019 at 18:08, on Zulip):

I guess I think this is maybe the core-most decision at this moment -- I see two options:

1. To do some work on rustc's existing solver and pursuing integrating chalk in a RLS 2.0 context
2. To try integrating chalk into rustc and let the rest of the work fall from that

nikomatsakis (Mar 18 2019 at 18:08, on Zulip):

There was a task in a document somewhere you asked me if I was interested in. Is that encompassed in that list?

Yes, that part of the RLS 2.0 thoughts

nikomatsakis (Mar 18 2019 at 18:08, on Zulip):

and I guess that reminds me that there are a few other goals that could be on the list, e.g. pursuing more design-based intitiatives

centril (Mar 18 2019 at 18:09, on Zulip):

:wave:

nikomatsakis (Mar 18 2019 at 18:09, on Zulip):

e.g., modeling specialization in chalk etc

Aaron Turon (Mar 18 2019 at 18:09, on Zulip):

@nikomatsakis so it seems like the main reason not to just pack everything into "chalk integration" is that we see shorter paths to other desirable things, e.g. const generics and GATs

nikomatsakis (Mar 18 2019 at 18:10, on Zulip):

seems correct

Aaron Turon (Mar 18 2019 at 18:10, on Zulip):

maybe we should start by digging into that a bit?

nikomatsakis (Mar 18 2019 at 18:10, on Zulip):

Yes, I was going to suggest we talk a bit about GATs to start

nikomatsakis (Mar 18 2019 at 18:10, on Zulip):

I looked over the set of use cases some

centril (Mar 18 2019 at 18:11, on Zulip):

@nikomatsakis Update re. associated type bounds: @Alexander Regueiro has been working on it, particularly the tests I made; we discuss it regularly on Discord.

nikomatsakis (Mar 18 2019 at 18:11, on Zulip):

I think that it would... probably be relatively easy to support the "internal iterator" use case

trait Iterator {
    type Item<'a> where Self: 'a;
    fn next<'a>(&'a mut self) -> Self::Item<'a>;
}
nikomatsakis (Mar 18 2019 at 18:11, on Zulip):

but it's probably talking that through in a bit more detail to convince ourselves

nikomatsakis (Mar 18 2019 at 18:12, on Zulip):

I think that it would... probably be relatively easy to support the "internal iterator" use case

I've usually thought of this as more "iterable", but I guess it covers a number of patterns

centril (Mar 18 2019 at 18:12, on Zulip):

(btw, when I wrote some of the GAT cases I assumed Sized would be easy to handle as a special case... ^^)

Aaron Turon (Mar 18 2019 at 18:12, on Zulip):

yes, including a number of cases in the async world (where this pattern is needed any time you abstract over async fns that borrow)

nikomatsakis (Mar 18 2019 at 18:13, on Zulip):

To start, we would have to fix various things in the normalization code -- right now we sort of hard-code that an associated type looks like <P0 as Trait<P1..Pn>>::Foo -- i.e., that the set of parameters on associated type definition is the same as the set from the trait

nikomatsakis (Mar 18 2019 at 18:13, on Zulip):

I think this should be relatively easy

nikomatsakis (Mar 18 2019 at 18:13, on Zulip):

@Sunjay Varma did some of that groundwork already

nikomatsakis (Mar 18 2019 at 18:14, on Zulip):

In particular, IIRC, we now have the def-id available of the associated type itself

nikomatsakis (Mar 18 2019 at 18:15, on Zulip):

I guess the next part would be that we have to handle the bounds

nikomatsakis (Mar 18 2019 at 18:16, on Zulip):

which is actually .. hmm .. kind of interesting :)

centril (Mar 18 2019 at 18:16, on Zulip):

@nikomatsakis by bounds, do you mean both on the associated type itself and its parameters?

nikomatsakis (Mar 18 2019 at 18:16, on Zulip):

so in general if you have type Foo<'a>: Bounds that is equivalent to a where clause on the trait like

for<'a> {
    <Self as Trait>::Foo<'a>: Bounds
}
nikomatsakis (Mar 18 2019 at 18:17, on Zulip):

nikomatsakis by bounds, do you mean both on the associated type itself and its parameters?

well, sort of both -- we have that where Self: 'a, for example

nikomatsakis (Mar 18 2019 at 18:17, on Zulip):

it's actually a kind of subtle point

centril (Mar 18 2019 at 18:18, on Zulip):

Right; that's a bound that must be proven on use rather than in the impl

nikomatsakis (Mar 18 2019 at 18:18, on Zulip):

we should should come up with two distinct terms

nikomatsakis (Mar 18 2019 at 18:18, on Zulip):

Is the distinction we're talking about clear to everyone? I sort of doubt it :)

centril (Mar 18 2019 at 18:19, on Zulip):

@nikomatsakis maybe crystallize the distinction by example?

nikomatsakis (Mar 18 2019 at 18:19, on Zulip):

Consider these two Debug bounds:

trait Foo {
    type Bar<T: Debug>: Debug
}
nikomatsakis (Mar 18 2019 at 18:19, on Zulip):

If I have:

impl Foo for MyType {
    type Bar<T: Debug> = Vec<T>;
}
nikomatsakis (Mar 18 2019 at 18:19, on Zulip):

you can see that I included one of those bounds (the T: Debug) but not the other

nikomatsakis (Mar 18 2019 at 18:20, on Zulip):

this is because the impl gets to assume that T: Debug will hold (and whoever "uses" the associated type must in turn prove it), but the impl must prove that Self::Bar<T>: Debug (assuming that T: Debug)

nikomatsakis (Mar 18 2019 at 18:20, on Zulip):

let's call the T: Debug bound a "condition" and the other a "requirement", I guess

nikomatsakis (Mar 18 2019 at 18:20, on Zulip):

for now?

nikomatsakis (Mar 18 2019 at 18:21, on Zulip):

(unless someone has a better suggestion)

Taylor Cramer (Mar 18 2019 at 18:21, on Zulip):

and where clauses are... both?

nikomatsakis (Mar 18 2019 at 18:21, on Zulip):

well, that's a question. I think they are conditions

Sunjay Varma (Mar 18 2019 at 18:21, on Zulip):

Right. So if I had a type Qxx<T> that is always Debug regardless of T, I could omit the T: Debug entirely?

nikomatsakis (Mar 18 2019 at 18:21, on Zulip):

because type Bar<T: Debug> and type Bar<T> where T: Debug should be equivalent

nikomatsakis (Mar 18 2019 at 18:21, on Zulip):

and requirements can always be moved to the trait anyhow

nikomatsakis (Mar 18 2019 at 18:22, on Zulip):

but to some extent we're bikeshedding here (though it's a good thing to discuss)

nikomatsakis (Mar 18 2019 at 18:22, on Zulip):

that is, in terms of how the compiler works, we can assume some separation

tmandry (Mar 18 2019 at 18:22, on Zulip):

no I think it's actually very good to have two terms IMO

centril (Mar 18 2019 at 18:22, on Zulip):
trait Foo {
    type Bar<T: Alpha>: Beta;
}

should be equivalent to:

trait Foo where <Self as Foo>::Bar: Beta {
    type Bar<T> where T: Alpha;
}
nikomatsakis (Mar 18 2019 at 18:22, on Zulip):

but to some extent we're bikeshedding here (though it's a good thing to discuss)

sorry, I didn't mean we were bikeshedding with the terms. I meant debating how the syntax maps to the terms is mildly bikeshedding. But we should probably still discuss it. =)

nikomatsakis (Mar 18 2019 at 18:23, on Zulip):

Right, and when we talk in the "chalk lowering", we usually talk about two sets of where clauses -- one on the trait ("the requirements") and one on the associated type ("the conditions")

nikomatsakis (Mar 18 2019 at 18:23, on Zulip):

So basically what @centril said

nikomatsakis (Mar 18 2019 at 18:23, on Zulip):

Right. So if I had a type Qxx<T> that is always Debug regardless of T, I could omit the T: Debug entirely?

correct @Sunjay Varma

centril (Mar 18 2019 at 18:24, on Zulip):

@nikomatsakis I would call one "use bounds/constraints" and the other "implementation bounds/constraints"

centril (Mar 18 2019 at 18:24, on Zulip):

based on where it has to be proven

Taylor Cramer (Mar 18 2019 at 18:24, on Zulip):

@centril w/ the caveat that different associated types may only be available when different constraints are satisfied, yes?

centril (Mar 18 2019 at 18:24, on Zulip):

@Taylor Cramer right, as with methods

centril (Mar 18 2019 at 18:25, on Zulip):

(e.g. think where Self: Sized)

Taylor Cramer (Mar 18 2019 at 18:25, on Zulip):

@centril yeah, just clarifying because that's not actually the case today, although I think that's a bug

nikomatsakis (Mar 18 2019 at 18:25, on Zulip):

so-- it's not easy for the compiler's current infrastructure to be scaled to include "use bounds or constraints".

nikomatsakis (Mar 18 2019 at 18:25, on Zulip):

this is a place where chalk is much stronger

nikomatsakis (Mar 18 2019 at 18:25, on Zulip):

(adopting @centril's terminology)

Taylor Cramer (Mar 18 2019 at 18:25, on Zulip):

@centril see https://github.com/rust-lang/rust/issues/57900

nikomatsakis (Mar 18 2019 at 18:26, on Zulip):

so-- it's not easy for the compiler's current infrastructure to be scaled to include "use bounds or constraints".

to make this more concrete: what a "use bound" means to us that we have to be able to adjust the "surrounding environment" as we prove various subgoals. e.g., if we have for<T: Debug> { Vec<T>: Debug }, we would need to (a) introduce a type parameter T and (b) add the assumption that T: Debug. Neither of these things is the compiler very good at, but the latter is particularly hard :)

nikomatsakis (Mar 18 2019 at 18:27, on Zulip):

which reminds me, @Aaron Turon, another thing which we were investigating but sort of dropped was the matter of universe integration and lifetimes

nikomatsakis (Mar 18 2019 at 18:27, on Zulip):

and us deciding how we felt about that :)

centril (Mar 18 2019 at 18:27, on Zulip):

(for those familiar with Haskell, this is the distinction between:

class Beta self => Foo self where
    delta :: Int
    gamma :: Alpha self => self -> Bool

)

Aaron Turon (Mar 18 2019 at 18:29, on Zulip):

@nikomatsakis so to bring this back to use-cases: i think that GATs document shows that we can get a lot of mileage out of just "impl bounds"

nikomatsakis (Mar 18 2019 at 18:29, on Zulip):

To come back to the iterable example, I was thinking that it didn't require us to solve so-called "use bounds", but I guess that's not really true. That is, the example was

trait Iterable {
    type Iter<'a> where Self: 'a;
}

that where clause is a "use bound".

nikomatsakis (Mar 18 2019 at 18:30, on Zulip):

so to bring this back to use-cases: i think that GATs document shows that we can get a lot of mileage out of just "impl bounds"

well, that's what I was debating, but I'm not entirely sure.

nikomatsakis (Mar 18 2019 at 18:30, on Zulip):

Let me see if I'm confusing myself :)

Aaron Turon (Mar 18 2019 at 18:30, on Zulip):

to be clear i was thinking of the async cases, not iterable

centril (Mar 18 2019 at 18:30, on Zulip):

@nikomatsakis can we "hack" simpler use-bounds & get away with it?

Aaron Turon (Mar 18 2019 at 18:30, on Zulip):

though @Taylor Cramer points out in comments that what i initially wrote for those is probably naive in a few ways

nikomatsakis (Mar 18 2019 at 18:31, on Zulip):

the problem with this where Self: 'a thing, where that comes from, is that you probably want something like

impl<T> Iterable for Vec<T> {
    type Iter<'a> = vec::Iter<'a, T>;
    // requires that T: 'a to be WF.. but how do we know that?
}
nikomatsakis (Mar 18 2019 at 18:31, on Zulip):

to be clear i was thinking of the async cases, not iterable

yeah, I sort of shifted it, but i'm not sure if it matters?

nikomatsakis (Mar 18 2019 at 18:31, on Zulip):

The key part being the comment "requires that T: 'a to be WF.. but how do we know that?" -- the idea would be that we know it because we get to assume that Self: 'a -- i.e., Vec<T>: 'a, which in turn implies T: 'a (we do this sort of deduction today)

nikomatsakis (Mar 18 2019 at 18:32, on Zulip):

can we "hack" simpler use-bounds & get away with it?

maybe, lifetime bounds of this kind are handled kind of "differently"

nikomatsakis (Mar 18 2019 at 18:33, on Zulip):

let's assume we could handle the where self: 'a case

nikomatsakis (Mar 18 2019 at 18:33, on Zulip):

I think we can generally handle proving the "impl bounds" -- we already prove for<'a> sort of things today

Aaron Turon (Mar 18 2019 at 18:34, on Zulip):

@nikomatsakis to clarify, i was thinking of cases like:

trait AsyncFoo {
    type Fut<'a>: Future<Output = Bar>;
    fn foo<'a>(&'a self) -> Self::Fut<'a>;
}
nikomatsakis (Mar 18 2019 at 18:34, on Zulip):

and similarly, we should be able to handle the other side where we rely on them as clauses

nikomatsakis (Mar 18 2019 at 18:35, on Zulip):

yeah, so my belief is that the major challenge to supporting (a limited version of) GATs in the compiler today is dealing with the where Self: 'a business. This limited version would probably by something like "one lifetime parameter without any other use bounds but Self: 'a".

nikomatsakis (Mar 18 2019 at 18:35, on Zulip):

maybe we should look a bit at the other things -- notably chalk integration questions -- and come back to what this means for GATs then?

centril (Mar 18 2019 at 18:36, on Zulip):

@Aaron Turon so in this case do we infer where Self: 'a from foo's definition?

Aaron Turon (Mar 18 2019 at 18:36, on Zulip):

@nikomatsakis so i'm kinda slow today, can you spell out whether this WF issue arises with cases like AsyncFoo?

nikomatsakis (Mar 18 2019 at 18:36, on Zulip):

ps I'm not wild about "impl bounds" as the terminology, since (in desugared form) they are where-clauses that appear on the trait (but are proven at the impl)

nikomatsakis (Mar 18 2019 at 18:36, on Zulip):

I imagine it would @Aaron Turon -- let's look at a possible impl

centril (Mar 18 2019 at 18:37, on Zulip):

@nikomatsakis yea I had to stop to think on that one for a bit... happy about changing it to "trait bounds" or something else ;)

centril (Mar 18 2019 at 18:37, on Zulip):

"use bounds" was from the POV of where things are proven tho, so it is internally consistent at least ^^

nikomatsakis (Mar 18 2019 at 18:37, on Zulip):
impl<T> AsyncFoo for MyType<T> {
    type Fut<'a> = /* ... the key question is if this type involves a `&'a T` ... */
}
Taylor Cramer (Mar 18 2019 at 18:37, on Zulip):

@Aaron Turon yes, it would, because the type implementing AsyncFoo might not be 'static

Taylor Cramer (Mar 18 2019 at 18:38, on Zulip):

So type Fut<'a> needs to only be valid so long as 'a doesn't outlive the Self type

nikomatsakis (Mar 18 2019 at 18:39, on Zulip):

put another way, the 'a lifetime represents (logically) "the lifetime of a reference to Self" in practice, and we will likely want to rely on that

Aaron Turon (Mar 18 2019 at 18:39, on Zulip):

would it be possible to restrict use to only 'static Self types? i guess i'm looking for whether there's a minimal case that allows us to abstract over async functions that take in borrowed data

centril (Mar 18 2019 at 18:39, on Zulip):

@Aaron Turon so &'a self ==> self: &'a Self ==> Self: 'a because of &'a X => X: 'a

nikomatsakis (Mar 18 2019 at 18:39, on Zulip):

well that's certainly a first step, good point

Aaron Turon (Mar 18 2019 at 18:39, on Zulip):

(though if we think we can "hack in" the Self: 'a support maybe it's not relevant)

nikomatsakis (Mar 18 2019 at 18:40, on Zulip):

i.e., we could do all the rest of the work, and it would just error out for cases that are not 'static

nikomatsakis (Mar 18 2019 at 18:40, on Zulip):

i.e., if it didn't get to take a where Self: 'a into account

Aaron Turon (Mar 18 2019 at 18:40, on Zulip):

yeah... maybe too hacky to be worth it, idk

nikomatsakis (Mar 18 2019 at 18:40, on Zulip):

well, it might make a decent "sprint goal"

nikomatsakis (Mar 18 2019 at 18:40, on Zulip):

otoh I think most use cases really want that

nikomatsakis (Mar 18 2019 at 18:40, on Zulip):

that is, sort of the whole point of this is to employ the 'a :)

nikomatsakis (Mar 18 2019 at 18:41, on Zulip):

(well, I guess it's not that you can't employ it at all)

nikomatsakis (Mar 18 2019 at 18:41, on Zulip):

the real question is not whether your proposal is too hacky @Aaron Turon -- it's whether fixing this will be too hacky

nikomatsakis (Mar 18 2019 at 18:41, on Zulip):

i.e., I think if we just did a "subset" of the impl steps, we would find it working ok for 'static types but not for others

Aaron Turon (Mar 18 2019 at 18:41, on Zulip):

heh yeah -- i was going to raise the question of whether it's feasible to stabilize anything here prior to chalk integration

Aaron Turon (Mar 18 2019 at 18:42, on Zulip):

(or whether we'd be too worried that the behavior might change)

nikomatsakis (Mar 18 2019 at 18:42, on Zulip):

I guess it's a bit early to say

nikomatsakis (Mar 18 2019 at 18:42, on Zulip):

I feel like we could test the behavior, it'd be more a question of impl quality probably

Aaron Turon (Mar 18 2019 at 18:42, on Zulip):

it's sort of another dimension in all this: when we talk about "shorter path" to unblock other things, do we mean on nightly or stable?

nikomatsakis (Mar 18 2019 at 18:42, on Zulip):

yeah

nikomatsakis (Mar 18 2019 at 18:43, on Zulip):

I am sensing we are not going to get to "sprint goals" this week :)

nikomatsakis (Mar 18 2019 at 18:43, on Zulip):

but I think that' sok

nikomatsakis (Mar 18 2019 at 18:44, on Zulip):

I had hoped to sort of have this conversation earlier but it's good we're having it now

Aaron Turon (Mar 18 2019 at 18:44, on Zulip):

@Taylor Cramer for your cases in Fuchsia, is it fair to say that this won't get you very far without supporting all the kinds of bounds?

Aaron Turon (Mar 18 2019 at 18:44, on Zulip):

I am sensing we are not going to get to "sprint goals" this week :)

we could always book an additional meeting

centril (Mar 18 2019 at 18:44, on Zulip):

I think we should be careful tho with 'static because if you only impose 'staticon uses then ostensibly impls get to assume that you haven't imposed anything more so they can say type Foo<'a> = Type; where Type only works for 'static.

centril (Mar 18 2019 at 18:45, on Zulip):

@nikomatsakis btw... update for meeting notes: re. for<'a: 'b> and such, I haven't done any work yet; busy with let_chains.

Aaron Turon (Mar 18 2019 at 18:46, on Zulip):

@nikomatsakis i think for GATs i'm increasingly of the mind that this "shorter path" vision won't be enough to really make an impact

nikomatsakis (Mar 18 2019 at 18:46, on Zulip):

let me see if I can summarize what we've said so far:

Taylor Cramer (Mar 18 2019 at 18:46, on Zulip):

@Aaron Turon We could certainly get by with the 'static restriction-- it'd just mean some extra Rc/Arc boilerplate

Aaron Turon (Mar 18 2019 at 18:47, on Zulip):

@Taylor Cramer do you feel like it's worth sprinting toward that on nightly, vs putting the effort into chalk integration?

nikomatsakis (Mar 18 2019 at 18:47, on Zulip):

I think for GATs i'm increasingly of the mind that this "shorter path" vision won't be enough to really make an impact

Interesting. I was kind of coming to the opposite conclusion. I guess it depends a lot about the where Self: 'a case-- whether we can handle that or not

nikomatsakis (Mar 18 2019 at 18:47, on Zulip):

But also I think we can't answer this question without talking about chalk integration

nikomatsakis (Mar 18 2019 at 18:47, on Zulip):

and what that means / what difficulties we foresee

nikomatsakis (Mar 18 2019 at 18:48, on Zulip):

well we could if we felt like our needs were significantly greater than the type Iter<'a> case outlined above

Taylor Cramer (Mar 18 2019 at 18:48, on Zulip):

@Aaron Turon Hm, I think I'd be more interested in seeing how it affects the rest of the ecosystem rather than Fuchsia specifically, in part because we've already gotten used to modeling things so differently as a result of not being able to write async fn in traits today

Aaron Turon (Mar 18 2019 at 18:48, on Zulip):

@nikomatsakis i think where it's coming from for me is that we're just "moving the cliff" rather than eliminating it. that is, you'd be able to do more, but then might be even more stuck when you hit the next cliff

Alexander Regueiro (Mar 18 2019 at 18:49, on Zulip):

hi.

Taylor Cramer (Mar 18 2019 at 18:49, on Zulip):

For example, how disruptive it would be to people using the various bits of tower-service-related stuff, tide, hyper, etc.

Alexander Regueiro (Mar 18 2019 at 18:49, on Zulip):

I had assumed the meeting was the same time, sorry!

Aaron Turon (Mar 18 2019 at 18:49, on Zulip):

@Taylor Cramer fair enough. i'm also thinking that for the rest of the ecosystem, stable matters more

nikomatsakis (Mar 18 2019 at 18:49, on Zulip):

I feel like to really see the impact on the ecosystem though .. hmm .. yeah, I guess what @Aaron Turon said

Alexander Regueiro (Mar 18 2019 at 18:49, on Zulip):

6:00 was better ironically

Alexander Regueiro (Mar 18 2019 at 18:49, on Zulip):

oh well, here now

Aaron Turon (Mar 18 2019 at 18:49, on Zulip):

and e.g. for the Tower folks, it's clear they want to wait until there are no cliffs

Aaron Turon (Mar 18 2019 at 18:49, on Zulip):

But also I think we can't answer this question without talking about chalk integration

yes agreed

centril (Mar 18 2019 at 18:50, on Zulip):

What I would be unhappy with is stabilizing and then using the 'static limitation in the standard library such that it becomes technical debt we cannot get away from later

Taylor Cramer (Mar 18 2019 at 18:50, on Zulip):

@Aaron Turon yeah, in principle I would definitely rather wait longer to get the "correct" thing than continually but more quickly edge towards something that looks usable except in cases X, Y, and Z

Aaron Turon (Mar 18 2019 at 18:50, on Zulip):

@nikomatsakis on that note, can you clarify: are there now two routes for integration? one with rustc today, and one via RLS 2.0 and eventual integration of that?

Taylor Cramer (Mar 18 2019 at 18:50, on Zulip):

but certainly there's a practical component of whether or not it's enough for most people

nikomatsakis (Mar 18 2019 at 18:51, on Zulip):

I feel like the AsyncFoo example -- I guess I still feel a bit confused

nikomatsakis (Mar 18 2019 at 18:51, on Zulip):

but let's move a bit on and circle back perhaps

Alexander Regueiro (Mar 18 2019 at 18:51, on Zulip):

we still on GAT? might need to devote time to other points :-)

Alexander Regueiro (Mar 18 2019 at 18:51, on Zulip):

heh

Aaron Turon (Mar 18 2019 at 18:51, on Zulip):

time check -- does anyone have a hard stop in 10 min? should we go ahead and schedule some additional time?

nikomatsakis (Mar 18 2019 at 18:51, on Zulip):

I'm game to keep going

centril (Mar 18 2019 at 18:52, on Zulip):

@Aaron Turon wrt. other subjects... type Foo = impl Bar;, can you review https://github.com/rust-lang/rfcs/issues/2515#issuecomment-467238637 ?

nikomatsakis (Mar 18 2019 at 18:52, on Zulip):

OK, let's leave GATs for a second. I guess it makes sense to focus a bit on chalk. Not sure, @scalexm, if you are around btw?

nikomatsakis (Mar 18 2019 at 18:53, on Zulip):

We could touch briefly on lazy norm -- I think in some sense it is maybe a similar story, though maybe different

centril (Mar 18 2019 at 18:53, on Zulip):

about lazy norm... I felt I hit it many times when writing ATB tests for @Alexander Regueiro

nikomatsakis (Mar 18 2019 at 18:53, on Zulip):

in particular I am not entirely persuaded that generic constants are truly blocked on this, but I feel like it'll take some amount of effort to really investigate it. Basically have to do some of the impl work around that and see what problems we hit.

centril (Mar 18 2019 at 18:54, on Zulip):

@nikomatsakis we already have generic constants through associated constants?

nikomatsakis (Mar 18 2019 at 18:54, on Zulip):

That is to say, I think that there is (maybe) a way to get const generics working with eager norm

nikomatsakis (Mar 18 2019 at 18:54, on Zulip):

No, not really

nikomatsakis (Mar 18 2019 at 18:54, on Zulip):

I mean there are various ad-hoc limitations

nikomatsakis (Mar 18 2019 at 18:54, on Zulip):

It's been tricky to get to the bottom of that

nikomatsakis (Mar 18 2019 at 18:55, on Zulip):

That said, I think lazy norm is needed for other reasons beyond that: or certainly there are a whole family of bugs that e.g. @centril was referring to.

nikomatsakis (Mar 18 2019 at 18:55, on Zulip):

It'd probalby be good to get precise about that

nikomatsakis (Mar 18 2019 at 18:55, on Zulip):

(including some issues where NLL is not able to capture the user's annotations as precisely as we might like)

nikomatsakis (Mar 18 2019 at 18:56, on Zulip):

So in some sense I feel like there is a similar trade-off to GATs here, but different. There is probably progress possible on rustc today, but I'm not 100% sure on how "low hanging" the fruit is

centril (Mar 18 2019 at 18:56, on Zulip):

Like Foo: for<'a> Bar<'a, Assoc: Copy> hits lazy norm issues I think due to desugaring to for<'a> <Foo as Bar<'a>>::Assoc: Copy

nikomatsakis (Mar 18 2019 at 18:56, on Zulip):

yeah, probably. that's more about 'normalizing under binders', but it's related

Alexander Regueiro (Mar 18 2019 at 18:56, on Zulip):

@nikomatsakis did we decide whether lazy norm was needed for fixing type alias bounds yet?

nikomatsakis (Mar 18 2019 at 18:57, on Zulip):

it's certainly my preferred route to rationalize type aliases

nikomatsakis (Mar 18 2019 at 18:57, on Zulip):

ok, so let's dig a bit into chalk

scalexm (Mar 18 2019 at 18:57, on Zulip):

I’m around

nikomatsakis (Mar 18 2019 at 18:57, on Zulip):

to answer your question @Aaron Turon, here is what I've been pondering

nikomatsakis (Mar 18 2019 at 18:58, on Zulip):

on the one hand, @scalexm (and others) did a lot of great work integration chalk into rustc, and we've got something kind of working for some cases (Which reminds me, @scalexm, it's on my todo list to give feedback on your "fixups" PR :P)

nikomatsakis (Mar 18 2019 at 18:58, on Zulip):

there are some nontrivial things left to fix, some of them however are more on the chalk side than rustc side (e.g., we have to work through the best way to handle region constraints)

Alexander Regueiro (Mar 18 2019 at 18:59, on Zulip):

yeah, region constraints seems like the big outstanding task

Alexander Regueiro (Mar 18 2019 at 19:00, on Zulip):

(from an outside perspective)

nikomatsakis (Mar 18 2019 at 19:00, on Zulip):

but we've also not started the real work of trying to get things "prod ready"

scalexm (Mar 18 2019 at 19:00, on Zulip):

Well maybe it’s not « that » big, we just need to figure out how to correctly aggregate identical solutions with different region constraints

centril (Mar 18 2019 at 19:00, on Zulip):

@nikomatsakis So maybe if "we" (read: Felix, other people...) can take some of the r?s off you then you can work more on chalk yourself?

nikomatsakis (Mar 18 2019 at 19:00, on Zulip):

I'm trying desperately to free up some more coding time :)

centril (Mar 18 2019 at 19:01, on Zulip):

@nikomatsakis aight; I'll try to help with freeing you up ^^

nikomatsakis (Mar 18 2019 at 19:01, on Zulip):

what I've been pondering about for RLS 2.0 is that -- we have a need to have chalk integration there too, and we have fewer "backwards compat constraints" -- so in particular we might be able to do much deeper integration

nikomatsakis (Mar 18 2019 at 19:01, on Zulip):

and in general we don't have to worry as much about regressing things on the rustc side etc

nikomatsakis (Mar 18 2019 at 19:02, on Zulip):

we did some investigation (see this paper) and came up with some pretty concrete work items

Aaron Turon (Mar 18 2019 at 19:02, on Zulip):

(quick clarification: for RLS 2.0 i believe the "integration" story involves using Chalk as a library; is the same true of the current rustc integration work?)

Alexander Regueiro (Mar 18 2019 at 19:02, on Zulip):

I'm personally a little concerned too much time is being devoted to RLS 2.0 when there are more pressing concerns, especially for wg-traits, no?

nikomatsakis (Mar 18 2019 at 19:02, on Zulip):

(quick clarification: for RLS 2.0 i believe the "integration" story involves using Chalk as a library; is the same true of the current rustc integration work?)

both involve using chalk as a library, but it depends on how much of chalk

nikomatsakis (Mar 18 2019 at 19:02, on Zulip):

currently, rustc uses chalk-engine, which is really a pretty minimal part

nikomatsakis (Mar 18 2019 at 19:03, on Zulip):

the plan for RLS 2.0 was to leverage far more -- e.g., sharing the "lowering code" that goes from impl+trait to rules, etc

nikomatsakis (Mar 18 2019 at 19:03, on Zulip):

and (eventually) the representation of types etc

Aaron Turon (Mar 18 2019 at 19:04, on Zulip):

ok -- so i guess a different question is, if the ultimate goal is to use shared crates, it seems like the rustc and RLS 2.0 efforts could intercept each other nicely by both being centered around that structure?

nikomatsakis (Mar 18 2019 at 19:05, on Zulip):

they don't seem directly at odds

nikomatsakis (Mar 18 2019 at 19:05, on Zulip):

I'm not sure if that's what you meant

nikomatsakis (Mar 18 2019 at 19:05, on Zulip):

( in other words, I think we could pursue both to some extent )

centril (Mar 18 2019 at 19:05, on Zulip):

I do think that rustc should be the priority where/if there's need to prioritize

nikomatsakis (Mar 18 2019 at 19:06, on Zulip):

I'm personally a little concerned too much time is being devoted to RLS 2.0 when there are more pressing concerns, especially for wg-traits, no?

well, this is not entirely clear to me, but I think it's a good question =) I see it being pretty important to help get RLS 2.0 up and going, and pretty important to validate out the chalk approach and find what problems we are going to find. But certainly if we are blocking on chalk for GATs + norm that changes things.

centril (Mar 18 2019 at 19:06, on Zulip):

(i.e. rustc + chalk, not rustc alone)

Aaron Turon (Mar 18 2019 at 19:06, on Zulip):

well, so more concretely, i'm imagining that rustc uses some parts of chalk in order to get expressivity benefits; meanwhile, RLS 2.0 pushes further out ahead, iterating on deeper modularization questions; and then over time, rustc is shifted to use more of these shared libraries as well

nikomatsakis (Mar 18 2019 at 19:07, on Zulip):

yes, I was contemplating this plan

Aaron Turon (Mar 18 2019 at 19:07, on Zulip):

but with the hope that we can ship some chalk-based features in rustc before full RLS 2.0 "integration"

nikomatsakis (Mar 18 2019 at 19:07, on Zulip):

I mean maybe the way to think about it is just one project -- "chalk integration"

centril (Mar 18 2019 at 19:08, on Zulip):

@Aaron Turon I agree strongly with the "before" bit ;) -- It would be a bummer to have the rustc side wait until middle of 2020 or so

Alexander Regueiro (Mar 18 2019 at 19:09, on Zulip):

it's basically ready now. :-) just adding the feature gate and cleaning up things.

Alexander Regueiro (Mar 18 2019 at 19:09, on Zulip):

Niko, should I r? you when it is?

nikomatsakis (Mar 18 2019 at 19:09, on Zulip):

So I'm re-reading the comments @scalexm made here

nikomatsakis (Mar 18 2019 at 19:10, on Zulip):

which map pretty closely to my memory in terms of chalk next steps

nikomatsakis (Mar 18 2019 at 19:10, on Zulip):

Niko, should I r? you when it is?

sorry what we are talking about here? your PR?

nikomatsakis (Mar 18 2019 at 19:12, on Zulip):

if we were going to pursue chalk integration full steam, I guess that I would want to focus our energy on

nikomatsakis (Mar 18 2019 at 19:12, on Zulip):

Maybe the thing to do is this

nikomatsakis (Mar 18 2019 at 19:12, on Zulip):

we have these sprints for a reason

nikomatsakis (Mar 18 2019 at 19:12, on Zulip):

we can try for 6 weeks

nikomatsakis (Mar 18 2019 at 19:12, on Zulip):

and re-evaluate :)

nikomatsakis (Mar 18 2019 at 19:13, on Zulip):

but we should try to set some clear goals

tmandry (Mar 18 2019 at 19:13, on Zulip):

so, chalk is still limited in terms of what it can express today.. full rustc integration could pave the way for the remaining aspects of Rust that it doesn't model

nikomatsakis (Mar 18 2019 at 19:13, on Zulip):

(and I would like to keep the RLS 2.0 ball going a bit)

nikomatsakis (Mar 18 2019 at 19:13, on Zulip):

but I think a lot of that was working on refactoring and improving chalk

centril (Mar 18 2019 at 19:13, on Zulip):

@nikomatsakis > if we were going to pursue chalk integration full steam, [...]

Yes, yes please :slight_smile:

nikomatsakis (Mar 18 2019 at 19:14, on Zulip):

so, chalk is still limited in terms of what it can express today.. full rustc integration could pave the way for the remaining aspects of Rust that it doesn't model

and yes, this is a thing too, extending to cover various bits of rust we don't cover. I think the list is roughly

uuuuuuuh anything else? :)

tmandry (Mar 18 2019 at 19:15, on Zulip):

may be crazy but since we're talking about sharing a representation and lower code.. was there ever any talk of converting HIR to chalk-ir?

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

yes

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

I looked into it some

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

it's maybe plausible but we already wrote a lot of that code

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

I think I'd rather pursue that on the RLS 2.0 side and come back

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

so I was thinkg

nikomatsakis (Mar 18 2019 at 19:15, on Zulip):

one of my big fears around chalk integration

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

has to do with the way the solver works --

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

I worry that it will take us some time to get the "evaluation strategy" tweaked right, so that it does't wind up taking a lot of time to explore useless avenues

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

it's supposed to be good at that but this is unproven

nikomatsakis (Mar 18 2019 at 19:17, on Zulip):

I'm trying to think if there is something we can do to help "tilt" our evaluation in that direction

nikomatsakis (Mar 18 2019 at 19:17, on Zulip):

I guess that it means that (e.g.) features like specialization are probably less important, but things like clause selection order and improving hacks around ?T: Sized are important

nikomatsakis (Mar 18 2019 at 19:17, on Zulip):

maybe I should explain what I'm worried about?

nikomatsakis (Mar 18 2019 at 19:18, on Zulip):

the tl;dr is that it is possible, given impls like

impl<T> Trait for Vec<T> { .. }

to produce a lot of answers for Trait -- e.g., basically Vec<T> for any sized T will do

Aaron Turon (Mar 18 2019 at 19:18, on Zulip):

(i personally think that getting full-blown GATs working is more important than specialization; also, this re-raises the point that Chalk integration could help with another big priority, namely compiler perf)

nikomatsakis (Mar 18 2019 at 19:18, on Zulip):

the way that the solver works, it could (in some cases) wind up enumerating those for a while

nikomatsakis (Mar 18 2019 at 19:19, on Zulip):

(i personally think that getting full-blown GATs working is more important than specialization; also, this re-raises the point that Chalk integration could help with another big priority, namely compiler perf)

yes, potentially

nikomatsakis (Mar 18 2019 at 19:19, on Zulip):

ok, so, we'll focus largley on chalk and less on "short term" fixes, at least for this sprint

nikomatsakis (Mar 18 2019 at 19:19, on Zulip):

I think an important question to ask is: who is going to have what amount of time :)

nikomatsakis (Mar 18 2019 at 19:19, on Zulip):

I am planning to try to reserve Mondays for trait coding, at least, and maybe another day. I guess we'll see. But I'm also on PTO for at least one week :P

Aaron Turon (Mar 18 2019 at 19:20, on Zulip):

i will have time but will need mentoring

scalexm (Mar 18 2019 at 19:20, on Zulip):

I don’t feel like I have enough time to actively work on the chalk integration in rustc, but I can advise

nikomatsakis (Mar 18 2019 at 19:20, on Zulip):

I think I would expect that most folks would need mentoring

centril (Mar 18 2019 at 19:20, on Zulip):

@nikomatsakis in the quantified constraints paper they talk about a technique they call "focusing", idk if that would help but it's worth a read; Here's the ICFP talk: https://www.youtube.com/watch?v=TDRvd0A6j6k

nikomatsakis (Mar 18 2019 at 19:20, on Zulip):

@centril ok thanks

tmandry (Mar 18 2019 at 19:20, on Zulip):

I may have some time also

nikomatsakis (Mar 18 2019 at 19:20, on Zulip):

(I didn't know the talk was online)

centril (Mar 18 2019 at 19:21, on Zulip):

(most ICFP talks are online ^^, and they are pretty great)

Aaron Turon (Mar 18 2019 at 19:22, on Zulip):

@nikomatsakis when is your PTO?

nikomatsakis (Mar 18 2019 at 19:22, on Zulip):

first week of april

nikomatsakis (Mar 18 2019 at 19:22, on Zulip):

gonna tour Uruguay after Rust LATAM

nikomatsakis (Mar 18 2019 at 19:22, on Zulip):

and yeah, there's that too :)

centril (Mar 18 2019 at 19:22, on Zulip):

@nikomatsakis (there's a talk about lambda prolog ("makam") that may interest you, https://www.youtube.com/watch?v=tg1a3Dd6Se0)

nikomatsakis (Mar 18 2019 at 19:22, on Zulip):

I remember the paper

nikomatsakis (Mar 18 2019 at 19:23, on Zulip):

so i'm going to put a few things into the dropbox paper document regarding sprint goals

Aaron Turon (Mar 18 2019 at 19:23, on Zulip):

OK, seems like it'd be good to try to build up some momentum over the next 1.5 weeks

Aaron Turon (Mar 18 2019 at 19:23, on Zulip):

(enough that it can continue without you)

Aaron Turon (Mar 18 2019 at 19:23, on Zulip):

i won't be at Rust LATAM

nikomatsakis (Mar 18 2019 at 19:24, on Zulip):

Yes I think a good idea @Aaron Turon would be for us to frontload some amoutn of work

nikomatsakis (Mar 18 2019 at 19:24, on Zulip):

i.e., me + you perhaps

nikomatsakis (Mar 18 2019 at 19:24, on Zulip):

I have a project in mind ;)

Aaron Turon (Mar 18 2019 at 19:24, on Zulip):

sounds great!

nikomatsakis (Mar 18 2019 at 19:25, on Zulip):

so i'm typing a bit into the paper and perhaps folks should drop in there, but something here I want to throw out for future dicussion:

nikomatsakis (Mar 18 2019 at 19:25, on Zulip):

I was thinking we could keep a queue of topics

nikomatsakis (Mar 18 2019 at 19:25, on Zulip):

but basically there is some amount of design discussion we should be doing

nikomatsakis (Mar 18 2019 at 19:26, on Zulip):

and people could nominate things for that week -- a place to talk over in detail the question they are thinking about

centril (Mar 18 2019 at 19:26, on Zulip):

@nikomatsakis is that just for chalk or in general?

nikomatsakis (Mar 18 2019 at 19:26, on Zulip):

(been thinking about how to make sure we have some time for that)

nikomatsakis (Mar 18 2019 at 19:27, on Zulip):

I would say .. anything? but priority for sprint topics? maybe just sprint topics?

centril (Mar 18 2019 at 19:27, on Zulip):

sgtm

nikomatsakis (Mar 18 2019 at 19:29, on Zulip):

@Sunjay Varma so in the RLS doc I put down "remove concept of “local and external” and reformulate in terms of crate-ids — make coherence relative to a specific crate? " and proposed it for you

nikomatsakis (Mar 18 2019 at 19:29, on Zulip):

this is a good example of work that is worthwhile I think, even though it won't directly affect rustc

nikomatsakis (Mar 18 2019 at 19:29, on Zulip):

are you still interested in that?

nikomatsakis (Mar 18 2019 at 19:29, on Zulip):

how much time do you have?

nikomatsakis (Mar 18 2019 at 19:29, on Zulip):

even though it won't directly affect rustc

yet...

nikomatsakis (Mar 18 2019 at 19:30, on Zulip):

how much time do you have?

by this I mean .. I don't want to pressure you to some extent :) it doesn't seem that hard to me though, we could probably schedule an hour to talk it over

Taylor Cramer (Mar 18 2019 at 19:32, on Zulip):

@Aaron Turon

i personally think that getting full-blown GATs working is more important than specialization

fwiw (maybe nothing, just figured I should say something) I disagree

Taylor Cramer (Mar 18 2019 at 19:32, on Zulip):

because I think it's much more common for people in all parts of Rust to be blocked by an issue that's wrapped up in details of coherence and specialization than it is for them to need GATs

Aaron Turon (Mar 18 2019 at 19:33, on Zulip):

hah, fair enough! though i think in the end it doesn't matter that much, since either is dependent on chalk integration, and GATs happens immediately

centril (Mar 18 2019 at 19:33, on Zulip):

(I think specialization has a lot more open questions and the path to stabilization is much less clear)

Taylor Cramer (Mar 18 2019 at 19:33, on Zulip):

mhm-- it also has a much clearer path towards an MVP though (I think)

centril (Mar 18 2019 at 19:33, on Zulip):

(I don't ^^)

Taylor Cramer (Mar 18 2019 at 19:33, on Zulip):

like, we're almost at a point where we could stabilize the existing implementation if you only allow specialization that uses concrete types

Taylor Cramer (Mar 18 2019 at 19:34, on Zulip):

which is 90% of my needs

centril (Mar 18 2019 at 19:34, on Zulip):

We haven't even discussed specialize(T: Foo) due to @Aaron Turon -- I don't see how we can stabilize the existing implementation.

nikomatsakis (Mar 18 2019 at 19:35, on Zulip):

@scalexm so we discussed over in #t-compiler/wg-rls-2.0/chalk this work item in some detail:

refactor lowering code to salsa queries that “demand” information

I didn't start doing anything there -- I'm presuming you didn't either. It doesn't really help rustc per se, but I am wondering if we feel it's worth trying to do? It seems like a lot of it was kind of "porting over" some of the "on demand" code from rustc?

I guess what I'm trying to figure out is just how focused to be.

nikomatsakis (Mar 18 2019 at 19:35, on Zulip):

Probably more focused is better.

Aaron Turon (Mar 18 2019 at 19:35, on Zulip):

Probably more focused is better.

seems right for our first sprint

Taylor Cramer (Mar 18 2019 at 19:37, on Zulip):

@centril I mean, it obviously wouldn't be the existing implementation exactly, but conceptually the bits that need to be changed are a much smaller implementation concern than GATs

nikomatsakis (Mar 18 2019 at 19:37, on Zulip):

(I suggest we move the specialization talk to a distinct topic)

Taylor Cramer (Mar 18 2019 at 19:37, on Zulip):

sg

tmandry (Mar 18 2019 at 19:38, on Zulip):

re: sprint, can we devote some time to putting up a clear issue list with some info on at getting started with each issue?

tmandry (Mar 18 2019 at 19:38, on Zulip):

or was your plan more to assign things to particular people from the start

scalexm (Mar 18 2019 at 19:39, on Zulip):

@nikomatsakis I barely started the queryfication work in chalk

scalexm (Mar 18 2019 at 19:39, on Zulip):

But that’s right basically it was like porting over the code in rustc

nikomatsakis (Mar 18 2019 at 19:40, on Zulip):

re: sprint, can we devote some time to putting up a clear issue list with some info on at getting started with each issue?

that's what I'm trying to do now, @tmandry -- that is, break things down into a bit more concrete steps. We don't necessarily have to have people assigned, but it's .. maybe a good idea.

scalexm (Mar 18 2019 at 19:40, on Zulip):

I don’t know if it’s worth doing it, I felt like it was, but it will definitely not be helping rustc in the short term

nikomatsakis (Mar 18 2019 at 19:41, on Zulip):

I still feel unsettled. I feel a certain urgency to see RLS 2.0 making progress. I also feel like "chalk the codebase" needs cleanup, and that there maybe an opportunity to parallelize a bit there -- but I do also think none of us have a ton of time, so the focus right now should probably be on getting more people familiar with the code than anything.

scalexm (Mar 18 2019 at 19:41, on Zulip):

On the other hand, it didn’t seem like a « huge » work either, just a big refactoring

nikomatsakis (Mar 18 2019 at 19:41, on Zulip):

Which actually might be an argument in favor, i.e., but looking on it more as a mentoring task

tmandry (Mar 18 2019 at 19:41, on Zulip):

(I have to run, but I'd be interested in picking issues off at some point)

nikomatsakis (Mar 18 2019 at 19:42, on Zulip):

Basically it seems like a problem that right now only @scalexm and I kind of have the two codebases in our heads

Sunjay Varma (Mar 18 2019 at 19:42, on Zulip):

how much time do you have?

I have a good amount of time. I will need some guidance though so I know what is needed and what I need to do. Is there any issue + some mentoring instructions somewhere?

nikomatsakis (Mar 18 2019 at 19:42, on Zulip):

On the other hand, it didn’t seem like a « huge » work either, just a big refactoring

why don't we say this

nikomatsakis (Mar 18 2019 at 19:43, on Zulip):

maybe this goes against the way sprints should work but I was thinking maybe it's useful to have a kind of "shortlist" of other ideas, depending on how things go

nikomatsakis (Mar 18 2019 at 19:43, on Zulip):

I have a good amount of time. I will need some guidance though so I know what is needed and what I need to do. Is there any issue + some mentoring instructions somewhere?

no but I think one could be prepared

Sunjay Varma (Mar 18 2019 at 19:45, on Zulip):

no but I think one could be prepared

That would be helpful. :)

nikomatsakis (Mar 18 2019 at 19:46, on Zulip):

I think what might be faster, @Sunjay Varma, is if we did a recorded call to talk it over

nikomatsakis (Mar 18 2019 at 19:46, on Zulip):

although maybe not

Sunjay Varma (Mar 18 2019 at 19:47, on Zulip):

That could work too

Sunjay Varma (Mar 18 2019 at 19:47, on Zulip):

Thursday at 2 pm EST?

nikomatsakis (Mar 18 2019 at 19:48, on Zulip):

Maybe, let's discuss that in a bit.

Sunjay Varma (Mar 18 2019 at 19:48, on Zulip):

kk

nikomatsakis (Mar 18 2019 at 19:48, on Zulip):

(well, that time doesn't work)

nikomatsakis (Mar 18 2019 at 19:49, on Zulip):

@Aaron Turon -- so I put you down for this "region ordering" question

nikomatsakis (Mar 18 2019 at 19:49, on Zulip):

er, sorry

nikomatsakis (Mar 18 2019 at 19:49, on Zulip):

"builtin bounds" / goal reordering

nikomatsakis (Mar 18 2019 at 19:49, on Zulip):

that's a bit vague and I suspect you have no idea what I am talking about

Aaron Turon (Mar 18 2019 at 19:49, on Zulip):

heh, indeed, but i'm game anyway!

nikomatsakis (Mar 18 2019 at 19:50, on Zulip):

so i'm trying to think how to "get started" on it

nikomatsakis (Mar 18 2019 at 19:50, on Zulip):

in light of that ;)

nikomatsakis (Mar 18 2019 at 19:51, on Zulip):

actually, not sure how many people are still around (this is a marathon planning session...) but I'm just going to keep dumping ideas for a second

Aaron Turon (Mar 18 2019 at 19:51, on Zulip):

could always start with a recorded zoom meeting?

nikomatsakis (Mar 18 2019 at 19:51, on Zulip):

basically, what is the set of codebases that people need to become familiar with

nikomatsakis (Mar 18 2019 at 19:51, on Zulip):

yes, I am jumping one step back from that idea

centril (Mar 18 2019 at 19:52, on Zulip):

@Aaron Turon recorded zoom meeting now?

Aaron Turon (Mar 18 2019 at 19:52, on Zulip):

no, i meant, when we want to get started on this work item

centril (Mar 18 2019 at 19:52, on Zulip):

oh, yes, makes sense

Aaron Turon (Mar 18 2019 at 19:52, on Zulip):

basically it's an easy way for @nikomatsakis to give the lay of the land without too much prep

nikomatsakis (Mar 18 2019 at 19:52, on Zulip):

I think it's something like this:

nikomatsakis (Mar 18 2019 at 19:53, on Zulip):

maybe a "sprint work item" in and of itself should be recording a few sessions trying to over the related code

nikomatsakis (Mar 18 2019 at 19:53, on Zulip):

(with an eye towards some of our goals)

nikomatsakis (Mar 18 2019 at 19:53, on Zulip):

I'm trying to decide whether it is possible to cover chalk-engine + existing rustc-chalk integration in one hour

nikomatsakis (Mar 18 2019 at 19:53, on Zulip):

maybe

nikomatsakis (Mar 18 2019 at 19:54, on Zulip):

it seems potentially nice to do so

nikomatsakis (Mar 18 2019 at 19:54, on Zulip):

since we could e.g. follow a single example "end to end"

nikomatsakis (Mar 18 2019 at 19:54, on Zulip):

actually I think it probably makes sense to start with the rustc-chalk integration

nikomatsakis (Mar 18 2019 at 19:54, on Zulip):

well I don't know, one or the other

Aaron Turon (Mar 18 2019 at 19:55, on Zulip):

haha

nikomatsakis (Mar 18 2019 at 19:55, on Zulip):

regardless, maybe we should aim to do something tomorrow

Aaron Turon (Mar 18 2019 at 19:55, on Zulip):

for me personally, i imagine it'll be pretty easy to get back up to speed with Chalk

nikomatsakis (Mar 18 2019 at 19:55, on Zulip):

and I'll decide in the meantime ;)

Aaron Turon (Mar 18 2019 at 19:55, on Zulip):

probably somewhat less so rustc, since it's been a lot longer since i worked on that

Aaron Turon (Mar 18 2019 at 19:55, on Zulip):

regardless, maybe we should aim to do something tomorrow

wfm

nikomatsakis (Mar 18 2019 at 19:56, on Zulip):

we had a nice session on this at the rust all hands actually

nikomatsakis (Mar 18 2019 at 19:56, on Zulip):

of course it's all gone from my head

nikomatsakis (Mar 18 2019 at 19:56, on Zulip):

but we didn't of course get down to the level of code

nikomatsakis (Mar 18 2019 at 19:56, on Zulip):

more the 'high level concepts'

nikomatsakis (Mar 18 2019 at 19:57, on Zulip):

ps, have you all seen the "timelines" in dropbox paper? kind of nifty ;)

nikomatsakis (Mar 18 2019 at 19:59, on Zulip):

OK I don't quite see how to get more precise yet, I think part of the work as we go will be trying to "unfold" these items into more and more specific things

nikomatsakis (Mar 18 2019 at 19:59, on Zulip):

but I think all of the items on this page are doable in 6 weeks

Aaron Turon (Mar 18 2019 at 19:59, on Zulip):

makes sense (feels like roadmap but on a smaller scale)

nikomatsakis (Mar 18 2019 at 19:59, on Zulip):

modulo how many other things get in the way :)

centril (Mar 18 2019 at 19:59, on Zulip):

@Aaron Turon "user stories" ;)

nikomatsakis (Mar 18 2019 at 20:00, on Zulip):

I think I may move this dropbox paper into its own folder

nikomatsakis (Mar 18 2019 at 20:00, on Zulip):

(that is, with one paper per sprint)

Aaron Turon (Mar 18 2019 at 20:00, on Zulip):

sg

centril (Mar 18 2019 at 20:00, on Zulip):

I'll drop out of the meeting and review some PRs to the reference

nikomatsakis (Mar 18 2019 at 20:01, on Zulip):

sprint paper doc

Aaron Turon (Mar 18 2019 at 20:02, on Zulip):

looks great @nikomatsakis

nikomatsakis (Mar 18 2019 at 20:02, on Zulip):

ok, so, now to schedule a few things :)

nikomatsakis (Mar 18 2019 at 20:05, on Zulip):

For the call covering rustc-chalk -integration, I'd like to do that sooner rather than later. I propose either:

nikomatsakis (Mar 18 2019 at 20:06, on Zulip):
nikomatsakis (Mar 18 2019 at 20:06, on Zulip):
Aaron Turon (Mar 18 2019 at 20:07, on Zulip):

the latter would be preferable for me

nikomatsakis (Mar 18 2019 at 20:07, on Zulip):

ok, that's prob better for (most) Europeans too

nikomatsakis (Mar 18 2019 at 20:07, on Zulip):

let's just do that

Sunjay Varma (Mar 18 2019 at 20:07, on Zulip):

For the call covering rustc-chalk -integration, I'd like to do that sooner rather than later. I propose either:

Does that cover chalk integration “future steps”? (That's the heading my task is under)

nikomatsakis (Mar 18 2019 at 20:08, on Zulip):

@Sunjay Varma nope

nikomatsakis (Mar 18 2019 at 20:08, on Zulip):

I was just going to ping you

nikomatsakis (Mar 18 2019 at 20:09, on Zulip):

so Thu is super busy for me

nikomatsakis (Mar 18 2019 at 20:09, on Zulip):

other days are better

Aaron Turon (Mar 18 2019 at 20:09, on Zulip):

@nikomatsakis have what you need from me at the moment?

nikomatsakis (Mar 18 2019 at 20:09, on Zulip):

yep, I think so

Sunjay Varma (Mar 18 2019 at 20:09, on Zulip):

Suggest a time?

nikomatsakis (Mar 18 2019 at 20:11, on Zulip):

@Sunjay Varma wed 14:00 Boston time?

Sunjay Varma (Mar 18 2019 at 20:12, on Zulip):

Yup that works. Talk to you then :smile:

scalexm (Mar 19 2019 at 19:02, on Zulip):

(deleted)

Last update: Nov 12 2019 at 15:30UTC