Julia is moving in the direction of having a static sub-language and even things like enforceable interface/etc. However, if we are not VERY careful, we can lose one big advantage that Julia has, easy generic. Duck typing allows easy, intuitive generic code, for example, if you want to print foo, y…

[image] goerz: it makes unspecified assumptions about v (that it is a one-based AbstractVector of numbers) It’s a reasonable guess, but strictly speaking it actually doesn’t make those assumptions. What mynorm(v) presumes is 1) length(v) is supported, 2) getindex(v, i) is supported for i in 1…

Yeah… though you actually didn’t need an abstract vector type either. A dict would also do.

You could, but in my opinion it’s not sensible to expand to non-vectors from Vector{Float64}. Then again, it may not be sensible to expand to nonnumerical element types from Float64. That can be taken care of with function mynorm(v::AbstractVector{T}) where T<:Number, and that can replace the eltype…

I think it’s sensible to expand to tuples for example, in case someone uses tuple to represent a fixed size vector. (or dicts to represent vectors whose dimensions are named.)

[image] mike.ingold: I pray that Julia doesn’t wind up requiring the kind of clunky syntax I often see in modern C++ and other similar languages. Julia should aspire to look like Swift, not C++. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/generics Swift ha…

The swift language still requires you to write the allowed operation in advance, which can get clunky in complicated cases. C++ template allows you to generate as many instances of functions as you need.

Ok, fine, people both over- and under-estimate the implicit assumptions in their code :slight_smile: I don’t want to get too hung up on the (contrived) norm example, and I’m aware of eachindex and other ways to safely write more generic code. The point I was trying to make is that naive “generic” c…

[image] goerz: Whether some future traits system in Julia can express that kind of condition is another question (although those algebraic traits don’t seem like they would be very far out). Meanwhile, you have to rely on tests and explicit verification, and a judicious use of @assert statements…

Yes, I’m actually not sure why Julia discourages return type annotations as much as it does. Not that I’ve used them myself much. I guess partly because the syntax is cumbersome (hard to format within a maximum line width, whether that’s 92 or my preferred 80). I do share the gut feeling that more r…

[image] goerz: The point I was trying to make is that naive “generic” code has the potential for pretty catastrophic correctness bugs. That’s true, generic code isn’t as easy as just widening argument annotations. If you can reasonably determine that you won’t need your code to be generic, th…

How can we maintain easy generics in the face of demand for a “safe” language?

Internals & Design

Topic		Replies	Views
Could introducing formal interfaces be nonbreaking? Internals & Design speculative	36	1368	June 4, 2025
What interface bugs have you ran into in the ecosystem? General Usage question	35	2023	January 31, 2024
Comparison of Julia with statically typed languages New to Julia question	10	2640	June 9, 2024
Structural subtyping New to Julia question	36	3392	July 14, 2021
How is it that new Julia programmers tend to abuse type annotations? Teaching & Outreach	94	6712	January 15, 2024

How can we maintain easy generics in the face of demand for a “safe” language?

Related topics