feat: support tuple structs

[joshmossas]

It would be cool if there was a way to support tuple struct so that something like this

#[derive(Exported)]
pub struct Email(pub String);

could became

{
  "type": "string"
}

[joshmossas]

Or maybe there's a different trait that could be made to indicate something is a wrapper around a primitive type? Then we basically implement some methods to extract the primitive value out of it?

IDK just thinking out loud

[joshmossas]

Following up on this. After going through the ronky codebase, I figured out how to do this manually. You just have to implement the Exportable trait.

pub struct Email(pub String);

impl ronky::Exportable for Foo {
    fn export_internal() -> impl ronky::Serializable {
        let schema = ronky::TypeSchema::new(ronky::Types::String);
        schema
    }
}

Might be useful if there was a derive for this to do it automatically. Idk exactly what that would look like. Maybe something like this (inspired by sqlx)

#[derive(ronky::Exported)]
#[arri(type = "string")]
pub struct Email(String);

[Arthurdw]

I believe that at compile time we can just check if the subtype has the exported type and then do it that way. Will take a look into this.

[Arthurdw]

Okey, was thinking a bit more about this, and have two questions for how we want to implement this.

1. Usually when you create a wrapper tuple for a single value, its to let the programmer have an explicit "confirmation" that its of that type. As far as I've seen this type of "alias" is not yet in the Arri spec? (I do believe most languages either support this built in [such as with typescript], or can easily be done by creating a wrapper type/class/object.

2. How do we handle multi value tuples, I vaguely remember us already having had a discussion about this; but just can't remember where.

[joshmossas]

1. Usually when you create a wrapper tuple for a single value, its to let the programmer have an explicit "confirmation" that its of that type. As far as I've seen this type of "alias" is not yet in the Arri spec? (I do believe most languages either support this built in [such as with typescript], or can easily be done by creating a wrapper type/class/object.

I'm not sure "aliases" are something we should preserve over the wire. At least for me if I create a wrapper type it's because I'm planning on enforcing some kind of restrictions on the internal value OR I have methods I want to attach to that type

// ensure internal value conforms to specific requirements
struct Username(String);

impl Username {
    pub fn new(input: &str) -> Result<Self, String> {
        if input.chars().all(|c| c.is_alphanumeric()) {
            Ok(Self(raw.to_lowercase()))
        } else {
            Err("Invalid characters in username".to_string())
        }
    }
}

// wrap a type to attach methods to it
struct TaskList(Vec<String>);

impl TaskList {
    // Special method to summarize the collection
    pub fn summary(&self) -> String {
        if self.0.is_empty() {
            "Nothing to do!".to_string()
        } else {
            format!("You have {} tasks remaining.", self.0.len())
        }
    }
}

In both cases it's not easy to encode that additional information over the wire. So the client doesn't really benefit from actually knowing that the value was wrapped in a type.

I think named tuples would probably be useful if we add support for them.

// both of these instances would be nice to support
pub struct Point(f64, f64, f64);
type Point = (f64, f64, f64);

2. How do we handle multi value tuples, I vaguely remember us already having had a discussion about this; but just can't remember where.

There currently is no support. Our previous discussion is on this issue. modiimedia/arri#163

I'm in the camp of agreeing with your suggestion that we can add support but languages with no tuple support will just have to have some special structs get generated (like in go)

[Arthurdw]

Okey, that clears things up. I'll do for the child in the AST as if it were that type. And if there are multiple values will temporarily give a compile error referencing that discussion.