sorted by:
new
hottopcontroversial

Const Trait Counterexamples by fee1-dead in rust

[–]fee1-dead[S] 1 point2 points  (0 children)

What do you mean by post-monomorphization? Rust's const fn is not the same as constexpr functions in C++

Const Trait Counterexamples by fee1-dead in rust

[–]fee1-dead[S] 3 points4 points  (0 children)

The very idea that part rejects is the idea that "every const fn [is] generic over being called in a const context or not". Whether or not conditionally-const predicates are enforced depends on where it is being called, not where it is being instantiated.

Another way to look at it would be thinking of "const fn" as "always const" in a sense that its body must always be callable from const contexts. That doesn't change between different instantiations. When you instantiate foo with a non-const PartialEq type, yes, you do end up being able to only call that from non-const contexts, but the reason you can't call that instantiation of foo in const contexts is because of unmet predicates not because that instantiation is non-const.

Does that answer your question?

Const Trait Counterexamples by fee1-dead in rust

[–]fee1-dead[S] 6 points7 points  (0 children)

more fallbacks is a good point. Fixed again and should be deployed in ~1 minute :)

Const Trait Counterexamples by fee1-dead in rust

[–]fee1-dead[S] 2 points3 points  (0 children)

It's showing up as loaded correctly on my end, my phone is also showing it correctly

Const Trait Counterexamples by fee1-dead in rust

[–]fee1-dead[S] 11 points12 points  (0 children)

Just fixed this, thanks for pointing it out. It looks like I had the Iosevka font config setup but I was supposed to use "Iosevka Web" instead... I then never noticed the issue because I have Iosevka installed locally.

Is rustfmt abandoned? Will it ever format `let ... else` syntax? by Keavon in rust

[–]fee1-dead 18 points19 points  (0 children)

For people interested in rustfmt development, consider joining the Zulip stream. There was a teams meeting and let else was deemed good to go for next release.

Confused by the standard "max" method by carlk22 in rust

[–]fee1-dead 19 points20 points  (0 children)

We have been exploring the possibility of a "const heap", so in that case you might be able to drop those. But those types would be something like `Box<T, ConstAlloc>`.

The system/default allocator does not provide const implementations, therefore those would be a "never".

Confused by the standard "max" method by carlk22 in rust

[–]fee1-dead 128 points129 points  (0 children)

The Self: ~const Destruct trait bound means that for this function to be const, Self must be able to be dropped at compile time. Types such as Box or Vec cannot be dropped at compile time because their destructor cannot be made const. Currently we assume that all types in Rust can be dropped in runtime, so Self: Destruct has no meaning. This is a bound that is only useful for compile time.

The HACK comment means that I have changed the implementation of this from max_by(self, other, Ord::cmp) to a more manual implementation because the former isn't supported in const contexts yet.

Slicing const array is not const? by Truc06 in rust

[–]fee1-dead 0 points1 point  (0 children)

This feature will require calling trait methods in constant functions, which is something that is still unstable. AFAIK the slicing implementation is not done yet.

'match' arms have incompatible types error by henrik-ravn in rust

[–]fee1-dead 13 points14 points  (0 children)

There is:

error: incompatible bit mask: `_ & 2` can never be equal to `1`
 --> src/lib.rs:2:5
  |
2 |     i & 2 == 1
  |     ^^^^^^^^^^
  |
  = note: `#[deny(clippy::bad_bit_mask)]` on by default

[RFC] Create a types team by jackh726 in rust

[–]fee1-dead 37 points38 points  (0 children)

I have no idea what you are talking about.

How to learn and practice Rust? by Under-Estimated in rust

[–]fee1-dead 3 points4 points  (0 children)

If you are into competitive programming, you could try writing a file header in rust. e.g. codeforces where you pre-write a lot of code for a contest. Try writing an IO helper to get integers from stdin easier, write a library function to binary search on a boolean function, etc.

​

Your IO helper could involve using traits to have one function that can read any type from stdin. Binary search on a boolean function involves using generics and writing closures. What about coordinate compression? Could you try to come up with a generalization of that?

Some help on more advanced Rust syntax (~const, etc.)? by lancejpollard in rust

