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

const(Object)ref #3

Closed
wants to merge 22 commits into from
Closed

const(Object)ref #3

wants to merge 22 commits into from

Conversation

michelf
Copy link
Contributor

@michelf michelf commented Feb 6, 2011

This branch implements the const(Object)ref syntax as proposed in bug 5325. It also add many tests including type deduction. It also successfully compile druntime and Phobos. Phobos needs a very minor patch for the Rebindable unittest to pass, see branch const-object-ref in my Phobos repository.

How it works at a glance:

  • All types now have a head() member which returns a pointer to a type representing their head. Non-class types have no distinct head modifiers, so their head() is just a pointer to themselves. For classes, head() returns a ClassRefSuffix type with the proper modifiers for the head, except when the head modifiers are the same as the class itself in which case the class type itself is returned.
  • mutableOf() now return a class type where only the head modifier was made mutable. If you want a mutable reference to an immutable class, you just do classType->immutbleOf()->mutableOf() -- immutableOf will make both the reference and the class immutable (because of transitivity), and mutableOf will then make only the head mutable.
  • All parts of the compiler which need to know about the head-modifiers have been changed to use head()->mod.

Of note:

  • Type deduction is not working in all cases, but overall it seems like it works better than for pointer types. This part will surely need to be revised, but it's probably best to address the problems with pointers first (issue 5531) since this could affect how things get fixed for classes.
  • inout tests are commented out because inout doesn't work well yet for non-class parameters, and fixing inout is beyond the scope of this patch.

@michelf
Copy link
Contributor Author

michelf commented Feb 27, 2011

Added a pull request for corresponding Phobos changes:
dlang/phobos#15

@WalterBright
Copy link
Member

Thanks for all the hard work you've done on this. I haven't been able to get to it yet.

static assert(c!(Object));
static assert(c!(const(Object))); // FIXME: should not match (const ref)
static assert(c!(const(Object)ref));
static assert(c!(immutable(Object))); // FIXME: should not match (immutable ref)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't these correct? They implicitly convert, unless I'm missing something.
const(Object) -> const(Object)ref
and
immutable(Object) -> const(Object) -> const(Object)ref

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, they implicitly convert if you assign from one variable to another, but if you want to pass the value by ref it won't work.

It's not entirely clear to me either what should work and what shouldn't. The tests with pointers below do match in these two cases, but they also match the shared variant which is obviously wrong. The language definition regarding templates isn't clear on that either, it was obviously written before const was added. So what is a bug and what isn't?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's not clear to me either.
As far as I can tell template deduction should ignore ref parameters, and this should be handled at a higher level. Of course at the moment, it's barely handled at all for template functions with ifti.
Are any implicit conversions allowed to be passed to ref parameters? (ignoring current bugs)
I think it will be safe to allow T : U to match for any implicit conversion once these bugs are fixed (and do ref parameter matching as something like T* : U*)
I agree the shared conversion is completely wrong. I think it's related to bug 5493, as the recursive deduction of types does not keep track of how many indirections deep it is, moving through something like:
shared(int)* : const(int)*
shared(int) : const(int)
which implicitly converts.

@michelf
Copy link
Contributor Author

michelf commented May 28, 2012

This pull request is no longer being maintained and cannot be merged without more work being done to it. I'm not going to do that work at this point, so I'm closing it.

@michelf michelf closed this May 28, 2012
braddr pushed a commit to braddr/dmd that referenced this pull request Oct 22, 2012
andralex added a commit that referenced this pull request Jul 14, 2016
Trivial: switch to Ddoc module comment #3
UplinkCoder referenced this pull request in UplinkCoder/dmd Aug 13, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Aug 13, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Aug 31, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Aug 31, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 1, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 1, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 4, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 4, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 19, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 19, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 25, 2016
UplinkCoder referenced this pull request in UplinkCoder/dmd Sep 25, 2016
skl131313 pushed a commit to skl131313/dmd that referenced this pull request Jan 26, 2017
marler8997 added a commit to marler8997/dmd that referenced this pull request Dec 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants