-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lifetimes are extremely difficult (impossible?) to navigate #52
Comments
Yes they can be useful. We already use Line 99 in 551f7cb
|
Doesn't look like that repository is public. Don't worry, I get it :) |
Oh sorry, it is public, I copied from the wrong repo. I've updated the link. |
In my comment xD. But it works! |
Is this a problem? |
I can't say for sure whether it's a problem still—it will depend on your use-case. However, this change from last year may have made things better: 3d42e51 |
I expect you might run into other limitations even if you didn't have this particular problem. E.g. to implement a text field I think #31 would need to be implemented. |
I have the same problem with the references. I'd like to cache the |
Rasterization and such is very complex in this library, so I wanted to abstract parts of it (i.e. getting an
OutlineBuilder
) to make it easier. But that's not possible, because of how this library uses lifetimes.Basic stuff like this does not work:
due to the ownership rules required by allsorts. For example,
font
(well actuallyprovider
) depends onfont_data
's lifetime instead ofbytes
.(I managed to get that function working, I think, using boxes, but the below case I haven't been able to solve at all)
it only goes downhill from here. Let's say I wanted to outsource the process of finding an OutlineBuilder, to a function. I want to have that function do all the stupid parsing of tables for me so I can just focus on rasterizing the outlines
Whoops, Rust complains. Looks like
cff_data
depends on the lifetime offont
instead of the data that it points to. Andcff
then depends oncff_data
instead of the data thatfont
points to. You can probably see where I'm going with this. This feels like a mess and it's impossible for me to navigate.I can't store the buffer as a box in GlyphOutlineProvider because that would break rust's ownership rules (the box's contents are immutably borrowed, but someone else would be able to mutate the box if it were returned, so rust complains that the box is borrowed when I try to put it into the enum). And that's the end of that, there's really no other way to do this. Storing it under the struct is a bust because that would borrow the struct indefinitely. Unsafe code is a bust because it's way too hard to come up with something that is sound and doesn't cause UB. So on so on...
I would really love for everything in this library to just use the same lifetime, the lifetime of the slice that Font loads its data from. Because right now, the situation is kind of unmanageable for me.
I talked with @wezm over Discord and they recommended I create this issue
The text was updated successfully, but these errors were encountered: