Base.@kwdef for v1.0?

Internals & Design
1

Hi :wave:

I stumbled on Base.@kwdef on Julia v1.1 and find it quite helpful and reduces a ton of boilerplate for my large types with lots of default values.

I started using it in my packages, but tests fail on Julia v1.0. It turns out (I guess), Base.@kwdef was introduced in Julia v1.1.

Is there a chance this could get backported (if that is the right word?) to Julia v1.0?

I’m hesitant to use it if it means I need to use Compat.jl or something :thinking:

2 Likes
2

FWIW, I think you should just depend on 1.1, eg specify something like

[compat]
julia = "1.1"

in your Project.toml. This is what I am doing for almost all of my packages (yes, I love Base.@kwdef too, and I am removing a lot of workarounds as the 1.1 compiler is so much smarter than 1.0).

Generally, it is my impression that features will not be backported, just critical bug fixes. Which is as it should be: with a lot of backports, one could hardly commit to keep a branch “stable”.

See the some discussion starting here.

2 Likes
3

@anon67531922 - according to semantic versioning, a minor release is backward compatible. So there is no reason not to upgrade to 1.1 :slight_smile:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.
1 Like
4

Thanks @Tamas_Papp :+1:

That is an interesting trail of posts. This comment here is particularly interesting:

I think we can hope that when 1.2 comes out that 1.1 becomes the new LTS branch and then we get all the benefits of 1.1 without needing to worry about 1.0 :pray:

5

Hi @tk3369 :wave:

Yeah. I am already working on v1.1 and love it. The issue is there are features in v1.1 that I want to use, e.g. Base.@kwdef, that work on v1.1. but NOT on v1.0 so if I use those features, I need to worry about people still using v1.0 :blush:

6

I think that’s the wrong way to think about it. You are writing free software, effectively donating your time and effort to other people who use the result. Your time and resources are finite, so you should be economizing on them.

If using new features of Julia makes your life a bit more convenient, you will have time to work on other stuff that benefits your users. Sensible users would recognize that they should do their part by keeping up with the latest stable release (with a reasonable lag, eg 1-2 weeks).

1 Like
7

I totally agree with Tamas. However, if you must have 1.0, then you can use Parameters.jl whose @with_kw is essentially the same as @kwdef. You could require Parameters for 1.0 and do const @kwdef = Parameters.@with_kw and in 1.1 const @kwdef = Base.@kwdef.

2 Likes
8

Base.@kwdef definitely exist in 1.0:

help?> Base.@kwdef
  @kwdef typedef


  This is a helper macro that automatically defines a keyword-based constructor for the type declared in 

...

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> Base.@kwdef struct Foo
             a::Int = 1         # specified default
             b::String          # required keyword
         end
  Foo

...

julia> versioninfo()
Julia Version 1.0.0

but maybe has gotten new features / bugfixes in 1.1.

9

It did, if I remember correctly it was for handling parametric types. The macro exists in 1.0, but it is not practically useful outside a few narrow contexts.

10

Ah. Ok. That makes sense :+1:

I had some tests that failed due to Base.@kwdef on v1.0, but passed on both v1.1 and nightly.

11

That’s the PR which extended kwdef: https://github.com/JuliaLang/julia/pull/29316

2 Likes
12

I think we should use Compat more for this kind of features, just like we did before 1.0.

1 Like
13
1 Like