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.
[...]
Article about this in C# and F#:
http://enterprisecraftsmanship.com/2015/09/28/c-and-f-approaches-to-illegal-stat
On Wednesday, 16 September 2015 at 18:41:33 UTC, Ola Fosheim
Grøstad wrote:
I don't think this is possible to establish in the general
case. Wouldn't this require a full theorem prover? I think the
only way for that to work is to fully unroll all loops and hope
that a theorem prover can deal wi
On Wednesday, 16 September 2015 at 18:01:29 UTC, Marc Schütz
wrote:
typestate(alias owner) {
this.owner := owner; // re-alias operator
this.owner.refcount++;
}
I don't think this is possible to establish in the general case.
Wouldn't this
On Wednesday, 16 September 2015 at 17:15:55 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 17:03:14 UTC, Marc Schütz
wrote:
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 managemen
On Wednesday, 16 September 2015 at 17:15:55 UTC, Ola Fosheim
Grøstad wrote:
dostuff(r);
(File f, FileRef r) = f.unborrow(r);
Of course, files are tricky since they can change their state
themselves (like IO error). Doing that statically would require
some kind of branching mechanism with a t
On Wednesday, 16 September 2015 at 17:03:14 UTC, Marc Schütz
wrote:
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.
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.
Yeah, I thought about type-states as a way of implementing
borrowi
On Wednesday, 16 September 2015 at 16:24:49 UTC, Idan Arye wrote:
No need for `reinterpret_cast`. The `close` function is
declared in the same module as the `File` struct, so it has
access to it's private d'tor.
True, so it might work for D. Interesting.
On Wednesday, 16 September 2015 at 15:57:14 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 15:34:40 UTC, Idan Arye
wrote:
Move semantics should be enough. We can declare the destructor
private, and then any code outside the module that implicitly
calls the d'tor when the var
On Wednesday, 16 September 2015 at 15:34:40 UTC, Idan Arye wrote:
Move semantics should be enough. We can declare the destructor
private, and then any code outside the module that implicitly
calls the d'tor when the variable goes out of scope will raise
a compilation error. In order to "get rid
On Wednesday, 16 September 2015 at 14:34:05 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 16 September 2015 at 10:31:58 UTC, Idan Arye
wrote:
What's wrong with two `open()`s in a row? Each will return a
new file handle.
Yes, but if you do it by mistake then you don't get the
compiler to check
On Wednesday, 16 September 2015 at 10:31:58 UTC, Idan Arye wrote:
What's wrong with two `open()`s in a row? Each will return a
new file handle.
Yes, but if you do it by mistake then you don't get the compiler
to check that you call close() on both. I should have written
"what if you forget cl
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
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 at
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
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
On Wednesday, 16 September 2015 at 05:51:50 UTC, Tobias Müller
wrote:
Ola Fosheim Grøstad 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-d
Ola Fosheim Grøstad 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?
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
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.
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?
Ola Fosheim Grøstad 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
Tobias Müller 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 B
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-g
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
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:
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
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:/
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
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
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,
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
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 s
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)
32 matches
Mail list logo
