On 18 December 2012 16:58, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 18 December 2012 16:43, Peter Alexander <peter.alexander.au@gmail.com>wrote:
>
>> On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>>
>>> Should we take this as an opportunity for other compiler maintainers to implement their own compiler-specific predefined attributes?
>>>
>>
>> Please, no!
>>
>> Suppose GDC implements @noreturn (or whatever other attribute)
>>
>> Later, LDC implements @noreturn separately with slightly different semantics.
>>
>> We now end up in a situation where @noreturn cannot be used portably, and neither compiler developer has incentive to change (whoever changes breaks their users code).
>>
>>
> Provide a situation where @noreturn attribute would mean anything other than telling the compiler to assume that the function cannot return, and I might please you on *that* particular attribute.
>

Might believe you. :=)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 18 December 2012 at 16:58:32 UTC, Iain Buclaw wrote:
> Provide a situation where @noreturn attribute would mean anything other
> than telling the compiler to assume that the function cannot return, and I
> might please you on *that* particular attribute.

On *that* particular attribute, I will accept that there isn't much you could do differently from a theoretical standardised version. The problem is, as soon as you add one compiler specific attribute, it will be used as a precedence for adding others.

pragma exists for the purpose of compiler-specific extensions. Can we just keep using that, and if an attribute comes up that could be truly useful for all compiler then it can be added to the spec.

> On *that* particular attribute, I will accept that there isn't much you could do differently from a theoretical standardised version. The problem is, as soon as you add one compiler specific attribute, it will be used as a precedence for adding others.

You could just name compiler specific attributes something like GDC_noreturn, just like http://dlang.org/pragma.html currently recommends for pragmas. You could also define them in compiler specific modules as has already been discussed in this thread, but then code that used them without full names (including the module name) would break if an attribute with the same name was added to the language.

> pragma exists for the purpose of compiler-specific extensions. Can we just keep using that, and if an attribute comes up that could be truly useful for all compiler then it can be added to the spec.

But you can't do as much with pragmas as you can with attributes. For example, you can alias attributes, and I hope you will also be able to use tuples of attributes - see my example in this thread:

http://forum.dlang.org/thread/uyvdqwslsphshxoioqnw@forum.dlang.org

