July 21, 2019
On Saturday, 20 July 2019 at 21:56:50 UTC, Walter Bright wrote:
> On 7/20/2019 5:42 AM, Sebastiaan Koppe wrote:
>> Anyway my question is whether the ownership and borrowing semantics ever gets applied to non-pointers?
>
> Currently, no. The programmer would be expected to include the correct copyctor/opAssign/destructors which would take care of it.
>
> We're likely going to add a move constructor, too.

Make sure that it is a separate pull request from the dip, as c++ std::string binding is currently block by the lack of this.
July 23, 2019
On 21.07.19 02:17, Walter Bright wrote:
> On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote:
>> Do you mean to keep track of ownership/borrowedness manually?
> 
> No, that's what the copyctor/opAssign/dtor semantics so.

This is not true.
July 23, 2019
On Tuesday, 23 July 2019 at 04:02:50 UTC, Timon Gehr wrote:
> On 21.07.19 02:17, Walter Bright wrote:
>> On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote:
>>> Do you mean to keep track of ownership/borrowedness manually?
>> 
>> No, that's what the copyctor/opAssign/dtor semantics so.
>
> This is not true.

I thought as much. Thanks for the confirmation. I am considering moving to pointers to benefit from the future semantics. It's just that I don't like pointers that much...
July 23, 2019
On 23.07.19 10:20, Sebastiaan Koppe wrote:
> On Tuesday, 23 July 2019 at 04:02:50 UTC, Timon Gehr wrote:
>> On 21.07.19 02:17, Walter Bright wrote:
>>> On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote:
>>>> Do you mean to keep track of ownership/borrowedness manually?
>>>
>>> No, that's what the copyctor/opAssign/dtor semantics so.
>>
>> This is not true.
> 
> I thought as much. Thanks for the confirmation. I am considering moving to pointers to benefit from the future semantics. It's just that I don't like pointers that much...

I think tying ownership/borrowing semantics to pointers instead of structs makes no sense; it's not necessary and it's not sufficient. Your use case illustrates why it is not sufficient.
July 23, 2019
On Tuesday, 23 July 2019 at 14:18:27 UTC, Timon Gehr wrote:
> I think tying ownership/borrowing semantics to pointers instead of structs makes no sense; it's not necessary and it's not sufficient. Your use case illustrates why it is not sufficient.

That's as good a time as any to plug my own proposal draft:

https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088

Any thoughts?
July 23, 2019
On Tuesday, 23 July 2019 at 19:15:44 UTC, Olivier FAURE wrote:
> That's as good a time as any to plug my own proposal draft:
>
> https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088
>
> Any thoughts?

So in a nutshell, a variable with the unique qualifier ensures that there are no other references to that data during the lifetime of said variable? In other words, you can only take 1 addressOf/ref at a time?

Does it prevent more that just use-after-free?

Random idea: what about an @owned destructor? One that only runs on the original object, not on any of its copies. Which implies scope of course, so that nothing of the copies or its internals are allowed to escape.
July 23, 2019
On Tuesday, 23 July 2019 at 22:01:56 UTC, Sebastiaan Koppe wrote:
> So in a nutshell, a variable with the unique qualifier ensures that there are no other references to that data during the lifetime of said variable? In other words, you can only take 1 addressOf/ref at a time?
>
> Does it prevent more that just use-after-free?

Can you ask again on the Github thread?

I don't want to hijack this thread for 12 pages.

(also, can you expand your question? I don't get what you're asking)
1 2 3
Next ›   Last »