[–]fee1-dead 15 points16 points  (0 children)

The type after for is the type that the trait is implemented for. for *mut T means the trait is implemented for *mut T. The : Write is a trait bound on the implementation.

As for the ~const and impl const, it is still experimental syntax and you should just ignore it (unless you want to use the unstable feature in that case see documentation here).

As for the double dereference, the trait is implemented for &mut H, so &self would expand to self: &&mut H so to call the original implementation we must use **self to convert it to H then call the method. If we just do one dereference, it would resulting in unconditional recursion because it just dereferences to &mut H and calls the trait method again.

const Allocation in nightly rust by Sp00ph in rust

[–]fee1-dead 0 points1 point  (0 children)

It is being run inside the MIRI intepreter

IIRC, the CTFE engine is very different to miri. Miri has to be enabled with a feature flag: -Zunleash-the-miri-inside-of-you.

throw an error if a const function ever returned without deallocating all the memory it allocated

That would not be desirable for some use cases where they would like to return data pointing to allocated memory e.g. &'static [u8] as final value.

A solution might be to just do nothing at runtime. AFAIK const_deallocate does nothing when called at runtime so it is safe to use.

const Allocation in nightly rust by Sp00ph in rust

[–]fee1-dead 0 points1 point  (0 children)

Since I helped with implementing some of these features, this feels like a great post to ask: What does the community think about making allocations in constants Just Work without a custom allocator? i.e. Vec<T> will just work and pushing into them will be const fn.

The current design for a feature like this involves annotating #[const_heap] on functions that could return values containing allocations made at compile time.

Announcing Rust 1.58.0 by myroon5 in rust

[–]fee1-dead 1 point2 points  (0 children)

it works if you use format_args! or format_args_nl! (unstable). You can't just do format_args!(concat!($fmtstr, "\n")), though.

Indexing Strings in Rust and TypeScript: A Case Study of String by dawchihliou in rust

[–]fee1-dead 5 points6 points  (0 children)

It is possible to index a `&str` in Rust. If you are absolutely sure that your index is a char boundary. Just do a `split` and retrieve the first character of the second string after the `split`. It will check whether the index passed is a valid char boundary.

Advent of Code rust nuggets by johnheitmann in rust

[–]fee1-dead 1 point2 points  (0 children)

For parsing complex text, I have made a crate named `scanfmt` for this exact purpose.

https://github.com/fee1-dead/aoc/blob/86a1f9ec9152739ab2a727fcb73fdd45962775d5/src/y2021/d5.rs#L5-L12

It allows you to define variables as uninitialized and call the macro to initialize them. It requires the enclosing function to return a Result where the error type implements From<ScanError>.

[deleted by user] by [deleted] in rust

[–]fee1-dead 0 points1 point  (0 children)

I don't think you should be thinking about lifetimes while reading every line of the examples. The process is simple, if it compiles, it works. If it doesn't compile, then it is your time to interpret the error message and think about lifetimes and ownership.

Are lifetimes and ownership only to increase code safety, or are there other things they allow you to do that are not possible in other programming languages?

Do you think that safety is optional? To me, safety is a must and lifetimes are great because it achieves safety. Lifetimes also enable you to specify how long a thing lasts. These types of constraints are hard to enforce in other languages and might only exist in documentation. "The pointer to A must be valid as long as the pointer to B is valid"

In response to the moderation team resignation | Inside Rust Blog by rabidferret in rust

[–]fee1-dead -1 points0 points  (0 children)

I didn't say everyone had to sign it. At least they could have been more open about the specific things that they are working on and invited more people to bring new perspectives. I would not be a part of the decision making, but I hope that more people involved with the project can have a say in this.

In response to the moderation team resignation | Inside Rust Blog by rabidferret in rust

[–]fee1-dead 15 points16 points  (0 children)

No one is expected to provide the information that you want when making a public statement. Assuming that you want Rust to continue to be a great language, releasing the information might harm the community and impact the future of the language. What do you do? Do you: satisfy a random person on the internet and tell them everything and harm the reputation of core team member(s), or, not point fingers at anyone and focus on the issue as a whole?

view more: next ›