On 2012-11-16 05:26, jerro wrote:

> I don't know whether the language could be changed to support code like:
>
> struct Foo(){}
> Foo foo;
>
> but doing that certainly would introduce some ambiguities. For example,
> consider this line:
>
> alias Foo Bar;
>
> Should Bar be a template or an instance of a template here?

Any place where a template and an instantiation is allowed it will default to a template. The user would then need to explicitly add !() to indicate an instantiation. In all other places, it will be an instantiation.

I think in most cases using just a template is not allowed.

-- 
/Jacob Carlborg

On 16/11/12 05:15, Rob T wrote:
> On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:
>>> Event_t e2;        // Will compile!
>>
>> Yeah but that kinda blows, doesn't it?
>>
>
> I found it surprising or unintuitive that the !() is required, and I do
> want to know what is the reasoning behind it,

One of the oldest open enhancement requests is on this topic:

http://d.puremagic.com/issues/show_bug.cgi?id=1012

I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.

Now I'm working that.

Kenji Hara

2012/11/16 Don Clugston <dac@nospam.com>

> On 16/11/12 05:15, Rob T wrote:
>
>> On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:
>>
>>> Event_t e2;        // Will compile!
>>>>
>>>
>>> Yeah but that kinda blows, doesn't it?
>>>
>>>
>> I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it,
>>
>
> One of the oldest open enhancement requests is on this topic:
>
> http://d.puremagic.com/issues/**show_bug.cgi?id=1012<http://d.puremagic.com/issues/show_bug.cgi?id=1012>
>
> I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.
>

Done. https://github.com/D-Programming-Language/dmd/pull/1295

Kenji Hara

2012/11/16 kenji hara <k.hara.pg@gmail.com>

> Now I'm working that.
>
> Kenji Hara
>
> 2012/11/16 Don Clugston <dac@nospam.com>
>
>> One of the oldest open enhancement requests is on this topic:
>>
>> http://d.puremagic.com/issues/**show_bug.cgi?id=1012<http://d.puremagic.com/issues/show_bug.cgi?id=1012>
>>
>> I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.
>>
>
>

On 11/16/12, kenji hara <k.hara.pg@gmail.com> wrote:
> Done. https://github.com/D-Programming-Language/dmd/pull/1295

Have you seen this comment:

On 11/16/12, jerro <a@a.com> wrote:
> doing that certainly would introduce some ambiguities. For example, consider this line:
>
> alias Foo Bar;
>
> Should Bar be a template or an instance of a template here?

On 2012-11-16 11:16, Andrej Mitrovic wrote:

> Have you seen this comment:
>
> On 11/16/12, jerro <a@a.com> wrote:
>> doing that certainly would introduce some ambiguities. For
>> example, consider this line:
>>
>> alias Foo Bar;
>>
>> Should Bar be a template or an instance of a template here?

And my reply to that comment:

Any place where a template and an instantiation is allowed it will default to a template. The user would then need to explicitly add !() to indicate an instantiation. In all other places, it will be an instantiation.

I think in most cases using just a template is not allowed.

-- 
/Jacob Carlborg

On 11/16/2012 4:08 AM, Nick Sabalausky wrote:
> On Fri, 16 Nov 2012 01:11:18 +0100
> As for your specific issue, there's a few different factors:
>
> 1. Like other have already said, all the files need to be sent to DMD
> together (possibly by using RDMD) or, if not that, then at least their
> objects all need to be sent to the linker together. I realize you're
> using VisualD and therefore have reason to expect it to be taken care
> of automatically, but since something obviously might be going awry in
> that regard, you'll need to take it up with the VisualD developer. If
> you're nice to him, he might even be glad to help out.
>
> 2. If there is indeed an actual bug in the compiler or linker (instead
> of either VisualD or your project's VisualD settings), and you want it
> addressed promptly (keeping in mind this is a non-commercial venture
> and you're not paying anyone for support, so therefore there are NO
> timeframe guarantees), then it will help greatly if you provide a test
> case (and file it in the bug tracker: http://d.puremagic.com/issues/ )
> which fully demonstrates the problem *without* having any reliance on
> any tool other than the compiler/linker itself. Yes, this means dealing
> with the command line.
>
> 3. The linker's error message needs to be better (as many people have
> already agreed with you on). The linker itself is written in
> highly-optimized assembly (and is in the process of being - very
> meticulously - converted to C for easier maintenance, as a stepping
> stone to it eventually moving to D), so changes to it *will be* slow.
> What *can* be done though, is to pipe its output through a D demangler,
> and in fact I think someone's already made such a tool. If you're not
> willing to use a direct command line to do that, then you can put in a
> request (not a demand) with the VisualD dev to have such functionality
> incorporated into VisualD. Or, although this may be a stretch, you
> could even offer to help incorporate the change to VisualD yourself.
>
> 4. I'm not sure I even see a specific problem in that thread that
> hasn't been addressed. First of all, it looks like your DFL problem was
> solved by including DFL in your VisualD project's dependencies.
> Secondly, I'm not getting your error when I try this:
>
> http://forum.dlang.org/thread/souztdpadfefltnvckcg@forum.dlang.org?page=2#post-djjkyaqnwlsquticjfmw:40forum.dlang.org
>
> Both of those files compile fine for me with DMD 2.060, and if I toss
> in a "void main() {}" I even get a working executable.
>

Even though the discussion seems to have cooled down, I'd like to clarify a number of speculations:

Visual D compiles the files that are added to the project, not anything imported as rdmd does (I think this does not scale for larger projects where you better use libraries for sub-projects).

Visual D does not use incremental builds because this causes linker problems due to missing symbols. Judging from single file compilation it won't even reduce build times because import dependencies cause almost everything is compiled or at least semantically analyzed anyways (though this might be with my projects only).

As of 0.3.34 Visual D demangles the linker output (if not explicitely disabled in the options).

On Friday, 16 November 2012 at 01:00:58 UTC, Walter Bright wrote:
> On 11/15/2012 4:11 PM, Stugol wrote:
>> am I likely to be told to fuck off again?
>
> I haven't seen Bernard lately, so probably not.

I'm still about.

> Bernard was certainly out of line with that remark

Absolutely. I let the NG get under my skin too much. I'm trying to
be a reformed man!