# A most harrowing collection of Julia WATs

**URL:** <https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323>\
**Category:** General Usage\
**Tags:** wat\
**Created:** [March 2, 2022, 6:15pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323 "2022-03-02T18:15:32Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [June 20, 2022, 7:15pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/81 "2022-06-20T19:15:01Z")

</div>

Ouch, that one is tough. The kwarg semicolon is a good habit.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [June 20, 2022, 7:24pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/82 "2022-06-20T19:24:44Z")

</div>

Python:

```julia
In [2]: sum(i for i in range(1,3), start=0)
  File "<ipython-input-2-fe555a1530ed>", line 1
    sum(i for i in range(1,3), start=0)
        ^
SyntaxError: Generator expression must be parenthesized

```

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [June 20, 2022, 9:13pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/83 "2022-06-20T21:13:03Z")

</div>

Python also allows omitting the parentheses when the generator comprehension is the sole argument, so I think Python’s parser just recognizes the comma as never part of the comprehension (nested loop is written as `for i in A for j in B`). We can’t do that for Julia because `for i in A for j in B` makes a 1D array in a 2-layer loop while `for i in A, j in B` makes a 2D array (though it only seems to work if there is 1 `for`, 2+ `for`s falls back to the 1D array). So if we must allow the comma for the multidimensional comprehension, the ~~remaining way for the parser to catch the typo and throw an error is if `j=B` is not allowed in comprehensions (or for-loops, to be consistent).~~ EDIT: Actually, that won’t be enough, because `in` is also a binary operator, so `i for i in 1:3, j in 1:4` could also be mixed up with 2 separate arguments `(i for i in 1:3), (j in 1:4)`. Just so much syntax overlap that typos aren’t unambiguous enough to throw an error.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 22, 2024, 12:39am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/84 "2024-01-22T00:39:05Z")

</div>

```julia
julia> (Tuple{T,T} where T<:String) <: (Tuple{T,T} where T >: String)
false

julia> (Tuple{String,String}) <: (Tuple{T,T} where T >: String)
true

```

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 22, 2024, 1:24am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/85 "2024-01-22T01:24:57Z")

</div>

Confusing yes, but you have to remember that `Union{}` is a subtype of every type. It has no instances yes, but the type exists.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 22, 2024, 10:16am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/86 "2024-01-22T10:16:35Z")

</div>

> [@Raf](#):
>
> ```julia
> julia> (Tuple{T,T} where T<:String) <: (Tuple{T,T} where T >: String)
> false
> 
> ```

Would someone kindly explain why this is?

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 22, 2024, 10:24am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/87 "2024-01-22T10:24:04Z")

</div>

I think Stefan means that because `Union{}` is a possible subtype of `String` and I’ve used the `>:` superset operator on the right hand side, the middle `<:` has to return `false` as it doesn’t always hold theoretically, because

```julia
julia> Union{} >: String
false

```

Even though in practice there is no possible subtype of `String`, and it practically holds in all real cases.

I don’t understand why this is useful… but I guess some type theoretic reason the compiler needs the `Union{}` bottom.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 22, 2024, 10:51am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/88 "2024-01-22T10:51:43Z")

</div>

I still don’t get it, since `Union{}` is not a valid tuple field type:

```julia
Tuple{Union{},Union{}}
ERROR: Tuple field type cannot be Union{}

```

so it should be ignored for the purposes of the expression above.

I think this is a bug and you should open an issue. (But let’s wait for others, I am not an expert on darker corners of the type system).

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [January 22, 2024, 11:00am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/89 "2024-01-22T11:00:30Z")

</div>

