▲ 19 ▼ The Handle trait (smallcultfollowing.com) submitted 10 months ago by SorteKanin@feddit.dk to c/rust@programming.dev 8 comments fedilink hide all child comments
[–] INeedMana@piefed.zip 0 points 10 months ago (2 children) Why not just expand meaning of &? let l_before = &v1; permalink fedilink source hideshow 4 child comments replies: [–] SorteKanin@feddit.dk [S] 5 points 10 months ago (1 child) How do I now actually get a &Arc? Without implicitly cloning? & is such a fundamental part of the syntax, I really don't think it's meaning should be muddled. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 1 point 10 months ago (1 child) What's the use-case for &Arc? Modifying an Arc object in outer scope? To me, this handle trait sounds a lot like "reference-counted reference". When there already exists a pure "reference" in the language permalink fedilink source parent hideshow 2 child comments replies: [–] SorteKanin@feddit.dk [S] 1 point 10 months ago (1 child) I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 2 points 10 months ago I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference This proposal as I understand it is an attempt at making reference-counting more ergonomic. Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at? permalink fedilink source parent [–] TechnoCat@lemmy.ml 5 points 10 months ago (1 child) Without ref counting it is hard to know when to free or safely change a value with multiple consumers permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 1 point 10 months ago I mean, keep the ref-counting. Just from the syntax perspective. Aligning with the example in the post: & before Arc would increment reference count, before a Mutex would reference the same object as it does now permalink fedilink source parent
[–] SorteKanin@feddit.dk [S] 5 points 10 months ago (1 child) How do I now actually get a &Arc? Without implicitly cloning? & is such a fundamental part of the syntax, I really don't think it's meaning should be muddled. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 1 point 10 months ago (1 child) What's the use-case for &Arc? Modifying an Arc object in outer scope? To me, this handle trait sounds a lot like "reference-counted reference". When there already exists a pure "reference" in the language permalink fedilink source parent hideshow 2 child comments replies: [–] SorteKanin@feddit.dk [S] 1 point 10 months ago (1 child) I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 2 points 10 months ago I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference This proposal as I understand it is an attempt at making reference-counting more ergonomic. Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at? permalink fedilink source parent
[–] INeedMana@piefed.zip 1 point 10 months ago (1 child) What's the use-case for &Arc? Modifying an Arc object in outer scope? To me, this handle trait sounds a lot like "reference-counted reference". When there already exists a pure "reference" in the language permalink fedilink source parent hideshow 2 child comments replies: [–] SorteKanin@feddit.dk [S] 1 point 10 months ago (1 child) I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 2 points 10 months ago I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference This proposal as I understand it is an attempt at making reference-counting more ergonomic. Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at? permalink fedilink source parent
[–] SorteKanin@feddit.dk [S] 1 point 10 months ago (1 child) I don't know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. References are just pointers, they don't have any counting. This proposal as I understand it is an attempt at making reference-counting more ergonomic. permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 2 points 10 months ago I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference This proposal as I understand it is an attempt at making reference-counting more ergonomic. Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at? permalink fedilink source parent
[–] INeedMana@piefed.zip 2 points 10 months ago I don’t know but it could be anything else than an Arc. Obviously you should still be able to take a usual reference to such a thing. Maybe. My point is that unless you want to, for example, have a reference that you switch between which object it references, I think you would be fine with using the ref-counted reference. With eventual optimization done via compiler when it's sure the code won't be trying to access the object after it got deleted. But even if I'm wrong, there could be another way to get a pure reference This proposal as I understand it is an attempt at making reference-counting more ergonomic. Yes, and IMO by using Handle for that it breaks a pattern. Rust keeps * and & for speaking about values and memory management (I want data vs I want reference). Using a trait for ref-counted referencing adds another layer. So suddenly we have *, & and ::Handle(). You see what I'm getting at? permalink fedilink source parent
[–] TechnoCat@lemmy.ml 5 points 10 months ago (1 child) Without ref counting it is hard to know when to free or safely change a value with multiple consumers permalink fedilink source parent hideshow 2 child comments replies: [–] INeedMana@piefed.zip 1 point 10 months ago I mean, keep the ref-counting. Just from the syntax perspective. Aligning with the example in the post: & before Arc would increment reference count, before a Mutex would reference the same object as it does now permalink fedilink source parent
[–] INeedMana@piefed.zip 1 point 10 months ago I mean, keep the ref-counting. Just from the syntax perspective. Aligning with the example in the post: & before Arc would increment reference count, before a Mutex would reference the same object as it does now permalink fedilink source parent