Support default values for schema properties

[PARAIPAN9]

Motivation

• Fixes Support default values for schema properties #66.

Modifications

• Update schema translations.

Result

• Schema translations will support default values.

Test Plan

• Run test suite. TODO - Write more tests.

[PARAIPAN9]

Opened it as a draft. Not sure if I addressed correctly all the schema translations. I'd appreciate your input so far.

[czechboy0]

Hi @PARAIPAN9,

thanks for starting on this work! I think roughly the direction is good, but it's difficult for me to fully understand the impact of the changes on the generated code.

I wonder if we could flip it, and first just write a bunch of snippet tests (that'll fail, initially), that show what code we want generated? That's where we can discuss which defaults we want to support, and which ones we might want to hold off on for now. I'm seeing defaults for things like typealiases and arrays and I realize I'm not sure I know how those should work.

Note that you might also want to add a sublist under default here:

swift-openapi-generator/Sources/swift-openapi-generator/Documentation.docc/Articles/Supported-OpenAPI-features.md

Line 171 in 7893a6c

- [ ] default

Write out all the schema types we support in general, and have an empty box for each of them. Then we can better track which schemas we have a plan/implementation for, and which ones don't support defaults yet.

How does that sound?

[PARAIPAN9]

Sounds perfect @czechboy0!! Thank you very much for your guidance!!

[PARAIPAN9]

I've created this table to show you how defaults would be generated according to the changes from this PR to give you a better undestanding. Feel free to comment.

	OpenAPI Document	Generated Code	Comments
Object Schema			...
Array Schema			...
Primitive Schemas			...

[simonjbeaumont]

The object schema defaults look sensible (default parameter for the init).

For the other two, the static default property is on Components.Schemas which is probably wrong. How would multiple of these compose? Also, because we're generating type aliases for these, it's not even clear to me where the default should go.

It wouldn't make sense, for example, to add an extension because we'd be adding an extension to e.g. [Swift.Bool]. Had we been generating nominal types for these, we might have been able to do it.

What I was thinking is that we don't generate this static property but we propagate the default value from the document to the places where the type is used as a parameter. E.g. anything that was generating a parameter of this type would continue to do so, but also include a default value for that parameter.

WDYT?

[PARAIPAN9]

Yes, it makes sense. Thanks!!

[czechboy0]

We already have something similar for optionality of values - they affect the call site of the type, rather than the definition of the type. So there's some precedent at least.