Stream: t-compiler

Topic: #59255 HAS_TY_ERR


davidtwco (May 13 2019 at 19:34, on Zulip):

@oli I've been looking for some refactoring/cleanup issues to do and stumbled upon #59255. Could you clarify that the issue is talking about removing HAS_TY_ERROR and just trying to get everything working again? I wasn't sure about where the comment was referring to when it said "just return Error", though it is ancient.

oli (May 13 2019 at 19:39, on Zulip):

@davidtwco Well... everywhere :D this would be a major undertaking (getting rid of TyKind::Err) and changing loads of functions to return Result. Maybe even putting some of these results into stored values, not sure

davidtwco (May 13 2019 at 19:39, on Zulip):

It wasn't clear to me from the issue whether it was just HAS_TY_ERROR or TyKind::Err too.

oli (May 13 2019 at 19:40, on Zulip):

yea, XD that wasn't very clear from what I wrote, I agree

davidtwco (May 13 2019 at 19:40, on Zulip):

The comment read to me as only talking about HAS_TY_ERROR.

oli (May 13 2019 at 19:41, on Zulip):

@nikomatsakis is this something we could bring up in a steering meeting? The general idea of using Result more?

oli (May 13 2019 at 19:41, on Zulip):

@davidtwco as long as we have TyKind::Err we'll need to have HAS_TY_ERROR I believe

davidtwco (May 13 2019 at 19:41, on Zulip):

I found the commit that introduced it, from March 20th 2013.

davidtwco (May 13 2019 at 19:42, on Zulip):

Unless that moved the comment and GitHub's collapsed diffs are making CTRL+F not find it.

oli (May 13 2019 at 19:42, on Zulip):

yea, it's super old

davidtwco (May 13 2019 at 19:42, on Zulip):

I suppose I'm up for the challenge.

davidtwco (May 13 2019 at 19:42, on Zulip):

It just depends if this is something we want to do or not.

oli (May 13 2019 at 19:43, on Zulip):

yea, don't start on it yet :D let's wait for niko and/or steering meeting discussions

Jake Goulding (May 13 2019 at 21:00, on Zulip):

Rust code using Result? Outrageous. Next you'll say we should use Option instead of null pointers.

varkor (May 13 2019 at 23:56, on Zulip):

there are more subtle scenarios, though, e.g. where we currently return a result of a type

varkor (May 13 2019 at 23:57, on Zulip):

so valid return values are Ok(some real type), Ok(type error) and Err(error)

varkor (May 13 2019 at 23:57, on Zulip):

and the latter two behave differently

varkor (May 13 2019 at 23:57, on Zulip):

for example, in unification system

varkor (May 13 2019 at 23:57, on Zulip):

I think there are some subtleties here

oli (May 14 2019 at 06:17, on Zulip):

will it handle all Error(error) variants differently? I would have assumed there are some terminating variants.

varkor (May 14 2019 at 21:16, on Zulip):

I'm not sure; maybe it won't be too much of a pain to convert

Vadim Petrochenkov (May 15 2019 at 09:16, on Zulip):

This is a very impractical idea, if I understand it correctly.
Replacing e.g. ExprKind::Err or Def::Err with Results would make matching on expressions/definitions a nightmare, I'd expect a similar effect from removing ty::Err.

Esteban K├╝ber (May 29 2019 at 22:04, on Zulip):

Agree with petrochenkov here, removing TyKind::Err will mean making every type node be Result<TyKind, _>, which doesn't give us much

oli (May 29 2019 at 22:15, on Zulip):

wouldn't it just bubble up so the outermost node would end up being Err(sth)?

Vadim Petrochenkov (May 30 2019 at 07:00, on Zulip):

I guess someone needs to try and see how it looks.

matklad (May 30 2019 at 17:49, on Zulip):

The general idea of using Result more?

Hm, from the IDE perspective, you really, really don't want Either<Value, Error>, you must use (Value, Vec<Error>)

matklad (May 30 2019 at 17:49, on Zulip):

That is, you should resiliently recover from errors.

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

is this something we could bring up in a steering meeting? The general idea of using Result more?

I've not read this whole topic, but to follow up here, we have a planning meeting tomorrow -- perhaps somebody can submit a short meeting proposal?

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

Agree with petrochenkov here, removing TyKind::Err will mean making every type node be Result<TyKind, _>, which doesn't give us much

but I definitely do NOT think we should do this

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

if anything, I'd more go the opposite direction, and create more error sentinel values :)

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

(roughly what @matklad said)

Last update: Nov 20 2019 at 01:15UTC