“Humans are very stupid so make sure to use childish analogical writing”

Just what the world needed, excel implemented In an excel script. Thanks sloppers

Why, this could be a fun excrement for sure

I pray there will be a light at the end of the tunnel soon, but I doubt it is possible without major political change.

why not just create a wrapper type for the payload that is returned by func1 and func2 takes it as a parameter?

Because you may want to share certain behaviors between the two wrapper types via generic impl

That sounds like a Wrapper<Func1Payload>, not a Ticket<Func1Call> that will become an extra parameter of Func2 whose only purpose is to prove to Func2 that you called Func1.

Maybe I misunderstood something.

Okay let's say you had three functions

func1(foo_0) -> bar0

func2(foo_1, foo_2) -> bar1

func3(foo_3, foo_3) -> bar2

And you wanted to make sure that func2 and func3 can only be called after func1 has been called.

A wrapper on the output of func1 here would be awkward because then you return Wrapper<Func1Done>(bar0). But func2 does not even need a bar0 and neither does func3.

So the solution is to return (bar0, Wrapper<Func1Done>) from func1 where

struct Wrapper<T>(//cheating ())

I think this is a good argument for the Ticket, however, for the case where these three functions are generically useful, not just used in this specified order, I would write a specific function, just copy-paste of the bodies capturing the required ordering as an implementation detail.

Obviously if you are operating in a wide, concurrent async system then the Ticket and separate function calls is the better mechanism for the ordering.

That's fair but then you have to make your args a struct for this bespoke purpose; an anti pattern.

Also, many other functions can depend on the ticket from func_1. So making the ticket separate and generic on the process is the right (imo) solution here.

Why should this be such a bad anti pattern? Sure, a function might not need to work on the entire data model, but with pass by reference, does it matter that much? I dont see big negatives by using struct args, possibly wrapped in some typestate.

On the other hand, doesnt seprating args and typestate defeat the purpose? Since they can now be constructed separately.

It's because I use Ticket<T> in situations where I need to remember (force other users to use) a sequence of functions that take arguments not necessarily constructed by others.

async fn write_buffer(buf: &mut [u8]) -> Ticket<BufferWritten>

//Best that it it's own function for readability

async fn complex_counter_logic(ctr: Arc<AtomicUsize>, ticket: Ticket<BufferWritten>) -> Ticket<ComplexCounterLogic>

//One could also place all the data in a giant struct and move that across all functions but that eventually leads to struct bloat unless we use an explicit state machine, in which case type state is better

Why not return a WrittenBuffer<'a>? This can also be used to specify the methodset allowed or required plus any further type transitions out of WrittenBuffer, for example into a new CompressedBuffer, or similar patterns.

That's fair, but you would have to make sure that write_buffer is the only function that can create a WrittenBuffer<'a>. And then the second function could take a WrittenBuffer<'a> as an unused arg

I mean there's many ways to skin a cat!

I think my point is that types and “typestate” do not need to be two separate things. For example, in the Lua API for C, one obviously requires a Lua context handle in order to perform any other operations, so the handle must be obtained first, by calling the context initializer function. There is no need for an extra “typestate” parameter since the dependency is explicit and enforced.

My Ticket example is not the standard type state pattern. Usually the State is shimmied in as a generic into the type being mutated

There is no cost imposed by wrapping a type in a struct to enforce a dependency.

Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.

I agree. I mention this briefly in one of the footnotes. There are some tasks that greatly benefit from the mouse (e.g photo editing tasks where arbitrary region point and click is required).

This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.

What's specifically is the limitation?

There is no moral imperative to help the world reach an optimum. Rather, the world is full of competing interests.

You’re presuming here that CEOs cause companies to make profit instead of serving as a scapegoat for their often unavoidable market dynamics (at best).

In a 1-person company, who or what generates a profit?

One person isn't a company. Legally maybe, but there's no point in a company if you can profitably do all the labor yourself.

I may be able to do all the labor myself, but need investors because I can’t afford the capital.

I may be able to do all the labor myself, but want to ensure continuity beyond my ability or interest to do the labor myself. (Sometimes this is by my wish; sometimes by the wish of consumers of my service.)

I may be able to do all the labor myself, but not want to expose my entire net worth to the financial obligations of the company.

There are plenty of cases where a single person company makes good sense.

At what point does a company become a company if one person doesn’t make a company? What’s the threshold for non-labor where a company becomes a company?

I'd start with division of labor as a minimum.

There are holding companies with zero employees. They typically pay a management fee to someone.

Attorneys commonly do this.

“I am actually the CEO of my basement office business” was not the corporate topology I was addressing with my comment.

Welcome to the future of the internet. Donate some social credits to a starving open-source maintainer and we might let you off with a warning

The prevailing mentality seems to be that if we don’t win in the next three quarters it will be such a catastrophe that there won’t be a future at all.

In my experience xhigh very often produces better results on the first try to the extent that the less cogitation-enthused settings actually waste more in the long run.