Why are people writing

   import std.stdio;

   void main ()
   {
      S s;
      s.foo;
   }

   struct S {
      void foo ()
      {
         writeln ("a");
      }
   }

but not

   void main ()
   {
      S s;
      s.foo;
   }

   struct S {
      void foo ()
      {
         writeln ("a");
      }
   }

   import std.stdio;

?

On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
> Why are people writing
>
>    import std.stdio;
>
>    void main ()
>    {

>    }
>
>    struct S {

>    }
>
> but not
>
>    void main ()
>    {

>    }
>
>    struct S {

>    }
>
>    import std.stdio;
>
> ?


Personally i found it weird and inconsistent that
you can import and define anywhere at module scope
but for any other scope you have to define and import before use

I think the rules should have been the same everywhere
and if there was an exception to be made, it could be made for the main function
since the main function is special anyway

Personally I would either do
> import

> declare and define

> main

or
> main

> import

> declare and define

the later, is because main is special, so it is as if i am saying
this is what i want to do (main) and to do it (import) this stuff and (declare and define this stuff) ... putting main first would be just to highlight it and attract attention to it

importing and declaring anywhere at module scope is just too random for my taste

On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
> On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
> [...]
> I think the rules should have been the same everywhere
> and if there was an exception to be made, it could be made for the main function
> since the main function is special anyway

The main function of a program corresponds to the final paragraph of a novel. I never understood why programmers place this function which possibly depends on all other functions in the translation unit at the beginning.

BTW: You can't write

   void main ()
   {
      x.writeln;
      int x;
   }
   import std.stdio;

There is no reason why the declaration of x should not be postponed.

On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
> On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
> BTW: You can't write
>
>    void main ()
>    {
>       x.writeln;
>       int x;
>    }
>    import std.stdio;
>

This is because x is not module scope
you can do this

   void main ()
   {
      x.writeln;

   }

   import std.stdio;
   int x;

On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
> On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
>> On Wednesday, 4 April 2018 at 18:57:27 UTC, kdevel wrote:
>> [...]
>> I think the rules should have been the same everywhere
>> and if there was an exception to be made, it could be made for the main function
>> since the main function is special anyway
>
> The main function of a program corresponds to the final paragraph of a novel. I never understood why programmers place this function which possibly depends on all other functions in the translation unit at the beginning.
>
> BTW: You can't write
>
>    void main ()
>    {
>       x.writeln;
>       int x;
>    }
>    import std.stdio;
>
> There is no reason why the declaration of x should not be postponed.

I've never seen the main function at the top but I think it would be be nice place for it honnestly. Sounds more like a C legacy than anything.

The reason why I place common imports at the top is because I read a *lot* of code as my day job is to audit software. While skimming rapidly through directories looking only at the top of each file I know what they are about and can quickly infer their purpose based solely on imports. This file does IO, this one web stuff, etc (and to debunk quickly a counter argument I've heard before: no, given how convoluted file names quickly get especially in languages like java, directory structure isn't nearly enough).

The same is true for the main function. If your code is clean it should the main is the place where you orchestrate the whole program. You should be able to grasp most of the program flow from it. What it setups, information flow, etc. Of course in practice people are often trying to burry useful information deep down in functions (where it's generally too coupled for its own good, but that's another story). Such burrying makes it harder to get useful information from the main function, hence maybe why so many are comfortable putting it at the end (I know I do by habit).

On the other hand, if the main effectively describes the programs course then putting it at the beggining makes complete sense: it is what you want to see first to get an idea of what the program is doing. No function could be better suited for that.

Some points hinted here make me think of https://www.youtube.com/watch?v=FyCYva9DhsI so maybe it could be of some interest to you.

On Wednesday, 4 April 2018 at 20:01:55 UTC, Ali wrote:
> On Wednesday, 4 April 2018 at 19:51:27 UTC, kdevel wrote:
>> On Wednesday, 4 April 2018 at 19:19:30 UTC, Ali wrote:
>> BTW: You can't write
>>
>>    void main ()
>>    {
>>       x.writeln;
>>       int x;
>>    }
>>    import std.stdio;
>>
>
> This is because x is not module scope
> you can do this
>
>    void main ()
>    {
>       x.writeln;
>
>    }
>
>    import std.stdio;
>    int x;

Cause there's no scope at the module level.


struct A
{
    A* a;

    ~this()
    {
        // use a
    }
}

void main()
{
    A b = A(&a);
    A a; // in this case "a" destructed before "b", but "b" uses "a"

}


Destruction and order of destruction becomes much more confusing. You also can't do scope(exit) at the module level for a reason. This mess shouldn't be allowed, it just makes it way worse to understand what is going on.