fixing sdk module generated code

[nimble galleon]

We just merged today support for Optional in the Go SDK, which results in the gql schema marking the field and/or arg as optional. I think that would fix at least the non-nullable error.

e.g.

type CustomObject struct {
  Foo Optional[string]
}

Hiding is still slightly distinct though. You technically could hack it today w/ custom MarshalJSON method, but I don't want anyone to rely on that. If there's a need for hiding (as opposed to just making optional) then we can add support for that too. I'm not sure if it's worth rushing into yet unless there's a strong need though.

[last dune]

wow never seen that syntax before!

[nimble galleon]

Yeah it's using generics 😎 Which do occasionally come in handy in cases like this

[last dune]

Actually in this case the issue is that the field should never be null in the first place. But still cool in other situations where null is a desirable value

[nimble galleon]

Yeah, we found the obvious path to support nullable fields via Optional so we went with that.

"the field should never be null in the first place" sounds like you might actually want support for default values? If so, we thought through how to support that in the Go SDK and have multiple ideas, but didn't really like any of them too much, so we just punted for now (while leaving all the doors open). Big ol thread here: https://github.com/dagger/dagger/pull/5907#issuecomment-1768953359

The problem is it's just hard to nicely retrofit support for default values on Go since Go doesn't actually support them Generics didn't save us in this case.

[last dune]

I don’t think a dagger-specific system for default field values is what we need.

First because I couldn’t easily use it myself between methods of my own module. Similar to “opts struct for optional arguments”, it bifurcates the calling experience between internal and external call.

Second because the same result can be achieved with constructors or accessors, which already exist and just need to be polished

[nimble galleon]

The motivation behind even trying all this is that graphql does have the notion of default values encoded into its schema and the idea of being able to display those defaults in, e.g., daggerverse is appealing.

However, I still agree overall with what you're saying. Some languages have the notion of defaults (e.g. python), some don't. So it feels like we inevitably will hit SDKs that just can't support the notion of defaults and will instead have to fallback on just documenting what default values are. That's essentially what we've done w/ Go so far.

So we may just need to accept our fate here

And rely on what you said in terms of constructors/accessors

[last dune]

Good point on the graphql schema

So basically, it’s a balance each SDK will need to find between 100% graphql resolution and 1
100% native DX?

[nimble galleon]

Yeah exactly, and I think what we need to be careful about is to not just add every possible feature to our language-agnostic Module APIs (and Daggerverse, which is essentially the frontend for those APIs, more or less). We don't want to get into a situation where a large number of SDKs just can't support some features and we start fracturing the ecosystem.

I don't think this is going to be a huge problem or anything, it's just something to be aware of. Default values in particular are tough because they feel right "on the border". There's lots of languages that support them, but also lots that don't.