On Friday, 12 August 2016 at 18:23:55 UTC, Cauterite wrote:
> Thanks colon-nazis, I'll take that into consideration ¬_¬

Be careful! They will cauterize your testicles and rape your children! Those semi-clone, I mean semi-colon-nazis are the worse kind!  It's a life and death matter! After all, `proper`(by section 8.043 of the penile nazile book of the dead) use of ';' is more important than your testicles anyways, right?

On Friday, 12 August 2016 at 17:53:12 UTC, ag0aep6g wrote:
> On 08/12/2016 07:33 PM, Cauterite wrote:
>> Why would I not terminate a declaration with a semi-colon?
>> Why should a declaration not end in a semi-colon just because the last
>> token is a brace?
>> Why should I not tell the lexer precisely where my declaration ends
>> instead of relying on whatever other tokens floating around it not
>> interfering?
>
> The semicolon is just noise. You're not helping the lexer at all. It goes by the braces, and doesn't see the semicolon as belonging to the function declaration. The semicolon creates another, empty declaration.

Then it should error if it doesn't accept ';'. If it accepts it then it is legal. Your post is noise since it also is relatively meaningless and just takes up space. Why is it no ok for him to add a noisy ';' but it is ok for you to add noise to noise by adding a noisy post?

> This is accepted as well, and means the same:
>
> ----
> ;;;
> void main() {}
> ;;;
> ----
>
>> Why must every thread in this forum contain more posts regarding some
>> irrelevant tangent than posts responding to the original topic?
>
> This is a common mistake - more for structs, though, because of C syntax. So I point it out so that you can learn that there's no point to it in D, and so that others don't get the impression that it's the proper syntax.


It is not a mistake... only in your mind. If it was a mistake D wouldn't allow it. Somewhere you picked up the mistake that adding a semicolon to the end of a struct is a mistake. Maybe you should unlearn that mistake?

There is no point in a lot of things, but pretending that life depends on such trivial things is a much worse mistake, IMO.

On 08/13/2016 09:23 PM, Engine Machine wrote:
> Then it should error if it doesn't accept ';'. If it accepts it then it
> is legal.

It is legal, yes. It's also pointless and misleading. It should be pointed out for the benefit of the author, as they may have a misconception about D syntax. It should also be pointed out so that others don't form such misconceptions.

[...]
> It is not a mistake... only in your mind.

In my experience, an empty declaration or statement is usually a mistake. And it's usually done by people coming from C. If it's not a mistake, it's a pretty weird style choice.

A similar thing is `return(foo);`. I'd point that out, too, because like the extra semicolon, it looks like it might be necessary syntax, but it's really just extra punctuation without purpose.

Of course, everyone is free to write their code however they want. But if you post here, it can't be surprising when you get feedback on it. Especially when it's an answer to someone else, which means it's more important to write good code, because you're influencing someone who's learning.

> If it was a mistake D wouldn't allow it.

D deliberately allows many mistakes, and they can be much more serious than the little style mishap at hand.

[...]
> There is no point in a lot of things, but pretending that life depends
> on such trivial things is a much worse mistake, IMO.

I originally wrote one little line on this. I don't think anyone here is "pretending that life depends on" it.

On Saturday, 13 August 2016 at 18:37:54 UTC, Cauterite wrote:
> On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
>> /* memory.d file */
>> module memory;
>> import include.linux.sched;    /* contains task_struct definition */
>>
>> void free_page_tables(task_struct* tsk) {
>>         /* do something with &tsk */
>> }
>>
>> And to use the method from somewhere else
>> /* use method.d */
>>
>> module usemethod;
>> import include.linux.sched;
>> import mm.memory;
>>
>> void some method() {
>>         free_page_tables(*pointer to task_struct*);
>> }
>>
>> I hope my explanation is not rambling nonsense.
>>
>> Cheers.
>
> Yes, you're right. Passing structure pointers to functions is an extremely common practice in C, because there aren't really any other compelling options. In D we have things like methods, classes, 'const ref' params, return-type inference, etc., so there's usually a better way to achieve the same result.

Cheers!!

Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer?  By that I mean something like

class Foo {
    void fooMethod() {

}

void bar(Foo *f) {

}

On Saturday, 13 August 2016 at 18:37:54 UTC, Cauterite wrote:
> On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
>> /* memory.d file */
>> module memory;
>> import include.linux.sched;    /* contains task_struct definition */
>>
>> void free_page_tables(task_struct* tsk) {
>>         /* do something with &tsk */
>> }
>>
>> And to use the method from somewhere else
>> /* use method.d */
>>
>> module usemethod;
>> import include.linux.sched;
>> import mm.memory;
>>
>> void some method() {
>>         free_page_tables(*pointer to task_struct*);
>> }
>>
>> I hope my explanation is not rambling nonsense.
>>
>> Cheers.
>
> Yes, you're right. Passing structure pointers to functions is an extremely common practice in C, because there aren't really any other compelling options. In D we have things like methods, classes, 'const ref' params, return-type inference, etc., so there's usually a better way to achieve the same result.

Cheers!!

Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer?  By that I mean something like

class Foo {
    void fooMethod() {
    }
}

void bar(Foo *f) {
    /* access fooMethod from &f */
}

Thanks for all your help, I really appreciate it!!

On Sunday, 14 August 2016 at 14:54:27 UTC, D.Rex wrote:
> Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer?

It just works with the regular dot.

But don't pass classes as pointers in D except in very rare circumstances. They are already pointers under the hood automatically.

On Sunday, 14 August 2016 at 14:59:17 UTC, Adam D. Ruppe wrote:
> On Sunday, 14 August 2016 at 14:54:27 UTC, D.Rex wrote:
>> Speaking of classes, and this may have been answered elsewhere, but I am yet to find said answer, or am just missing something right in front of my face...but how does one go about accessing a method from a class if said class is passed to a function as a pointer?
>
> It just works with the regular dot.
>
> But don't pass classes as pointers in D except in very rare circumstances. They are already pointers under the hood automatically.

So you can access a method from a class pointer the same way you would access a method from a class normally?

so '&foo.bar();' works the same as 'foo.bar();'?

ah that makes sense, classes being pointers behind the scenes, Most of my programming experience is in Java, so the usage of pointers is a rather new concept for me.

Thank you kindly for your answer, much appreciated!! :-)

On Sunday, 14 August 2016 at 16:21:58 UTC, D.Rex wrote:
> so '&foo.bar();' works the same as 'foo.bar();'?

with pointers, D automatically rewrites expressions like this:
	f.fooMethod()
to this:
	(*f).fooMethod()
which is why you're able to index an object-pointer-pointer (Foo*) the same way as an object-pointer (Foo).

Most built-in D types have value semantics, so it's understandable that you wouldn't expect classes to be reference types.

Associative arrays are also reference types, FYI.

Structs on the other hand are value types; if you're new to the language make sure you familiarise yourself with the differences between structs and classes.