-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make keyword argument names consistent #27
Comments
Hmm. I think I understand now. The pascal case is being used to distinguish arguments that expect a type. This wasn't obvious to me. I haven't seen this convention in other Julia packages. What about making it a bit more verbose but more clear at the same time: MetaGraphsNext.MetaGraph(graph::AbstractGraph{T}; label_type, vertex_data_type, edge_data_type, graph_data, weight_function, default_weight) where T |
Yup, I came up with that convention. I kind of like it; |
Would be nice to hear other people's opinions. In my opinion, it breaks an important styling convention advocated in Julia's Base lib where variables (arguments in this case) are defined in lower case and actual types (or modules) in upper case. |
I don't have strong opinions either but I don't really like that constructor anyway, since it is not inferrable. I think #6 will be part of the answer |
Oof I didn't realize that. Even with constant propagation of the types? That seems like arguably a bug in base. |
I think types as kwargs are never inferrable, are they? Anyway, working on fixing it with a new constructor for upcoming v0.5 |
This seems to work?
|
It does but this fails for instance julia> @inferred keyword_function(; key_type=String)
ERROR: return type Dict{String, Int64} does not match inferred return type Dict{_A, Int64} where _A
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35 I think it's the same topic as this recent discourse thread https://discourse.julialang.org/t/keyword-arguments-and-type-stability/94993 |
Oh, right sure, that's not with constant propagation though. |
I documented it in more detail in #45 |
For consistency, I propose changing this constructor signature from:
to
The text was updated successfully, but these errors were encountered: