I'm definitely not liking the mismatch of naming between annotations definition and their usage in code. It's confusing and has no presedent. If it takes a massive hack in the compiler (hardcode Primitive until next release) to do it without having to suffix annotations with Annotation, it's definitely worth it to me.

The rest is great.

@RX14 As I explain somewhere above, I was actually going to do it that way (with the Annotation suffix) to avoid cluttering the top-level namespace. Then I said "Meh, let's leave that for later" and then I immediately found a conflict, which only means that avoiding that name clash is actually something good.

Plus, again, it's how it's done in C# (only in C# you can use the full attribute name too, when using it, but I don't think we need that in Crystal, or at least we could maybe easily support it later).

But I wouldn't mind not using the suffix and waiting a bit. It's just that seeing Link there in the API docs, openning and seeing "well, it's a link attribute, not a link class or struct or module" is probably a bit confusing. It's much clear if it's called LinkAttribute. The example I gave about XML::Element and XML::ElementAttribute is algo a good one. And in my JSON::Serializable prototype there is a JSON::SerializableAttribute too, to specify strictness of parsing, and it just looks nice and consistent.

Well, that's my argument anyway :-)

I agree with RX14.

I don't know about conflicts, maybe it's good to prevent having a class and an annotation under the same name?

Or you could just make a hack that appends Annotation to all names, both in annotation and @[ ] (the latter is actually already done!)

Your argument about discerning annotations in docs is not an argument towards particular naming, it's really just a feature request for docs generator.

That said, if everyone else also dislikes this "hack", for now, I can hardcode that "Primitive" always refer to the primitive annotation, when used in annotations, and later remove that rule.

thanks, this json serialization, i dream about:

class JsonWithDefaults
  include JSON::Serializable

  property a = 11
  property b = "Haha"
  property c = true
  property d = false
  property e : Bool? = false
  property f : Int32? = 1
  property g : Int32?
  property h = [1, 2, 3]
end

if we also can generate initialize with named_tuple it would be super.

@kostya that's possible. What do you mean?

Ah, yes, that's coming soon, too. Actually, it can already be done with the addition of knowing the default value of an instance var, only that the error message if used incorrectly are a bit ugly, but nothing too terrible.

Please add an emoji in this comment for:

• 👍 to keep the requirement of the "Annotation" suffix
• 👎 to remove the requirement of the "Annotation" suffix

But if we go with 👎 , we'll have to think of another name of the attribute used on top of a type to let the parsing be strict (though now that I think about it, there was this idea of having a method you could override to handle unknown attributes, which by default would just pull.skip... so I guess this is also a 👍 for 👎 from my part 😛).

I just pushed a commit that removes the requirement that annotation names must end with "Annotation". I had to hardcode two things in annotations, Primitive and Flags, because there's Int::Primitive and File::Info::Flags, and there isn't yet a way to write ::Primitive and ::Flags in annotations, but in the next version we can use that and remove the hardcoded rule.

So builtin annotations conflicts with top level types? I would have thought they are in a separate category

They are in the same namespace, yes. Maybe later we can put them in a separate namespace, I don't know. But then, if they are in a different namespace, how would you show them in docs? That's a bit ugly.

That's why I first suggested with stick with the "Annotation" suffix, but nobody liked that. But I don't think it's a big deal, really.

We could put them in a special Crystal::Annotation namespace, and the doc generator would just have to check in this namespace

But annotations can appear under other namespaces, like in the JSON::Field example above. And you can define top-level annotations if you want to.

@kostya Hey, I found a way to do what you want with the current (0.24.2) version of Crystal 😄

class Object
  module Initialize
    def initialize(**args : **T) forall T
      {% for key in T.keys.map(&.id) %}
        {% unless @type.instance_vars.map(&.id).includes?(key) %}
          {% raise "no argument named '#{key}'" %}
        {% end %}

        @{{key}} = args[{{key.symbolize}}]
      {% end %}
    end
  end
end

class Foo
  include Initialize

  property id : Int32
  property x = 1
  property y = "foo"
end

p Foo.new(id: 1)
p Foo.new(id: 2, y: "hi")
p Foo.new(id: 2, x: 3)
p Foo.new(id: 3, x: 10, y: "hello")

And you even get a "nice" error message if you use it in a wrong way:

Error in bar.cr:27: no argument named 'z'

p Foo.new(z: 10)
      ^~~

@asterite true, what about keeping the Annotation suffix internally (but keep annotation Field & @[Field] clean)

Then it will clash with stuff that ends with Annotation.

Let's leave it like this, there's no problem, really.

bug: https://play.crystal-lang.org/#/r/40ab (easy fixable), also when mismatch type bad error message: https://play.crystal-lang.org/#/r/40ao

That mismatched type error message looks fine to me.

Things to specify can be:

• Where the annotation can be used (instance var, method, etc.)
• What's the shape of the annotation arguments (for example one could specify the named argument names at least, so you'll get a fast and nice error message when used incorrectly)

Let's get a new JSON interface based on this PR merged, then we can cut 0.25 I think.

@RX14 Based on the sheer amount of features it should be more like 0.30 🍘

@RX14 iirc you can't directly use the compiler feature until next release, so the new JSON interface will have to wait next release

But maybe we can release a 0.24.3 with annotations (only?), so that we can develop that new serialization interface for 0.25 ?

This can be done. If someone wants to work on this, let us know.

Here's a diff to do it:

diff --git a/src/json.cr b/src/json.cr
index ce859e2d7..58abfd904 100644
--- a/src/json.cr
+++ b/src/json.cr
@@ -93,3 +93,7 @@ module JSON
 end
 
 require "./json/*"
+
+{% if compare_versions(Crystal::VERSION, "0.25.0") >= 0 %}
+  require "./json/next/serialization"
+{% end %}
diff --git a/src/json/next/serialization.cr b/src/json/next/serialization.cr
new file mode 100644
index 000000000..0b14ba494
--- /dev/null
+++ b/src/json/next/serialization.cr
@@ -0,0 +1,7 @@
+module JSON
+  annotation Field
+  end
+
+  module Serializable
+  end
+end

In short:

1. We conditionally require a file based on the crystal version
2. We use the new features in this file

I put it in json/next/serialization.cr because json.cr does require "./json/*" so we must put it in a nested directory.

For specs it'll be a bit trickier.

Alternatively, there's no reason why we can't release 0.25.0 "soon", and then work on 0.26.0 next and release it soon too. I used to released maybe once a month in the past. We can release as often as we'd like (except that I'm not in charge of releasing anymore).

i add some initial work on it: #6082

It's been too long since last release... I thought the release process was supposed to be easier now 🤷‍♂️

Release is easier but it still needs someone from manas. @bcardiff should be around in a week or so to cut a release...

Maybe we should start a release PR now though, to track anything left we want in 0.25.0 and write the changelog.

Can we ask them to give you, RX14, or someone else from the core team, the ability to do releases? At this point this is the only thing that's holding us back from managing Crystal as a true open source community project.

@asterite yeah I think thats a good idea. I'd really like crystal to be disconnected from manas in terms of management. Perhaps I'll ask @bcardiff to walk me through next release?