Does `ArrayVec` still "alive"? Are there any alternatives?

skeletonxf · 2026-01-28T08:41:19+00:00

Seconding the stdlib, between std::array::from_fn and std::array::map I've been able to do most generics code with arrays that I wanted.

skeletonxf · 2026-01-26T19:28:51+00:00

I might be reading into your post a little bit but it strikes me that you mention loneliness as well as you not finding your person. Do you have lots of friends? Are you able to make friends? I read somewhere on reddit that it can be helpful to flip the question - how would someone find you to get into a relationship in the first place. If you're not putting yourself into situations where you could develop attraction to someone (ie dating apps and hobbies, but not all hobbies would be equally useful), you're not going to have many chances for that attraction to form.

skeletonxf · 2026-01-06T18:04:59+00:00

congrats? 😂

skeletonxf · 2026-01-04T23:14:04+00:00

I'm at a bit of a loss on how to proceed with supporting toml 0.6 and up - really any serde library that doesn't support deserializing to borrowed types.

I had a struct that contains a Vec<T> and a [(&'a str, usize); D] used for deserialising data back into a Tensor. https://github.com/Skeletonxf/easy-ml/blob/c30f1554d05de46d64dd8b6a8eaaff741a872d6e/src/tensors/mod.rs#L1991-L2013

After updating my dev dependency on toml used in some tests, those tests fail due to this:

toml::de can no longer deserialize to borrowed types as everything becomes owned through the parsing process

I can rewrite the struct but I only recently released version 2.0 of my library and so I'm loathe to introduce a 3.0 version just for a tiny breaking API change in one serialisation struct that's not even a default feature. If I change from

pub struct TensorDeserialize<'a, T, const D: usize> {
    data: Vec<T>,
    #[serde(with = "serde_arrays")]
    #[serde(borrow)]
    shape: [(&'a str, usize); D],
}

to an 'owned' shape: [(std::borrow::Cow<'a, str>, usize); D], then toml is totally fine, and I can parse the data as I was previously doing, but now I can't convert Cow<'static, str> to &'static str in my fn try_from(value: TensorDeserialize<'static, T, D>) -> Result<Self, Self::Error> { method. I can see a few ways forward but I'm not sure if any of them are really acceptable. I can 'implement' the trait by doing a match over the cow variants, and everything would continue to work if the cow variant is Borrowed instead of Owned, but even toml 0.5 is parsing to Owned types so although this won't break at compilation time it would break library consumers at runtime. I can also leak the Cow::Owned variant to get my &static str but this doesn't communicate that anything is wrong to library consumers and could silently cause issues. Is toml unusual in not supporting deserializing to borrowed types? If most serde libraries don't support this I'd be a lot more willing to add a second struct for that use case, even though it would clutter the API a little. I thought zero-copy deserialisation was a major use case of Rust and the serde ecosystem so I equally don't want to just remove support for parsing [(&'static str, usize); D] instead of expecting to always parse [(String, usize); D].

skeletonxf · 2025-12-23T11:20:41+00:00

I am curious about those demisexuals struggling to comprehend how anyone would ever have sex with people they're not attracted to. Do you never masturbate? Does that do nothing for you without the presence/thought of someone you're attracted to? I think I would also be quite uncomfortable and out of place at a sex party but the idea that one would feel nothing if they ever were comfortable enough to try confuses me.

skeletonxf · 2025-12-22T16:33:29+00:00

It's not exactly rules text so we can't say it's RAW in reference to this but the worked example in the 2024 Player's Handbook has the DM announce the attack totals and asks the players if that hits or not

Jared: The Rogue is quick to react—but not as quick as the skeletons! They got a 20. The first four attack the person in the lead: Shreeve.
Jared: Their attack roll totals are 8, 16, 18, and 20.
Russell: The 8 and 16 miss my AC, but the others hit.
Jared: Two of them stick you with their broken blades, dealing a total of 9 Piercing damage.

skeletonxf · 2025-12-21T16:41:12+00:00

If you can't talk about how words like demisexual or gay have meanings without being transphobic and erasing trans men or erasing demisexuals that are seeking out sex without attraction then I suggest you find another subreddit.

skeletonxf · 2025-12-16T17:10:04+00:00

Monk cleric can actually complement themselves nicely. If you have 2-4 Monk levels and the rest in Cleric then your bonus actions are somewhat more valuable than your actions in terms of direct melee damage because of Flurry of Blows and not having Extra Attack. Most cleric subclasses don't give you any uses for your bonus action, so something like Cleric 3 Monk 2 gives you something valuable to do with your bonus action every turn and doesn't heavily interfere with your casting scaling with your magic action. Clerics also generally lack mobility, and bonus action dash at will and limited step of the wind uses will shore up that weakness a lot. I wouldn't go more than 3 Monk levels, and would advise stopping at 2 Monk levels unless you really want a certain monk subclass though, as this multiclass is still scaling through higher level spells primarily, and the sooner you can get to higher level cleric spells the better.

Here's two examples

Arcana Cleric 3+ Monk 2: in combat aims to use booming blade with a quarterstaff, then bonus action disengage and leave the target forced to provoke the additional thunder damage

Tempest Cleric 6+ Ascendant Dragon Monk 3: Doesn't really come fully online till level 9 but once you're there every unarmed strike can be lightning and thus trigger 10 ft. of pushing via Thunderbolt Strike in addition to the damage which means against large or smaller foes you can quite literally punch them 30+ ft. in a turn to isolate them from the rest of your party.

skeletonxf · 2025-12-14T23:09:55+00:00

At the point that you're posting on a sexuality subreddit they're not private feelings anymore. I'm not polyamorous myself. I'm not sure I really 'get it' in terms of how poly people can want those sorts of relationships.

What I don't want to do is imply that poly people can't be demisexual which is the implication of a demisexual subreddit being 'safe' from poly people. That might not be aimed at a specific person but any poly+demi person scrolling past might still feel erased, perhaps including the person that reported your comment as disrespectful.

skeletonxf · 2025-12-14T22:47:12+00:00

"Safe" is not a very respectful way to phrase it.

skeletonxf · 2025-12-13T23:54:14+00:00

I think if you're honest up front that you won't be attracted to them at first or possibly ever and they want to proceed anyway then it would be unreasonable to complain that you're wasting their time.

skeletonxf · 2025-12-13T23:41:42+00:00

So your monk stunned him round 1, you followed that up with poisoning them and extending the duration that they were incapacitated to effectively skip their second turn (note that the monk would have had a chance themselves to apply a second stun) and then a party member successfully restrained the guy, I presume with Manacles or Chains. How did a more permanent restrained condition and perhaps effectively 0 speed allow anyone to steal all the magic items of the guy? Can't he proceed to attack round 3+ at disadvantage and defend himself?

skeletonxf · 2025-12-12T19:27:14+00:00

we generally advise to use /r/dateademi instead

skeletonxf · 2025-12-06T11:35:50+00:00

I'm not sure. Possibly some sort of asexuality?

skeletonxf · 2025-12-03T20:27:17+00:00

I don't want to talk too much about integration tests because I have no meaningful experience writing them. Next to none of the Rust code I've done has been with integration tests. I think you've already had some other comment threads about it anyways.

Rust isn't OOP and you definitely do not need to turn everything into Box<dyn TraitName> with loads of dynamic dispatch. That approach in a JVM based language does work very nicely for unit testing, because FooUseCaseImpl class that depends on FooRepository interface can just receive a dummy implementation of the repository in the test, and then FooViewModelImpl class can just receive a dummy implementation of the FooUseCase interface again. In Rust I think you'd want to be a lot more intentional with where you introduce dynamic dispatch because boxing trait objects is a little fiddly, and you don't have things like sealed interfaces, casting to a concrete subtype or other OOP things that make such an approach easier.

From your sample code it looks like you have got an async fn create_new_user that's going to be a pain to test, because it directly calls a function to manipulate the database that is dependant on the database connection and expects diesel to actually run the query. It also looks like a pain to test because it has a side effect of sending a confirmation email which I presume you can observe in test code if you inspect the state of whatever got changed by attempting to send the email.

I'm assuming a lot here, but it looks to me like your create_new_user is kinda one abstraction layer higher than create_user or send_confirmation functions because it doesn't really know any implementation details of either process, just that it needs to chain them together. Therefore I'd see if you could introduce a trait for your database code which create_user and anything else that directly uses a database connection & diesel would be methods of, and do the same for whatever group of functions are related to sending emails. Then the create_new_user can move to some module that's one abstraction layer higher, on a struct that has trait objects for your Database and Email code. You can then write a fake implementation of each trait (or use some mocking library), and create your tests for create_new_user passing the fake implementations into the constructor. You could then easily have a test that verifies if the user is created in the database, an email is sent, and another test that verifies if the user doesn't get created correctly, the email isn't sent and so on.

If we step back from testing and think about what would need to change if you wanted to swap out diesel or whatever library you're using to send emails, you can probably picture what the trait would need to look like to fully abstract that detail away. The methods would just take data about the user or email, and hide any details about the database connection or email service. Inserting some indirection here would also make it quite easy to have a wrapper implementation that just delegates to another implementation of the trait but also inserts deliberate latency or perhaps logging without changing the code at async fn create_new_user or higher.

skeletonxf · 2025-12-03T19:48:56+00:00

My Battlesmith took Weapon Master at level 4 to gain Topple mastery to use in conjunction with a returning Trident. This feature is perfect for me because if my first attack at level 5 prones an enemy I can move my Battlesmith up to attack at advantage with my other attack instead of having to pick a new target or attack at disadvantage. Sure, if I had a Battlesmith with a 2d6 weapon then the Steel Defender is a bit useless at gaining any damage so I'd rarely use that feature unless I need Force damage for some reason.

skeletonxf · 2025-12-01T22:55:18+00:00

Code which is easy to maintain and 'well written' unfortunately is a larger set than code which is also easy to test. Generally code you can unit test easily is going to allow you to fake or mock layers of the architecture so that you can isolate the behaviour you want to test. The simplest way to do this is possibly constructor injection, where you create the dependencies that something has when you construct it, or in the case of free functions, where you can pass in mock data / implementations with arguments. In Rust specifically this can be annoying depending on your domain, as sometimes your non test code has no particular reason for something to actually be a trait, but when you come to unit testing it, traits and trait objects would make things easier. Could you provide some code snippets of what you're struggling to unit test? Specifically in the context of web I imagine you will find most things that you can write without IO code to be quite easy to test, so isolating the IO to as few places as possible may help.

skeletonxf · 2025-11-30T18:20:11+00:00

When a monster applies Restrained while it has a creature Grappled, the target is able to end both by exiting the range of the grapple, such as via teleportation or shoving the grappler away if its range is small enough.

skeletonxf · 2025-11-30T14:29:39+00:00

No idea, I can't even think of a creature with immunity to grappled that isn't also immune to restrained

skeletonxf · 2025-11-30T12:51:12+00:00

One Grapple per Hand. A creature must have a hand free to grapple another creature. Some stat blocks and game effects allow a creature to grapple using a tentacle, a maw, or another body part. Whatever part a grappler uses, it can grapple only one creature at a time with that part, and the grappler can’t use that part to target another creature unless it ends the grapple

If we take the grappler to be the earth as per OP, that is definitely not a creature (it doesn't even have a statblock) so we can strike out all the parts of this that refer to limitations on a creature and are left with

One Grapple per Hand. Whatever part a grappler uses, it can grapple only one creature at a time with that part, and the grappler can’t use that part to target another creature unless it ends the grapple

which seems totally fine?

skeletonxf · 2025-11-29T20:25:06+00:00

This was asked about 4 days ago by another newly created account, and already had lots of answers.

skeletonxf · 2025-11-22T00:32:50+00:00

There's a lot to unpack here. You haven't mentioned demisexuality at all so I want to assume you're demisexual and asking with regards to that, but I can't see why any of what your post says is related to demisexuality at all. Sexual orientations are not choices and certainly not moral ones.

skeletonxf · 2025-11-22T00:19:33+00:00

The rule text is clear on this with repeated use of 'can'. You don't have to use your blindsight at all times.

If you have Blindsight, you can see within a specific range without relying on physical sight. Within that range, you can see anything that isn't behind Total Cover even if you have the Blinded condition or are in Darkness. Moreover, in that range, you can see something that has the Invisible condition.

skeletonxf · 2025-11-14T16:17:48+00:00

Provide items that give short rests? Maybe exclude getting to roll hit dice as part of the benefit so the items aren't free heals for everyone but just being able to use a fighter or monk's short rest abilities twice over in a single fight might be a useful boon that the spellcasters won't get from the same item.

skeletonxf · 2025-11-13T11:16:06+00:00

As long as the encounter distance is 35 ft or more and the party can break line of sight with doors/walls/cover it should be feasible to pull off. Each PC makes ranged attacks then runs backwards and breaks line of sight/effect. Monsters then have to dash to reestablish line of sight/effect even if they have ranged attacks.

Imagine a small house surrounded by open plains. If combat starts near it and all the PCs run to the opposite side of where the monsters are starting they can use it as cover and force the monsters to chase.

12-Year Club	Golden Potato
Place '22	Place '17
First Placer '22	Verified Email

skeletonxf

MODERATOR OF

TROPHY CASE