On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander wrote:
> On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander wrote:
>> On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>>> Should we take this as an opportunity for other compiler maintainers to implement their own compiler-specific predefined attributes?
>>
>> Please, no!
>
> Before anyone says "that would never happen", consider that C++11 was forced to use 'decltype' instead of the more natual 'typeof' because GCC already added 'typeof' as an extension. The same thing happened with the containers. GCC added stdext::hash_map as an extension, so C++11 had to use the ugly std::unordered_map (yep, even the different namespace didn't help).

Can you explain why it was an issue in the unordered_map case ? Because of using ?

I think this should be advertised that such a feature is in some GDC's specific module, and that it can clash with any library symbol at any time, as it is not a standardized feature of the language.

On Tuesday, 18 December 2012 at 19:08:06 UTC, deadalnix wrote:
> On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander wrote:
>> On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander wrote:
>>> On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>>>> Should we take this as an opportunity for other compiler maintainers to implement their own compiler-specific predefined attributes?
>>>
>>> Please, no!
>>
>> Before anyone says "that would never happen", consider that C++11 was forced to use 'decltype' instead of the more natual 'typeof' because GCC already added 'typeof' as an extension. The same thing happened with the containers. GCC added stdext::hash_map as an extension, so C++11 had to use the ugly std::unordered_map (yep, even the different namespace didn't help).
>
> Can you explain why it was an issue in the unordered_map case ? Because of using ?

Most probably yes. using namespace std, and using namespace stdext are all too common. You can't afford to break that code when you update a language as large as C++.

> I think this should be advertised that such a feature is in some GDC's specific module, and that it can clash with any library symbol at any time, as it is not a standardized feature of the language.

Doesn't matter whether you advertise it as experimental or not. As we've just seen with Remedy Games and UDAs, as soon as someone starts using it in production, whether it's experimental or not, you have to support it. That's life.

Am Tue, 18 Dec 2012 20:06:16 +0100
schrieb "jerro" <a@a.com>:

> You could also define them in compiler specific modules as has already been discussed in this thread, but then code that used them without full names (including the module name) would break if an attribute with the same name was added to the language.

We could do this: Language attributes (@property, @safe, ...) are
defined in "lang.attributes" (or choose some other name). Then add a
public import of lang.attributes to object.di.

GDC attributes are defined in gdc.attributes (or any other name). We could add an public import to object.di for gdc. Or we don't, that's a different discussion.

The result is that you can always resolve conflicting attributes: If gdc introduces @noreturn in gdc.attributes you can now do this:
------------------------
//(Optional if gdc.attributes is imported in
//object.di)
import gdc.attributes;

@noreturn void foo{}
------------------------

If a @noreturn attribute is now added to lang.attributes, the compiler will refuse to compile the above code as it's ambiguous. But you can now do this:

@lang.attributes.noreturn void foo{}
or
@gdc.attributes.noreturn void foo{}

or
import gdc = gdc.attributes;
@gdc.noreturn void foo{}

On Tuesday, 18 December 2012 at 19:23:18 UTC, Peter Alexander wrote:

>> I think this should be advertised that such a feature is in some GDC's specific module, and that it can clash with any library symbol at any time, as it is not a standardized feature of the language.
>
> Doesn't matter whether you advertise it as experimental or not. As we've just seen with Remedy Games and UDAs, as soon as someone starts using it in production, whether it's experimental or not, you have to support it. That's life.

Many other programming languages aren't as conservative as C++. I thing the key point here is to have a tool to handle the refactoring automatically. It seems way easier to provide such a tool in D than in C++.

On 18 December 2012 19:23, Peter Alexander <peter.alexander.au@gmail.com>wrote:

> I think this should be advertised that such a feature is in some GDC's
>> specific module, and that it can clash with any library symbol at any time, as it is not a standardized feature of the language.
>>
>
> Doesn't matter whether you advertise it as experimental or not. As we've just seen with Remedy Games and UDAs, as soon as someone starts using it in production, whether it's experimental or not, you have to support it. That's life.


Then again, I am not tied to any particular organisation, so I have no influence from external bodies during the decision making of when I'm adding, keeping, or removing any compiler features in the GDC flavour of D.  I know that probably sounds rather blunt or ignorant, but what I do do is only ever done on the basis that that was the right thing to do and did with the best intentions that I had had at the time of doing them. (Awkward sentence meant for opticron so I can watch him trip and fall over it :).


An example of a litmus test I've done in the past is something like this:

1) Ask people what would they think if I pull feature X from GDC (eg, D's
.html source support).
2) Listen to the responses, some would agree, but most argue against the
whole idea for legacy reasons.
3) Wait maybe a fortnight whilst I take in all considerations and just do
it anyway.
4) Wait 6-12 months for anyone to notice.
5) No one noticed, thus concluding that:
 a) No one really has any use for it despite what they argue, or
 b) No one infact uses GDC (go figure!).
6) Send a pull request to DMD which gets put through into the next release.


Similarly, no one has noticed that most of the pragma GDC supported have mysterious vanished either.  The ones left at kept only for gcc.builtins support until a time I re-implement the attributes in a better way that I haven't decided on yet (hence why raising this thread).


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Tuesday, 18 December 2012 at 20:27:31 UTC, deadalnix wrote:
> Many other programming languages aren't as conservative as C++. I thing the key point here is to have a tool to handle the refactoring automatically. It seems way easier to provide such a tool in D than in C++.

I think it's quite the contrary, due to mixin() and the extended code generation capabilities of D. In comparison, the C preprocessor is pretty limited, at least as far as the typical use cases are concerned.

David

On 12/18/12 11:58 AM, Iain Buclaw wrote:
> On 18 December 2012 16:43, Peter Alexander <peter.alexander.au@gmail.com
> <mailto:peter.alexander.au@gmail.com>> wrote:
>
>     On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>
>         Should we take this as an opportunity for other compiler
>         maintainers to implement their own compiler-specific predefined
>         attributes?
>
>
>     Please, no!
>
>     Suppose GDC implements @noreturn (or whatever other attribute)
>
>     Later, LDC implements @noreturn separately with slightly different
>     semantics.
>
>     We now end up in a situation where @noreturn cannot be used
>     portably, and neither compiler developer has incentive to change
>     (whoever changes breaks their users code).
>
>
> Provide a situation where @noreturn attribute would mean anything other
> than telling the compiler to assume that the function|| cannot return,
> and I might please you on *that* particular attribute.

One possibility: one compiler assumes @noreturn never returns, whereas another enforces that by adding an HLT at the end of the function.

Andrei