On 11/29/2012 12:28 PM, Jonathan M Davis wrote:
> I don't really care whether it's done with an attribute or a pragma, but
> pragmas are supposed to be potentially compiler-specific as opposed to being
> part of the language, so I'd think that an attribute would make more sense.

An attribute would bring along with it the notion of having some static constructors care about dependencies and others not. A pragma would be global to the module.

Both would introduce implementation-defined behavior (being the actual order in which the construction occurs), so perhaps a pragma would be more suitable.

On 2012-11-29 03:00, Walter Bright wrote:

> An attribute would bring along with it the notion of having some static
> constructors care about dependencies and others not. A pragma would be
> global to the module.

Why can't the attribute be global to the module?

-- 
/Jacob Carlborg

On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
> On 2012-11-29 03:00, Walter Bright wrote:
>
>> An attribute would bring along with it the notion of having some static
>> constructors care about dependencies and others not. A pragma would be
>> global to the module.
>
> Why can't the attribute be global to the module?
>

Because attributes attach to the declarations they enclose. A global attribute would be something else.

When I first read about D's CTFE capabilities, I imagined a full-fledged computing environment both at compile-time and at run-time. I thought the aim was to provide a language which can compile into its own source code, which in turn can compile into a binary. Right now I understand, that it's not the case. I certainly have no right to complain, so all I can say is that I had too high hopes. Despite a few broken hopes, D remain the #1 champion among languages.


On Thu, Nov 29, 2012 at 2:25 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
>
>> On 2012-11-29 03:00, Walter Bright wrote:
>>
>>  An attribute would bring along with it the notion of having some static
>>> constructors care about dependencies and others not. A pragma would be global to the module.
>>>
>>
>> Why can't the attribute be global to the module?
>>
>>
> Because attributes attach to the declarations they enclose. A global attribute would be something else.
>



-- 
Bye,
Gor Gyolchanyan.

On Thursday, 29 November 2012 at 10:25:40 UTC, Walter Bright wrote:
> On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
>> On 2012-11-29 03:00, Walter Bright wrote:
>>
>>> An attribute would bring along with it the notion of having some static
>>> constructors care about dependencies and others not. A pragma would be
>>> global to the module.
>>
>> Why can't the attribute be global to the module?
>>
>
> Because attributes attach to the declarations they enclose. A global attribute would be something else.

What's wrong with attaching the annotation to the module declaration?
i.e.
@no_circular_ctors module foobar;

Ideally, I'd like to have the reverse default - require an explicit import _inside_ the static ctor when a dependency actually exists. Seems to me that in the vast majority of cases this is the actual preferred choice by users and for the tiny (if any) percent that depend on the current behavior - they'll just get an easy to fix compile-error - e.g. symbol foo.bar is missing, solvable by adding the relevant import.
Of course, such a change should be properly announced and documented per the other thread about the development process of D.

On 2012-11-29 12:44, foobar wrote:

> What's wrong with attaching the annotation to the module declaration?
> i.e.
> @no_circular_ctors module foobar;
>
> Ideally, I'd like to have the reverse default - require an explicit
> import _inside_ the static ctor when a dependency actually exists. Seems
> to me that in the vast majority of cases this is the actual preferred
> choice by users and for the tiny (if any) percent that depend on the
> current behavior - they'll just get an easy to fix compile-error - e.g.
> symbol foo.bar is missing, solvable by adding the relevant import.
> Of course, such a change should be properly announced and documented per
> the other thread about the development process of D.

Having the imports inside the static constructor sounds like a good idea.

-- 
/Jacob Carlborg

On 2012-11-29 11:25, Walter Bright wrote:

> Because attributes attach to the declarations they enclose. A global
> attribute would be something else.

Well that doesn't stop us from making attribute attachable to, say, a module declaration.

-- 
/Jacob Carlborg

On 11/29/12 5:25 AM, Walter Bright wrote:
> On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
>> On 2012-11-29 03:00, Walter Bright wrote:
>>
>>> An attribute would bring along with it the notion of having some static
>>> constructors care about dependencies and others not. A pragma would be
>>> global to the module.
>>
>> Why can't the attribute be global to the module?
>>
>
> Because attributes attach to the declarations they enclose. A global
> attribute would be something else.

Could be attached to the module declaration.

Andrei

On 11/29/12 6:44 AM, foobar wrote:
> On Thursday, 29 November 2012 at 10:25:40 UTC, Walter Bright wrote:
>> On 11/29/2012 6:40 PM, Jacob Carlborg wrote:
>>> On 2012-11-29 03:00, Walter Bright wrote:
>>>
>>>> An attribute would bring along with it the notion of having some static
>>>> constructors care about dependencies and others not. A pragma would be
>>>> global to the module.
>>>
>>> Why can't the attribute be global to the module?
>>>
>>
>> Because attributes attach to the declarations they enclose. A global
>> attribute would be something else.
>
> What's wrong with attaching the annotation to the module declaration?
> i.e.
> @no_circular_ctors module foobar;

I think this entire approach is unprincipled (aside from solving a problem that's not urgent and not important). We shouldn't focus on the _syntax_ of the completely unprincipled approach, but instead on improving it.

A possibly better approach would be e.g. to do a simple analysis of the static constructor's use of symbols, and use that set to decide whether two static constructors must be ordered or not.


Andrei

On 2012-11-29 15:17, Andrei Alexandrescu wrote:

> A possibly better approach would be e.g. to do a simple analysis of the
> static constructor's use of symbols, and use that set to decide whether
> two static constructors must be ordered or not.

Of course, that would be the preferred choice. But if you write a static constructor that has no dependencies. Then you make some changes that accidentally introduce dependencies. There are reasons why "pure", "const" and so on are not automatically inferred, even if they could.

-- 
/Jacob Carlborg