Skip to content
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

Empty parameters error #20878

Closed
cstjean opened this issue Mar 3, 2017 · 5 comments
Closed

Empty parameters error #20878

cstjean opened this issue Mar 3, 2017 · 5 comments
Labels
won't change Indicates that work won't continue on an issue or pull request

Comments

@cstjean
Copy link
Contributor

cstjean commented Mar 3, 2017

This is a regression:

   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.0-pre.alpha.34 (2017-03-03 04:10 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit e9c1c3b (0 days old master)
|__/                   |  x86_64-apple-darwin13.4.0

julia> type Empty end

julia> f(::Empty{}) = 3
ERROR: TypeError: Type{...} expression: expected UnionAll, got Type{Empty}
@yuyichao
Copy link
Contributor

yuyichao commented Mar 3, 2017

What do you want?

@cstjean
Copy link
Contributor Author

cstjean commented Mar 3, 2017

In 0.5, Empty{} === Empty, and that's convenient for writing generic code. Besides, it's inconsistent that 0.6 accepts type Empty{} end, but Empty{} is an error in other contexts.

@yuyichao
Copy link
Contributor

yuyichao commented Mar 3, 2017

The Empty{} === Empty was seen as a bug that's fixed by the change. I don't really see why you want this in generic code since the two behaves very differently anyway. type Empty{} end is not applying type parameters and is a declaration so it is allowed. We can certainly make it a syntax error though.

@yuyichao yuyichao added the won't change Indicates that work won't continue on an issue or pull request label Mar 3, 2017
@yuyichao
Copy link
Contributor

yuyichao commented Mar 3, 2017

Ref #17943

@yuyichao yuyichao closed this as completed Mar 3, 2017
@StefanKarpinski
Copy link
Member

There is something elegant about viewing non-parametric types just as parametric types with no type parameters. It would significantly reduce the number of different kinds of things in the language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
won't change Indicates that work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

3 participants