Allow boolean literals in enums

kalrnlo commented 2 months ago

This pr adds support for boolean literals in enums, a pattern that is useful for result types

ex:

event EVENTI_RESULT = {
    from: Server,
    type: Reliable,
    call: ManyAsync,
    data: enum "succeeded" {
        true {
            from_action: enum { SCHEDULE, END, REMOVE, START, TELEPORT }
        },
        false {
            from_action: enum { SCHEDULE, END, REMOVE, START, TELEPORT },
            error: string,
        }
    },
}

sasial-dev commented 2 months ago

I'm still unconvinced with this PR, can you explain to me more around the motivation of this PR and why you can't persue the current alternatives?

kalrnlo commented 1 month ago

I'm still unconvinced with this PR, can you explain to me more around the motivation of this PR and why you can't persue the current alternatives?

The motivation is that it'd be an easy way to support result types for usecases of reporting datastore errors, roblox api errors, ect, to the client. Plus this is more intended to be a quick fix, as I'd like to not have to use "false" and "true" strings. That don't even atleast coerce into booleans in luau. And this can be replaced with a better syntax in the rewrite, and I'd like to not fully properly implement a solution as this can be just made better in the rewrite.

sasial-dev commented 1 month ago

Just out of curiosity, what syntax would you suggest in the rewrite?

On 14 Jul 2024, at 11:35 am, Kalrnlo @.***> wrote:

I'm still unconvinced with this PR, can you explain to me more around the motivation of this PR and why you can't persue the current alternatives?

The motivation is that it'd be an easy way to support result types for usecases of reporting datastore errors, roblox api errors, ect, to the client. Plus this is more intended to be a quick fix, as I'd like to not have to use "false" and "true" strings. That don't even atleast coerce into booleans in luau. And this can be replaced with a better syntax in the rewrite, and I'd like to not fully properly implement a solution as this can be just made better in the rewrite.

— Reply to this email directly, view it on GitHub https://github.com/red-blox/zap/pull/120#issuecomment-2227160384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKQU3TGVGXZG5JKCUI57S33ZMHIXRAVCNFSM6AAAAABKPWNCVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXGE3DAMZYGQ. You are receiving this because you commented.

kalrnlo commented 1 month ago

Probably a result type, something like

result<value_on_sucess, value_on_fail>

that'd then serialize into

type MyResult = {
     success: true,
     -- whatever is included in value_on_sucess, if value_on_sucess is just like a singular type ie u8 or u8 then it will create a value field
} | {
   success: false,
   -- same as the success side but using value_on_fail
}

jackdotink commented 1 month ago

result types like that will not be happening in rewrite

red-blox / zap

Allow boolean literals in enums #120