Historically there is an opaque value type for holding an arbitrary C void*. It was called HANDLE!.
A name change that @rgchris suggests is that the datatype starting with an @, as in @rgchris, take this name of HANDLE!. The issue was discussed many years ago.. Other name suggestions were:
- email! (just reuse it for
@foo, which Red is currently doing) - at!
- name!
- person!
- user!
- username!
- nick!
- nickname!
When the discussion was being had, I liked AT! because I was thinking about how abstract the uses could be. I was already thinking about how many usages for %foo there were than just naming files. So calling it nickname! or person! was out for me.
Today I think HANDLE! is probably best
BrianH felt that the thing we call HANDLE! today was named well, from a computer science point of view. But for Rebol's purposes, I feel like it might be just the right kind of name for a unified datatype that represents email addresses, twitter handles, and whatever kind of state you might want to be marked with an @.
Plus, the HANDLE! type was falsely unifying C data pointers and C function pointers, which may be of different sizes. I feel like CDATA! and CFUNCTION! would be more legitimate types (possibly with a hyphen, though without seems okay to me.)
What about unification with EMAIL! ?
I think unifying with EMAIL! is likely a good idea. (Red is already doing this.) I've also described a concept for how it might work that as handle! <foo> => @foo while still as tag! a@b => <a@b>.
Having two names is less of an issue, e.g. with evaluative switch, email!: handle! will "just work" for type tests through synonyms...though some canon display would have to be chosen for molding the type (I'd suggest HANDLE!)
@johnk worried about unifying the email and handle types, because it would be relaxing the rules for catching invalid email addresses at LOAD time. You could have something that was an EMAIL! that did not meet the RFC for an EMAIL!. I think that doesn't have quite the benefit it sounds like...you can dynamically create an EMAIL! with any text in it. Disallowing string manipulations that ever pass through a non-RFC-compliant state would be performance-inhibitive and too restrictive...they're always going to have to be validated later anyway. Having the canon name of the type HANDLE! helps clear up the false sense of security some might get, believing EMAIL! can only hold an RFC-valid address.
Note there is overlap. #foo@example.com would be a valid email address (It's an EMAIL! and not an ISSUE! in Rebol2, R3-Alpha, Red, and currently Ren-C.) It's a bit of a maze also, because URLs can contain @ too...further overriding the rules for email (!)