bug: Unable to set default on scalar definition

[tmeckel]

The following screenshot shows a valid OpenAPI YAML definition for a component which derives from a string and has a default value assigned. The default value is inherited when, the component definition is (re-)used as reference inside another component (model) definition:

With CADL 0.4.0 the following code creates a compile time error:

import "@cadl-lang/rest";

using Cadl.Http;
@service({
  title: "CADL Test Service",
  version: "1.0.0",
})
namespace CADLTestService;

@format("uuid")
scalar Id extends string = "b285d632-5603-471f-90a9-b836fa3fce7b";

model Item {
  id: Id;
  value: bytes
}

Cadl compiler v0.40.0

Diagnostics were reported during compilation:

/home/user/cadl-test/main.cadl:11:26 - error token-expected: Statement expected.
> 11 | scalar Id extends string = "b285d632-5603-471f-90a9-b836fa3fce7b";
     |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Found 1 error.

It is possible though to define/assign a default value to the id field of model Item when the field id is marked optional. But this is definitely not the same behavior as with the initially mentioned OpenAPI definition.

import "@cadl-lang/rest";

using Cadl.Http;
@service({
  title: "CADL Test Service",
  version: "1.0.0",
})
namespace CADLTestService;

@format("uuid")
scalar Id extends string;

model Item {
  id?: Id = "b285d632-5603-471f-90a9-b836fa3fce7b";
  value: bytes
}

[bterlson]

@markcowl what is the design discussion needed here? Can we schedule this?

[tmeckel]

@bterlson @markcowl any progress here? The issue lingers around for a while now? 😕

[bterlson]

There is a related issue now (#2359, for general declarations not just scalars). Sorry for the delay and I agree this issue has been around for a quite a while and is something we should support, I'll try to get something on the design agenda for next week (and will scope the issue to just scalars in case model defaults is a bridge too far for folks). /cc @markcowl

[tmeckel]

@bterlson great news! This issue is the only thing preventing me from converting all OpenAPI definitions to TypeSpec at a customer engagement. Can't wait 😊👌🏼

[bterlson]

@tmeckel we managed to discussed this briefly today, but did not come to any conclusion for scalar defaults yet. However, it was noted that the code above, which previously threw an error, does not throw! In particular, this should work fine today:

model Item {
  // id is required, this is allowed
  id: Id = "b285d632-5603-471f-90a9-b836fa3fce7b";
  value: bytes
}

Perhaps this is a viable workaround. It does mean any usages of Id will have to specify their own defaults, though. To that end, another possible workaround is to encapsulate the entire property in a model:

model ItemId {
  id: Id = "b285d632-5603-471f-90a9-b836fa3fce7b";
}

model Item {
  ... ItemId;
  value: bytes;
}

Lastly, it would be helpful to understand the underlying motivation behind the need for scalar defaults - is it about not repeating the default everywhere it is used, matching an existing OpenAPI document, etc.

[tmeckel]

@bterlson Many thanks for the detailed answer! I'll give both workarounds a shot. See which might work best for me.

About the reasons you asked:

• Firstly it's very convenient to have a default on a scalar because regardless where you use (reference) it in a component type, the property of the component type will inherit the default value. This is less error prone than repeating the default value over and over again. The second workaround (via a model) and use the spread operator to expand the model into another model gets as closest as it could I think. But it feels kinda awkward. I'm a purist in that way 😁

• Secondly the OpenAPI specs that I try to migrate to TypeSpec mostly apply this pattern i.e. defining a default value on scalars. By the way, this was the reason why I opened this issue in the first place.

[markcowl]

• link to Allow defaults for declarations #2359

[markcowl]

closing in favor of #2359