> [@Tamas\_Papp](#):
>
> Would someone kindly explain why this is?

EDIT: this is now fixed (in a PR, soon to be merged, I guess). See [Intransitivities in subtyping](https://discourse.julialang.org/t/intransitivities-in-subtyping/109266)

It’s AFAIK not possible, even in theory, to implement the subtyping (`<:`) so that it always returns `true` when a human would expect that.

The discussion in this issue is relevant: [suboptimal subtyping for `UnionAll` and `Union` · Issue #52818 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/52818)

Quoting vtjnash, emphasis mine:

> The type system is generally _permitted to return false whenever it wants to, provided only that it preserves transitivity_.

You might also be interested in the _Julia subtyping_ paper:

> _Julia Subtyping: A Rational Reconstruction_ . Proceedings of the ACM on Programming Languages, 2018, 27, ⟨ **10.1145/3276483** ⟩. ⟨ **hal-01882137** ⟩

Excerpt:

> _Unprovable judgments_. Julia’s subtype algorithm, and in turn our formalization, cannot prove all judgments expected to hold.

> [@Tamas\_Papp](#):
>
> I still don’t get it, since `Union{}` is not a valid tuple field type:
> 
> ```julia
> Tuple{Union{},Union{}}
> ERROR: Tuple field type cannot be Union{}
> 
> ```

This is actually a recent bug, introduced in v1.10, see ["Tuple field type cannot be Union{}" error in 1.10rc · Issue #52385 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/52385)

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [January 22, 2024, 12:27pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/90 "2024-01-22T12:27:54Z")

</div>

A relevant PR, to expand the `<:` doc string:

> <https://github.com/JuliaLang/julia/pull/53001>
>
> Clear up some things, state some expected properties and limitations, add cross-…references, add an academic reference, add more examples.

---

<div class="post-metadata">

**Author:** ![Larbino1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/larbino1/32/37831_2.png) [@Larbino1](https://discourse.julialang.org/u/Larbino1)\
**Post date:** [January 22, 2024, 2:22pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/91 "2024-01-22T14:22:26Z")

</div>

This thread/post would be a great source of cases for a “clippy” style linter. Rusts linting is top class and we should definitely learn from it, to help avoid errors that people might stumble upon, but that can’t be fixed by changing syntax/parsing.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [January 22, 2024, 2:32pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/92 "2024-01-22T14:32:03Z")

</div>

> [@Larbino1](#):
>
> This thread/post would be a great source of cases for a “clippy” style linter.

In principle I agree with you, but TBH I’m not sure if VS Code ever pointed out an actual issue to me (except syntax errors), while it sadly points out many false positives. IMO the linting for Julia needs to drastically cut down on the false positives if it’s to be useful, instead of just ignored. Although, I think I may actually have already disabled some of the linting options in the extension settings, so maybe my experience is outdated.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 25, 2024, 5:13pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/93 "2024-01-25T17:13:56Z")

</div>

Split this topic on January 25, 2024, 5:13pm UTC

10 posts were split to a new topic: [Intransitivities in subtyping](https://discourse.julialang.org/t/intransitivities-in-subtyping/109266)

---

<div class="post-metadata">

**Author:** ![Larbino1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/larbino1/32/37831_2.png) [@Larbino1](https://discourse.julialang.org/u/Larbino1)\
**Post date:** [January 22, 2024, 2:34pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/94 "2024-01-22T14:34:29Z")

</div>

I completely agree, the current VSCode linter needs work. I’m just a user, I’ve never worked on linting, and I appreciate there must be huge number of challenges, especially in a much more dynamic/flexible language like Julia.

However, I think linting is a very useful tool and its a shame that we don’t seem to have a good linting ecosystem.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 22, 2024, 4:25pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/97 "2024-01-22T16:25:39Z")

</div>

> [@Tamas\_Papp](#):
>
> I think this is a bug and you should open an issue.

Given the refusal to construct `Tuple{Union{},Union{}}` I would agree with that. Otherwise I don’t see how that subtype check is false.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [January 23, 2024, 1:45am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/98 "2024-01-23T01:45:36Z")

</div>

Here’s a confusing one, from the _Julia subtyping_ paper:

```julia-repl
julia> (Vector{T} where {S,T}){Int} # WAT?
Vector{Int64} (alias for Array{Int64, 1})

```

Naively one would expect for the type application to apply `Int` to the unused type parameter. However the unused type parameter seems to have already been deleted/rewritten out by that point.

I think unused type parameters are, thankfully, already caught by the static analysis in VS Code.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [January 23, 2024, 6:20am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/99 "2024-01-23T06:20:12Z")

</div>

> [@nsajko](#):
>
> Here’s a confusing one, from the _Julia subtyping_ paper:
> 
> ```julia-auto
> julia> (Vector{T} where {S,T}){Int} # WAT?
> Vector{Int64} (alias for Array{Int64, 1})
> 
> ```

The unused S is just discarded at runtime:

```julia-auto
julia> Vector{T} where {S,T}
Vector (alias for Array{T, 1} where T)

```

Also occurs in where statements with non-UnionAll types:

```julia-auto
julia> Integer where {A,B,C,D}
Integer

```

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 23, 2024, 10:08am UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/100 "2024-01-23T10:08:28Z")

</div>

```julia
julia> struct A{T,S} end
julia> bar(::Union{A{T,2}, A{1,T}}) where T = T
julia> bar(A{1,2}())
1

```

I think I would prefer if that was an ambiguity error (or at least a warning when running under special command-line flags or debug builds), such as e.g.

```julia
julia> baz(::A{T,2}) where T = T
baz (generic function with 1 method)

julia> baz(::A{1,T}) where T = T
baz (generic function with 2 methods)

julia> baz(A{1,2}())
ERROR: MethodError: baz(::A{1, 2}) is ambiguous.

```

Ambiguous pattern matching of existential type parameters is imo just as bad as ambiguous method dispatch.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 23, 2024, 1:51pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/102 "2024-01-23T13:51:09Z")

</div>

This thread has been going on for 2 years and has become an unorganized grab-bag of unrelated discussions. As such, it’s a prime case for [Time limits for unfocused discourse threads?](https://discourse.julialang.org/t/time-limits-for-unfocused-discourse-threads/106739).

---

<div class="post-metadata">

**Author:** ![jonniedie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jonniedie/32/12842_2.png) [@jonniedie](https://discourse.julialang.org/u/jonniedie)\
**Post date:** [January 25, 2024, 5:51pm UTC](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323/103 "2024-01-25T17:51:37Z")

</div>

I very much disagree. Threads like this and [What is in your startup.jl?](https://discourse.julialang.org/t/what-is-in-your-startup-jl/18228) are best when they’re continuously added to. I pretty regularly come back to both of these just to see what people have added. It’s fun – maybe not to everyone, but to some people. And it’s only wasting the time of the people who choose to come here and have their time wasted. It might not be “productive”, but that doesn’t mean there isn’t any value in it.

Do these sometimes spark full-fledged discussions that are unrelated to the main topic? Yes. Should those discussions be migrated to their own topic? Yeah, probably. But that’s just natural conversation. If we want this to work more like StackOverflow, we should be there instead.

[Previous page](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323.md?page=4)

[Next page](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323.md?page=6)