Jacob Lifshay

> * Trap, because you read as a type that doesn't allow all initialized byte sequences (like `bool`) and the compiler helpfully chose a byte sequence the type doesn't allow....

> ```rust > pub fn ext(&mut self) -> &'a mut dyn Any; > ``` i think you shouldn't return with lifetime `'a` since that requires replacing the `Option

I think it would be useful to have the `is_*_feature_detected` macros instead run code like: ```rust macro_rules! is_x86_feature_detected { ("sse") => { feature_detect(X86Feature::SSE) }; ("sse2") => { feature_detect(X86Feature::SSE2) }; ("avx")...

> That's approximately how `std_detect` works already, could you explain what in particular is different about your example code? it's not what @Amanieu proposed? in particular the code has the...

> > I think it would be useful to have the `is_*_feature_detected` macros instead run code like: > > This is what I described in alternative designs [here](https://github.com/Amanieu/rfcs/blob/core-detect/text/0000-core_detect.md#using-a-lang-item-to-call-back-into-std). > >...

well, a list of things i think need `const PartialEq` and `const PartialOrd`: * all integer types, `char`, `bool`, `str`, all nonzero types, `Ordering`, `()`, `CStr`, `OsStr`, `PhantomData`, `Infallible`, `!`...

can we mark `impl ~const PartialEq for TypeId` unstably const now and switch to the hacky method later when that's implemented? I have code that could use it and i'd...

oh, maybe also accept function item and 0-capture lambda types and use the corresponding fn ptr

> > maybe also accept function item and 0-capture lambda types > > Do we have any way to express that kind of type constraint? I think it would have...

> reading from `/proc//environ` assuming that's like `/proc//cmdline` (edit: which luckily turns out to be a false assumption), it reads directly from the running program's memory, so if that program...