Hi,

"Walter" <walter@digitalmars.com> wrote in message news:aaklkn$1pc9$1@digitaldaemon.com...
>
> If you're going to have a "safe" language, you cannot allow conversions of random bit patterns into arbitrary types. Hence, unions cannot be allowed.

Obviously, you cannot allow unions in the form they appear in C/C++. However, when I think of unions and how I use them, they might serve a purpose in D and might be supported anyway in a restricted form. I use them rarely - the most common example I can think of is YACC parsers.

As far as I can see, the compiler could generate a hidden "selector" member, that could be set on assignment, validated on reference, and used by the garbage collector. This would cause a minor run-time penalty, but would ease converting existing C code to D and for example making YACC support D.

Regards,
Martin M. Pedersen

In article <aamedh$2lp6$1@digitaldaemon.com>,
 "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote:

> Hi,
> 
> "Walter" <walter@digitalmars.com> wrote in message news:aaklkn$1pc9$1@digitaldaemon.com...
> >
> > If you're going to have a "safe" language, you cannot allow conversions of random bit patterns into arbitrary types. Hence, unions cannot be allowed.
> 
> Obviously, you cannot allow unions in the form they appear in C/C++. However, when I think of unions and how I use them, they might serve a purpose in D and might be supported anyway in a restricted form. I use them rarely - the most common example I can think of is YACC parsers.
> 
> As far as I can see, the compiler could generate a hidden "selector" member, that could be set on assignment, validated on reference, and used by the garbage collector. This would cause a minor run-time penalty, but would ease converting existing C code to D and for example making YACC support D.

Sounds a lot like polymorphism... with virtual get and set functions.
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>

Hi,

"Keith Ray" <k1e2i3t4h5r6a7y@1m2a3c4.5c6o7m> wrote in message news:k1e2i3t4h5r6a7y-C0A6F7.09091330042002@digitalmars.com...
> In article <aamedh$2lp6$1@digitaldaemon.com>,

> > As far as I can see, the compiler could generate a hidden "selector"
member,
> > that could be set on assignment, validated on reference, and used by the garbage collector.

> Sounds a lot like polymorphism... with virtual get and set functions.

Yes, it would be a lot polymorphism. But it saves you for defining a class hierachy.

I don't know if unions should be built into the language. Other new features might be more important to be supported. My point was simply that unions have other purposes than simply bypassing the type system, it would be possible for D to support type safe uses of unions, and so, they shouldn't be completely disregarded simply because of their unsafe nature in C/C++.

Regards,
Martin M Pedersen

Unions could be supported (semantically), but implemented the same as
structs.  Stuff should still compile and run unless they do crap like
assert(sizeof(union_type) < sizeof(struct_type)) or rely on changing one
union member causing another union member to change value in a predictable
way.

Sean

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:aaml7l$a0o$1@digitaldaemon.com...
> Hi,
>
> "Keith Ray" <k1e2i3t4h5r6a7y@1m2a3c4.5c6o7m> wrote in message news:k1e2i3t4h5r6a7y-C0A6F7.09091330042002@digitalmars.com...
> > In article <aamedh$2lp6$1@digitaldaemon.com>,
>
> > > As far as I can see, the compiler could generate a hidden "selector"
> member,
> > > that could be set on assignment, validated on reference, and used by
the
> > > garbage collector.
>
> > Sounds a lot like polymorphism... with virtual get and set functions.
>
> Yes, it would be a lot polymorphism. But it saves you for defining a class hierachy.
>
> I don't know if unions should be built into the language. Other new
features
> might be more important to be supported. My point was simply that unions have other purposes than simply bypassing the type system, it would be possible for D to support type safe uses of unions, and so, they shouldn't be completely disregarded simply because of their unsafe nature in C/C++.
>
> Regards,
> Martin M Pedersen

"Sean L. Palmer" wrote:

> Unions could be supported (semantically), but implemented the same as
> structs.  Stuff should still compile and run unless they do crap like
> assert(sizeof(union_type) < sizeof(struct_type)) or rely on changing one
> union member causing another union member to change value in a predictable
> way.

The latter case is why I wouldn't want unions-as-struct.  Mapping the binary implementation of one type to another is one of the well-known uses of unions. If we changed them to structs, it would cause subtle errors.

We could, however, add a syntax error such as:
    "Unions not supported in this language.  Please use a struct instead."

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"C.R.Chafer" wrote:

> Guy Pascarella wrote:
>
> > I think that everyone is on the right track for a stripped down "safe" version of D, but you might want to call it something other than D--. Maybe D'Light (aka delight) or something.
> >
> > -Guy
>
> DeLight : great idea :-)
>
> C 2002/4/30

I'm not opposed to "Delight"...though I prefer D-- because of its reference to C++.  However, the decision doesn't have to be made yet.  Let's leave that to later and focus on discussing the technical requirements.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:

> I'm forking from the "Compiling Phobos" thread to discus D-- here.
[snip]
A very important feature should be implemented:
You should be able to make an object visible to the script languages
(D-- or ECMAscript). All objects should be hidden to the script
language by default.

Best regards,
Mark Junker

Alexander Lahmann wrote:

> Russ Lewis wrote:
>
> > I'm forking from the "Compiling Phobos" thread to discus D-- here.
> [snip]
> A very important feature should be implemented:
> You should be able to make an object visible to the script languages
> (D-- or ECMAscript). All objects should be hidden to the script
> language by default.
>
> Best regards,
> Mark Junker

If I understand what you want, D already has this feature.  Simply mark objects as "private" in the D file that declares them, and they should not be visible from other D files that import that file.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:

> Alexander Lahmann wrote:
>
> > Russ Lewis wrote:
> >
> > > I'm forking from the "Compiling Phobos" thread to discus D-- here.
> > [snip]
> > A very important feature should be implemented:
> > You should be able to make an object visible to the script languages
> > (D-- or ECMAscript). All objects should be hidden to the script
> > language by default.
> >
> > Best regards,
> > Mark Junker
>
> If I understand what you want, D already has this feature.  Simply mark objects as "private" in the D file that declares them, and they should not be visible from other D files that import that file.

But, this is a very good note...any "safe D library" will have to tightly control which objects that "untrusted" code can access.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]