Would it be worth implementing some kind of typestate into the language?
By typestate I mean a modifiable enum.

For example:
---
enum FState
{
    none,
    read,
    write
}

struct File
{
    //maybe another keyword other than enum
    enum state = FState.none;

    void openRead(string name)
    {
        //evalutaed in a way similar to static if
        state = FState.read;
        //...
    }

    void openWrite(string name)
    {
        state = FState.write;
        //...
    }

    ubyte[] read(size_t) if (state == FState.read)
    {
        //...
    }

    void write(ubyte[]) if (state == FState.write)
    {
        //...
    }
}

unittest
{
    File f;
    static assert(f.state == FState.none);
    f.openRead("a.txt");
    static assert(f.state == FState.read);
    auto data = f.read(10);
}
---

We could use this "typestate" to implement:
 Rust style memory management in a library
 Safer Files (as shown)
 Possibly other ideas

Thoughts?

On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
> Would it be worth implementing some kind of typestate into the language?
> By typestate I mean a modifiable enum.
>
> For example:
> ---
> enum FState
> {
>     none,
>     read,
>     write
> }
>
> struct File
> {
>     //maybe another keyword other than enum
>     enum state = FState.none;
>
>     void openRead(string name)
>     {
>         //evalutaed in a way similar to static if
>         state = FState.read;
>         //...
>     }
>
>     void openWrite(string name)
>     {
>         state = FState.write;
>         //...
>     }
>
>     ubyte[] read(size_t) if (state == FState.read)
>     {
>         //...
>     }
>
>     void write(ubyte[]) if (state == FState.write)
>     {
>         //...
>     }
> }
>
> unittest
> {
>     File f;
>     static assert(f.state == FState.none);
>     f.openRead("a.txt");
>     static assert(f.state == FState.read);
>     auto data = f.read(10);
> }
> ---
>
> We could use this "typestate" to implement:
>  Rust style memory management in a library
>  Safer Files (as shown)
>  Possibly other ideas
>
> Thoughts?

This won't work in D. Everything that's static is common to each instance.
What's possible however is to use an immutable FState that's set in the ctor.

---
struct File
{
    immutable FState state,
    this(string fname, FState st){state = st}
}
---

Than you're sure that your file state can't be changed by error.
Otherwise just hide the state to set it as a private variable...

On Tuesday, 15 September 2015 at 17:57:10 UTC, BBasile wrote:
>
> This won't work in D. Everything that's static is common to each instance.
> What's possible however is to use an immutable FState that's set in the ctor.
>
> ---
> struct File
> {
>     immutable FState state,
>     this(string fname, FState st){state = st}
> }
> ---
>
> Than you're sure that your file state can't be changed by error.
> Otherwise just hide the state to set it as a private variable...

No, I'm talking about adding a new feature to the language, modifable enums(typestate).

On Tuesday, 15 September 2015 at 17:45:45 UTC, Freddy wrote:
> ...

I just thought of some corner cases and how to solve them.
---
Disallow global variable with typestate (there might be a better solution down the line).
The evaluated typestate of variables after going through  branches (if,for,etc...) must be the same.
Example
---
void func(){
    File f;
    if(someVar){
        f.openWrite("a.txt");
    }
    //error here one branch where f is none, another branch where f is open
}
---

On Tuesday, 15 September 2015 at 17:59:19 UTC, Freddy wrote:
> On Tuesday, 15 September 2015 at 17:57:10 UTC, BBasile wrote:
>>
>> This won't work in D. Everything that's static is common to each instance.
>> What's possible however is to use an immutable FState that's set in the ctor.
>>
>> ---
>> struct File
>> {
>>     immutable FState state,
>>     this(string fname, FState st){state = st}
>> }
>> ---
>>
>> Than you're sure that your file state can't be changed by error.
>> Otherwise just hide the state to set it as a private variable...
>
> No, I'm talking about adding a new feature to the language, modifable enums(typestate).

Ok, sorry I didn't know this concept so far.
So there would be a kind of 'compile-time instance' of File with a modifiable member ?

On Tuesday, 15 September 2015 at 18:10:06 UTC, BBasile wrote:
> Ok, sorry I didn't know this concept so far.
> So there would be a kind of 'compile-time instance' of File with a modifiable member ?

A simplified version of this: https://en.wikipedia.org/wiki/Typestate_analysis
Where types can have compile time state(enum) that change as they are used.

On Tuesday, 15 September 2015 at 18:15:46 UTC, Freddy wrote:
> On Tuesday, 15 September 2015 at 18:10:06 UTC, BBasile wrote:
>> Ok, sorry I didn't know this concept so far.
>> So there would be a kind of 'compile-time instance' of File with a modifiable member ?
>
> A simplified version of this: https://en.wikipedia.org/wiki/Typestate_analysis
> Where types can have compile time state(enum) that change as they are used.

Ok, I see. So type states can be used in static analysis to find possible bugs if certain states-pattern are not found. In the file example if after FState.open, fState.close is never found then a compiler could emitt a warn about a possible leak or something...wow that's pretty edgy...

On Tuesday, 15 September 2015 at 18:25:51 UTC, BBasile wrote:
> On Tuesday, 15 September 2015 at 18:15:46 UTC, Freddy wrote:
>> On Tuesday, 15 September 2015 at 18:10:06 UTC, BBasile wrote:
>>> Ok, sorry I didn't know this concept so far.
>>> So there would be a kind of 'compile-time instance' of File with a modifiable member ?
>>
>> A simplified version of this: https://en.wikipedia.org/wiki/Typestate_analysis
>> Where types can have compile time state(enum) that change as they are used.
>
> Ok, I see. So type states can be used in static analysis to find possible bugs if certain states-pattern are not found. In the file example if after FState.open, fState.close is never found then a compiler could emitt a warn about a possible leak or something...wow that's pretty edgy...

It is the same type of concept. Typestate, effect system, linear typing, behavioural typing. It is no doubt the future for type systems, but also demanding. I've tried to raise awareness about it before, but no takers:

http://forum.dlang.org/post/ovoarcbexpvrrceysnrs@forum.dlang.org

On Tuesday, 15 September 2015 at 18:30:34 UTC, Ola Fosheim Grøstad wrote:
> It is the same type of concept. Typestate, effect system, linear typing, behavioural typing. It is no doubt the future for type systems, but also demanding. I've tried to raise awareness about it before, but no takers:
>
> http://forum.dlang.org/post/ovoarcbexpvrrceysnrs@forum.dlang.org

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.

On Tuesday, 15 September 2015 at 20:01:16 UTC, Meta wrote:
> On Tuesday, 15 September 2015 at 18:30:34 UTC, Ola Fosheim Grøstad wrote:
>> It is the same type of concept. Typestate, effect system, linear typing, behavioural typing. It is no doubt the future for type systems, but also demanding. I've tried to raise awareness about it before, but no takers:
>>
>> http://forum.dlang.org/post/ovoarcbexpvrrceysnrs@forum.dlang.org
>
> 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.

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