September 15, 2015
On Tuesday, 15 September 2015 at 20:14:11 UTC, Ola Fosheim Grøstad wrote:
> Having a simple core language is usually a good idea. I see now in the rust forums that people use the borrow checker for other things than memory, like tracking what thread you are in:
>
> https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859/7

Not actually sure if that does depend on the borrow checker though... My knowledge of Rust is superficial... But nevertheless, it will be interesting to see how people use the rust type system for other things than memory.


September 15, 2015
Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
> On Tuesday, 15 September 2015 at 20:01:16 UTC, Meta wrote:
>> [...]
>> If I remember correctly Rust *did* have a typestate system very > early
>> on but it was done away with in favour of the borrow > checker.
> 
> Yeah, I've seen the Rust creator write about how they started out with all whistles and bells with the intent of having a full blow effect system. Then realized that they had to make things simpler and focus on memory management because that was the most critical feature. Probably a wise strategy to go for simplicity and hit version 1.0 sooner.

I think they settled for a simpler library solution using a marker type (I
think it was called Phantom type) as template parameter and then using
local shadowing to emulate mutable type state. Multiple variables with same
name but different (marker) type.
There's a Blog post somewhere but I can't find it atm.

Maybe that's also possible for D?

Tobi
September 15, 2015
Tobias Müller <troplin@bluewin.ch> wrote:
> I think they settled for a simpler library solution using a marker type (I
> think it was called Phantom type) as template parameter and then using
> local shadowing to emulate mutable type state. Multiple variables with same
> name but different (marker) type.
> There's a Blog post somewhere but I can't find it atm.

Ok found it: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/

Tobi
September 15, 2015
On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller wrote:
>> There's a Blog post somewhere but I can't find it atm.
>
> Ok found it: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/

But that is for runtime detection, not compile time?


September 15, 2015
On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
>  Rust style memory management in a library

Wait nevermind about that part, it's harder than I thought.
September 15, 2015
On Tuesday, 15 September 2015 at 21:44:25 UTC, Freddy wrote:
> On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
>>  Rust style memory management in a library
>
> Wait nevermind about that part, it's harder than I thought.

All hope might not be lost, something like this MIGHT work,but i'm am sure I am missing some kind of detail.
---
//doesn't actually compile
struct MutBorrow(T, bool usable_ = true)
{
    private T** ptr;
    enum usable = usable_;
    static if (usable)
    {
        @disable this();
        ref T use()
        {
            return **ptr;
        }
    }
    //...
}

struct Unique(T)
{
    private T* ptr;

    alias user = null;

    ~this()
    {
        static assert(user is null);
        free(ptr);
    }

    auto giveMut(alias local)()
    {
        static assert(is(user : null)));
        user = local;
        local.usable = true;
        local.ptr = &ptr;
    }

    auto takeMut(alias local)()
    {
        static assert(local == user); //is there a proper way to compare alias?
        user = null;
        local.usable = false;
    }

    static if ( /+user not null+/ )
    {
        ref T use()
        {
            return *ptr;
        }
    }
}
---
September 16, 2015
Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
> On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller wrote:
>>> There's a Blog post somewhere but I can't find it atm.
>> 
>> Ok found it: > http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/
> 
> But that is for runtime detection, not compile time?

Not as far as I understand it.
The marker is a type, not a value. And it's used as template param.
But you need non-copyable move-only types for it to work.

In D it would probably look like:

File!Open file = open(...);
File!Closed file = close(file);

Tobi
September 16, 2015
On Wednesday, 16 September 2015 at 05:51:50 UTC, Tobias Müller wrote:
> Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>> On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller wrote:
>>>> There's a Blog post somewhere but I can't find it atm.
>>> 
>>> Ok found it: > http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/
>> 
>> But that is for runtime detection, not compile time?
>
> Not as far as I understand it.
> The marker is a type, not a value. And it's used as template param.
> But you need non-copyable move-only types for it to work.

Yes... But will it prevent you from doing two open() in a row at compiletime?

September 16, 2015
On Wednesday, 16 September 2015 at 06:25:59 UTC, Ola Fosheim Grostad wrote:
> On Wednesday, 16 September 2015 at 05:51:50 UTC, Tobias Müller wrote:
>> Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>> But you need non-copyable move-only types for it to work.
>
> Yes... But will it prevent you from doing two open() in a row at compiletime?

Nevermind, it needs linear typing, not only move semantics...

September 16, 2015
On Wednesday, 16 September 2015 at 06:25:59 UTC, Ola Fosheim Grostad wrote:
> On Wednesday, 16 September 2015 at 05:51:50 UTC, Tobias Müller wrote:
>> Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>>> On Tuesday, 15 September 2015 at 20:34:43 UTC, Tobias Müller wrote:
>>>>> There's a Blog post somewhere but I can't find it atm.
>>>> 
>>>> Ok found it: > http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/
>>> 
>>> But that is for runtime detection, not compile time?
>>
>> Not as far as I understand it.
>> The marker is a type, not a value. And it's used as template param.
>> But you need non-copyable move-only types for it to work.
>
> Yes... But will it prevent you from doing two open() in a row at compiletime?

What's wrong with two `open()`s in a row? Each will return a new file handle.