Rick Mann <rmann-d-lang latencyzero.com> writes:

I didn't get any responses in D.learn for this question, so I decided maybe it
was advanced enough for this group.

I was hoping I could do this:

typedef void* CFTypeRef;
typedef CFTypeRef CFStringRef;

class DCFObject
{
  CFTypeRef getRef() {}
}

class DString : DCFObject
{
  CFStringRef getRef() {}
}

But the compiler gives me:

src/d/darbon/corefoundation/DString.d:32: function
darbon.corefoundation.DString.DString.getRef of type CFStringRef() overrides
but is not covariant with darbon.corefoundation.DCFObject.DCFObject.getRef of
type CFTypeRef()

From what I gather in the docs, CFStringRef is derived from CFTypeRef, so this
should be acceptable. Am I missing something?

TIA,
Rick

Bill Baxter <dnewsgroup billbaxter.com> writes:

Rick Mann wrote:
 I didn't get any responses in D.learn for this question, so I decided maybe it
was advanced enough for this group.
 
 I was hoping I could do this:
 
 typedef void* CFTypeRef;
 typedef CFTypeRef CFStringRef;
 
 class DCFObject
 {
   CFTypeRef getRef() {}
 }
 
 class DString : DCFObject
 {
   CFStringRef getRef() {}
 }
 
 But the compiler gives me:
 
 src/d/darbon/corefoundation/DString.d:32: function
darbon.corefoundation.DString.DString.getRef of type CFStringRef() overrides
but is not covariant with darbon.corefoundation.DCFObject.DCFObject.getRef of
type CFTypeRef()
 
 From what I gather in the docs, CFStringRef is derived from CFTypeRef, so this
should be acceptable. Am I missing something?

That's not the message I get from reading the docs.  What I see:
  "Strong types are semantically a distinct type to the type checking 
system, for function overloading, and for the debugger."
  (http://www.digitalmars.com/d/declaration.html)

Basically CFStringRef becomes something completely new and different 
from CTypeRef as far as the compiler is concerned.

What are you reading that makes you think CFStringRef is "derived" from 
CFTypeRef?

--bb

Stewart Gordon <smjg iname.com> writes:

Bill Baxter Wrote:

 Rick Mann wrote:
 I didn't get any responses in D.learn for this question, so I 
 decided maybe it was advanced enough for this group.
 
 I was hoping I could do this:
 
 typedef void* CFTypeRef;
 typedef CFTypeRef CFStringRef;


<snip>
 From what I gather in the docs, CFStringRef is derived from 
 CFTypeRef, so this should be acceptable.  Am I missing something?

 
 That's not the message I get from reading the docs.  What I see:
 "Strong types are semantically a distinct type to the type checking 
 system, for function overloading, and for the debugger."
 (http://www.digitalmars.com/d/declaration.html)

Are you taking this to mean distinct from each other or distinct from their
underlying types?  If the latter, this is much the same a class being different
from its base class.

 Basically CFStringRef becomes something completely new and 
 different from CTypeRef as far as the compiler is concerned.

What are you reading that makes you think it's _completely_ different?  This
compiles:

----------
typedef void* CFTypeRef;
typedef CFTypeRef CFStringRef;

void func(CFTypeRef p) {}

void main() {
    CFStringRef s;
    func(s);
}
----------

 What are you reading that makes you think CFStringRef is "derived" 
 from CFTypeRef?

Probably that typedefs implicitly convert to their underlying types.  Moreover,
typedefs behave in a number of respects very similarly to enums, for which the
notation

    enum Enum : int

suggests type derivation as with classes.

Stewart.

Rick Mann <rmann-d-lang latencyzero.com> writes:

Bill Baxter Wrote:

 What are you reading that makes you think CFStringRef is "derived" from 
 CFTypeRef?

It seems to be implied by the "Implicit Conversions" section of
<http://www.digitalmars.com/d/type.html>:

"A typedef or enum can be implicitly converted to its base type, but going the
other way requires an explicit conversion. "

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Rick Mann wrote:
 Bill Baxter Wrote:
 
 What are you reading that makes you think CFStringRef is "derived" from 
 CFTypeRef?

 
 It seems to be implied by the "Implicit Conversions" section of
<http://www.digitalmars.com/d/type.html>:
 
 "A typedef or enum can be implicitly converted to its base type, but going the
other way requires an explicit conversion. "

Implicitly convertible doesn't mean a type is a subtype of another. 
Altough in this case of typedef and enums I think they could be subtypes 
of the base type.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Bruno Medeiros wrote:
 Rick Mann wrote:
 Bill Baxter Wrote:
 "A typedef or enum can be implicitly converted to its base type, but 
 going the other way requires an explicit conversion. "

 
 Implicitly convertible doesn't mean a type is a subtype of another. 
 Altough in this case of typedef and enums I think they could be subtypes 
 of the base type.

Perhaps he meant the "to its base type" part? I could see someone mixing 
that up with the same term used in class hierarchies...

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Frits van Bommel wrote:
 Bruno Medeiros wrote:
 Rick Mann wrote:
 Bill Baxter Wrote:
 "A typedef or enum can be implicitly converted to its base type, but 
 going the other way requires an explicit conversion. "

 Implicitly convertible doesn't mean a type is a subtype of another. 
 Altough in this case of typedef and enums I think they could be 
 subtypes of the base type.

 
 Perhaps he meant the "to its base type" part? I could see someone mixing 
 that up with the same term used in class hierarchies...

True enough, that may cause some confusion.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Rick Mann <rmann-d-lang latencyzero.com> writes:

Frits van Bommel Wrote:

 Bruno Medeiros wrote:
 Rick Mann wrote:
 Bill Baxter Wrote:
 "A typedef or enum can be implicitly converted to its base type, but 
 going the other way requires an explicit conversion. "

 
 Implicitly convertible doesn't mean a type is a subtype of another. 
 Altough in this case of typedef and enums I think they could be subtypes 
 of the base type.

 
 Perhaps he meant the "to its base type" part? I could see someone mixing 
 that up with the same term used in class hierarchies...

In that case, I'd like to make it a feature request. It seems only natural to
be able to use typedefs in this manner. Should I file a formal request via bug?