On Wednesday, 25 January 2012 at 12:03:15 UTC, Nick Sabalausky wrote:
> <equinox@atw.hu> wrote in message news:op.v8mxx6s9xa30qa@marton-pc...
>>
>>Hi,
>>
>>I have been thinking . Would not C and C++ backend would make DMD more versatile?
>>D language could be used in many platforms easily.
>>D language could be used in .net and elsewhere.
>>It could be compiled with other language that are also translated into C/C++.
>
> I think LDC can do that...At least in theory anyway, since LLVM has a C backend.

It does, but they tell you not to use it. Make of that what you will.

On Wed, 25 Jan 2012 05:26:20 -0500, <equinox@atw.hu> wrote:

>
> Hi,
>
> I have been thinking . Would not C and C++ backend would make DMD more versatile?
> D language could be used in many platforms easily.
> D language could be used in .net and elsewhere.
> It could be compiled with other language that are also translated into C/C++.
>

IIRC, Walter is (slowly) working on that.

-Steve

On Wed, Jan 25, 2012 at 4:26 AM,  <equinox@atw.hu> wrote:
>
> Hi,
>
> I have been thinking . Would not C and C++ backend would make DMD more
> versatile?
> D language could be used in many platforms easily.
> D language could be used in .net and elsewhere.
> It could be compiled with other language that are also translated into
> C/C++.

As far as platform support goes, GDC *should* be able to target pretty
much any platform GCC can currently target. There are probably some
platform-specific issues at this point; one example would be that you
have to disable the section-anchors optimization to get D running on
ARM.
There are also some fun things like Fibers not working because the
getcontext/setcontext/makecontext functions in glibc are just stubs on
ARM, but Iain has done an excellent job of adding GCC-specific version
blocks to Druntime that replace most of the platform-specific code
with pre-written GCC intrinsics.

I know Daniel Green had some difficulty getting a toolchain that supports TLS on Windows, hopefully he can chime in on whether that's just Windows or will be an issue on other platforms as well.

> The issue is not with aliases, accessability already has a natural grey
> area:
>
> ====================
> module lib;
>
> private struct Foo {}
>
> // Should any of these be allowed?
> public Foo getFoo() { return Foo(); }
> public void takeFoo(Foo f) {}
> struct Bar
> {
>     Foo f;
> }
>
> ------
>
> module main;
> import lib;
>
> getFoo();  // Allowed?
>
> takeFoo(getFoo());  // Allowed?
>
> Bar b;  // Allowed?
>
> takeFoo(b.f);   // Allowed?
>
> b.f = getFoo();   // Allowed?
>
> // Allowed? If so, can you *do* anything with x?
> auto x = getFoo();
>
> ====================
>
The solution seems to be to check protection only during symbol lookup.
Thus all of the above are allowed and you can do with x what Foo allows you to
(aggregates default to public protection).