TODO after 0.7: DomainError() should be equivalent to DomainError(nothing)

[musm]

julia> DomainError()
WARNING: DomainError now supports arguments, use `DomainError(value)` or `DomainError(value, msg)` instead.
Stacktrace:
 [1] depwarn at .\deprecated.jl:70 [inlined]
 [2] DomainError() at .\deprecated.jl:1550
 [3] eval(::Module, ::Expr) at .\repl\REPL.jl:3
 [4] eval_user_input(::Any, ::Base.REPL.REPLBackend) at .\repl\REPL.jl:69
 [5] macro expansion at .\repl\REPL.jl:100 [inlined]
 [6] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at .\event.jl:73
while loading no file, in expression starting on line 0
DomainError(nothing, #undef)

IMO this should not throw a warning . Was this intentional so that package authors start using the new feature?

[fredrikekre]

It is an intentional deprecation warning, see #22751

[musm]

I don't see a discussion regarding the deprecation warning in the issue?

[fredrikekre]

What do you mean? Zero-arg DomainError() was deprecated in the linked PR.

julia/base/deprecated.jl

Lines 1544 to 1548 in 83007fb

	# PR #22751
	function DomainError()
	depwarn("DomainError now supports arguments, use `DomainError(value)` or `DomainError(value, msg)` instead.", :DomainError)
	DomainError(nothing)
	end

[musm]

RIght. My point is that I think DomainError() --> DomainError(nothing) i.e the previous behavior should just correspond to what is currently DomainError(nothing) .

[fredrikekre]

Why? The point of #22751 was to make DomainError more informative; so why would you opt out of that new feature?

[musm]

The new feature is great. I have no problems with it.
For error, you can opt in to adding a more descriptive error message or you can decide to leave it as error() . With DomainError, perhaps you do not care to add a message then you have to use DomainError(nothing) currently, instead of DomainError() which is what I am suggesting it be an alias for.

Considering the misunderstanding, I think this should be reopened.

[musm]

@timholy : Since you implemented this feature, care to share any insight on this?

[timholy]

Perhaps unsurprisingly, I agree with @fredrikekre ---without a deprecation warning, people won't change their code, and consequently we'll still have impenetrable errors in production code. I agree that for "quick scripting" for your own personal use, there might be times when you don't want to bother being explicit about the nature of the problem, but I think that's a minor disadvantage compared to the benefits.

The only reason it wasn't worse before was that we used to do something clever to try to be at least a bit informative, but I think that being stupid is much better than being clever when you can get away with it (and now we can).

After 1.0 comes around we could consider adding the fallback you're asking for, but because the next release would be the first (only) with a depwarn I think we have to leave it the way it is now.

[musm]

@timholy Thanks for the clarification. I think it would then be best to add something to Compat to allow using this feature in a backwards compatible manner with 0.6 .
I think this issue should receive a TODO or pending label.

[timholy]

Good idea (and I should have thought of this myself). I am pretty swamped for the next couple of days, so if you're in a hurry I'd appreciate some help. But I will put this on my TODO list if no one beats me to it.