Get rid of EscapeDebugInner.

[reitermarkus]

I read the note on EscapeDebugInner and thought I'd give it a try.

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[hkBst]

I think this is the comment you reference, so perfrun seems to be in order.

[reitermarkus]

Yeah. Should definitely be optimized in terms of size, speed remains to be seen.

[hkBst]

-        // SAFETY: `self.data.escape_seq` contains an escape sequence, as is 
-        // guaranteed by the caller, and in that case `self.alive` is guaranteed 
+        // SAFETY: `self.data.escape_seq` contains an escape sequence, as is
+        // guaranteed by the caller, and in that case `self.alive` is guaranteed

I'm sure you know this, but if you highlight these lines, you can see that the trailing space is the problem.

[reitermarkus]

r? @hkBst

[hkBst]

I still think this comment is logically wrong. If there was another way to create an EscapeIterInner with self.data.literal besides this function, would that impact the things that AlwaysEscaped guarantees? I think it does not, which would mean that this comment gives the wrong reason for the guarantees that AlwaysEscaped provides and thus this comment is wrong.

[hkBst]

@rustbot author

[reitermarkus]

I still think this comment is logically wrong.

I don't think so. You can argue both ways:

• EscapeIterInner::<N, MaybeEscaped>::printable is the only way to create any EscapeIterInner<N, T> with self.data.literal, so it follows EscapeIterInner::<AlwaysEscaped> (or any EscapeIterInner<N, T> where T != MaybeEscaped, for that matter) always contains self.data_escape_seq, given MaybeEscapedCharacter only has two variants.
• EscapeIterInner<N, AlwaysEscaped> always contains self.data_escape_seq since there is no constructor for creating an EscapeIterInner<N, AlwaysEscaped> containing self.data.literal.

However, I'm not sure where I would place the second one, given that the constructors for EscapeIterInner<N, AlwaysEscaped> are a subset of those for EscapeIterInner<N, MaybeEscaped>.

[reitermarkus]

@rustbot ready

[hkBst]

* `EscapeIterInner::<N, MaybeEscaped>::printable` is the only way to create any `EscapeIterInner<N, T>` with `self.data.literal`, so it follows `EscapeIterInner::<AlwaysEscaped>` (or any `EscapeIterInner<N, T>` where `T != MaybeEscaped`, for that matter) always contains `self.data_escape_seq`, given `MaybeEscapedCharacter` only has two variants.

I strongly prefer a formulation similar to this which talks about what the union contains or which variant it is, over the formulation "self.data.escape_seq is valid", because validity requirements are in my mind requirements beyond just being initialized. Also I think it is good to remind readers of the union nature of this member.

* `EscapeIterInner<N, AlwaysEscaped>` always contains `self.data_escape_seq` since there is no constructor for creating an `EscapeIterInner<N, AlwaysEscaped>` containing `self.data.literal`.

Instead of talking about the absence of constructor functions that create other union variants, you could just as easily and more clearly say that all constructor functions create the one union variant, and it remains true irrespective of the number of union variants that exist.

However, I'm not sure where I would place the second one, given that the constructors for EscapeIterInner<N, AlwaysEscaped> are a subset of those for EscapeIterInner<N, MaybeEscaped>.

Maybe it makes sense to place this entire rationale with the generic definition where the union member is defined to explain how the code manages to not access it invalidly.

[hkBst]

I don't have the power to approve, so it's probably best to keep someone around who does.

r? @thomcc

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[hkBst]

@thomcc I think it would make sense to see the perf impact of this change, since it is supposed to be an optimization (and increases the use of unsafe). Otherwise it seems hard to determine if this is a worthy trade-off.