Noticed several typos that dmd seems to have not picked up initially. Does dmd not compile all source code? I obviously wouldn't expect it to recompile something unnecessarily, but in a few cases I've just seen it not throw errors where it should have.

On Wednesday, 6 December 2017 at 16:07:41 UTC, A Guy With a Question wrote:
> Noticed several typos that dmd seems to have not picked up initially. Does dmd not compile all source code? I obviously wouldn't expect it to recompile something unnecessarily, but in a few cases I've just seen it not throw errors where it should have.

It depends on how you're invoking it.

In all likelihood, you had typos in uninstantiated templates.

Atila

On Wednesday, 6 December 2017 at 16:10:34 UTC, Atila Neves wrote:
> On Wednesday, 6 December 2017 at 16:07:41 UTC, A Guy With a Question wrote:
>> Noticed several typos that dmd seems to have not picked up initially. Does dmd not compile all source code? I obviously wouldn't expect it to recompile something unnecessarily, but in a few cases I've just seen it not throw errors where it should have.
>
> It depends on how you're invoking it.
>
> In all likelihood, you had typos in uninstantiated templates.
>
> Atila

I'm not sure how it works underneath the covers, but I'm not currently working with a ton of templates explicitly. I am utilizing interfaces and some generic container types, which I guess might mean templates underneath. However, if an abstract class with a generic parameter translates itself to a template underneath the covers, I still would expect it to throw an error if I have a clear syntax problem. If it's not, that's pretty unacceptable actually for it not to.

I have to be honest, I'm a little worried about all of this code I just translated and how much of it is actually valid...I hope I didn't waste my time.

On Wednesday, 6 December 2017 at 16:32:05 UTC, A Guy With a Question wrote:
> I have to be honest, I'm a little worried about all of this code I just translated and how much of it is actually valid...I hope I didn't waste my time.

Ok, so I verified this much. I would expect an error from the following, but it does not actually produce an error...

module grrr.grr;

abstract class Test(T)
{
private:
    T thing;

public:
    this(T theThing)
    {
        thing = theThing;
	thisdoesnotexist(); // expect compiler error right here!!!!
    }
}

...but this compiles just fine.

On Wednesday, 6 December 2017 at 16:47:17 UTC, A Guy With a Question wrote:
> On Wednesday, 6 December 2017 at 16:32:05 UTC, A Guy With a Question wrote:
>> I have to be honest, I'm a little worried about all of this code I just translated and how much of it is actually valid...I hope I didn't waste my time.
>
> Ok, so I verified this much. I would expect an error from the following, but it does not actually produce an error...
>
> module grrr.grr;
>
> abstract class Test(T)
> {
> private:
>     T thing;
>
> public:
>     this(T theThing)
>     {
>         thing = theThing;
> 	thisdoesnotexist(); // expect compiler error right here!!!!
>     }
> }
>
> ...but this compiles just fine.

It does produce there error when I do this:

class Test2
   : Test!int
{
    this(int thing)
    {
	super(thing);
    }
}

On Wednesday, 6 December 2017 at 16:49:51 UTC, A Guy With a Question wrote:
>> module grrr.grr;
>>
>> abstract class Test(T)
>> {
>> private:
>>     T thing;
>>
>> public:
>>     this(T theThing)
>>     {
>>         thing = theThing;
>> 	thisdoesnotexist(); // expect compiler error right here!!!!
>>     }
>> }
>>
>> ...but this compiles just fine.
>
> It does produce there error when I do this:
>
> class Test2
>    : Test!int
> {
>     this(int thing)
>     {
> 	super(thing);
>     }
> }

Another example:

interface ITest(T)
{
   @property
   Nullable!T value();	// have not imported Nullable. Should fail.
}

compiles...

Fails when this happens:

class Test
   : ITest!int
{
   @property
   Nullable!int value() { return nullable(0); }
}


I really do think, regardless of if this is considered a template expansion, that dmd should be catching these obvious errors. When one writes interfaces and abstract classes they are generally not ready to implement the end class yet. And getting a ton of errors at once when that occurs is really hard to deal with. I really don't understand why the compiler would have issues with this.

On 12/6/17 12:04 PM, A Guy With a Question wrote:

> I really do think, regardless of if this is considered a template expansion, that dmd should be catching these obvious errors. When one writes interfaces and abstract classes they are generally not ready to implement the end class yet. And getting a ton of errors at once when that occurs is really hard to deal with. I really don't understand why the compiler would have issues with this.

So, it is important to note that a template must successfully *parse*, but it cannot be semantically analyzed until it is instantiated.

It is no different from C++ templates.

So why wouldn't the compiler fail? Because it has no idea yet what you mean by Nullable. It doesn't even know if Nullable will be available or not. You could even import Nullable, but Nullable!T may be an error.

This is definitely different from Generics (which I think you are familiar with), where there is some semblance of structure implied in the wildcard types. With templates, the type can be anything.

It might be possible to do some deduction of whether something will EVER compile, but it's probably not worth the extra work.

Did you waste your time? No. It seems like all your errors are simple import problems, just fix the bugs, and you should be good!

For the future, the correct way to write templates like this is to instantiate them in tests. Use unittesting, and you shouldn't have problems like this.

-Steve

On Wednesday, 6 December 2017 at 17:04:06 UTC, A Guy With a Question wrote:
>>> abstract class Test(T)

Here you have a class template.

>> It does produce there error when I do this:
>>
>> class Test2
>>    : Test!int

You instantiated the template, so the compiler can now type check the instantiated class.

> class Test
>    : ITest!int

Same thing here but with an interface template.

> I really do think, regardless of if this is considered a template expansion, that dmd should be catching these obvious errors. When one writes interfaces and abstract classes they are generally not ready to implement the end class yet. And getting a ton of errors at once when that occurs is really hard to deal with. I really don't understand why the compiler would have issues with this.

I sympathize, something like Rust's traits or concept-enhanced C++ could probably do what you want, but D doesn't have this feature.

On Wednesday, 6 December 2017 at 16:47:17 UTC, A Guy With a Question wrote:
> abstract class Test(T)
> {
> private:
>     T thing;
>
> public:
>     this(T theThing)
>     {
>         thing = theThing;
> 	thisdoesnotexist(); // expect compiler error right here!!!!
>     }
> }
>
> ...but this compiles just fine.

It's because it's not being used in your program. How can the compiler compile it without knowing what T would be?

When you do this:

> class Test2
>    : Test!int
> {
>     this(int thing)
>     {
> 	super(thing);
>     }
> }

You are suppling T and now it is compiled and an error raised.