I think it would be useful to have a dedicated syntax for symbols that a naive compiler can ignore, that is, for compiler hints. I'd consider "@disable" and "pragma" a compiler hint, but not "@property"

I don't grasp the motivation for the naming of keywords in D. I think the syntax would be more clear if "@" was reserved for compiler hints.

Suggestions for compiler-hints that are useful and empowering:

@inline(fuzzylogic-expression){ }

Examples:

@inline some_function(){...}

@inline{
   while(...){ ...inline_all_inner_loop_statements... }
}

@inline(0) never-inline-this...
@inline(1) always-inline-this...
@inline(0.5) inline-if-compiled-to-not-conserve-memory-footprint


@warningonuse "some text"

length() @warningonuse "in this class the length-function is O(n), consider xyz instead"

The "@warningonuse" keyword enables text editors to emit symbols on the side of the text with helpful warnings about possible bottlenecks when using libraries.

Ola Fosheim Grøstad:

> @warningonuse "some text"
>
> length() @warningonuse "in this class the length-function is O(n), consider xyz instead"
>
> The "@warningonuse" keyword enables text editors to emit symbols on the side of the text with helpful warnings about possible bottlenecks when using libraries.

A @warningonuse("some text") used for editors is just a convention, it needs no language changes.

Bye,
bearophile

On Saturday, 28 December 2013 at 11:42:58 UTC, bearophile wrote:
> A @warningonuse("some text") used for editors is just a convention, it needs no language changes.

All compiler-hints are conventions: @assert(), @suppresswarnings{} etc. Compilers should be able to ignore all compiler hints they don't support without affecting a progam which is sound. ( @assert() should never be used to test input, only to assert that the logic is correct ).

It needs grammar-support if you want to avoid making comments "magic". It also needs compiler support if you want to support advanced IDEs or features such as compile-should-fail-on-any-warning.

Ola.

On Saturday, 28 December 2013 at 11:38:38 UTC, Ola Fosheim Grøstad wrote:
> I think it would be useful to have a dedicated syntax for symbols that a naive compiler can ignore, that is, for compiler hints. I'd consider "@disable" and "pragma" a compiler hint, but not "@property"

@disable is definitely not something a compiler should be allowed to ignore.

> length() @warningonuse "in this class the length-function is O(n), consider xyz instead"

This is a terrible example - in D it's generally accepted that such a `length` function should NOT be provided at all. If it provides anything that standard algorithms like `walkLength` don't, then it must at least be named something other than `length`.

With this philosophy in mind and with the lack of any good examples, I think it's possible that @warningonuse is in fact undesirable.

On Saturday, 28 December 2013 at 11:58:48 UTC, Jakob Ovrum wrote:
> This is a terrible example - in D it's generally accepted that such a `length` function should NOT be provided at all.

Correction: in the D-community it is generally accepted.

But the reasoning behind this is not sound, it puts the burden on the programmer when you can afford to use O(N). The reasoning is also flawed in general because the amortized/average performance of algorithms depends on the structure of the input. If you know that N tends to be below K on average then the performance hit is O(1) even if the complexity is O(N) on unbounded input on a turing-machine. And if we are going to be pedantic: all algorithms that terminates on a von Neuman-computing device are O(1) because you can always come up with a constant upper bound that holds for all physical computing devices.

@disable and (@obsolete) etc can safely be ignored for a sound program, it is a hint for the compiler to check the integrity of the logic, but it does not affect the semantics of a sound program. The same goes for unittests, pre conditions and post conditions etc.

On Saturday, 28 December 2013 at 13:03:30 UTC, Ola Fosheim Grøstad wrote:
> @disable and (@obsolete) etc can safely be ignored for a sound program, it is a hint for the compiler to check the integrity of the logic, but it does not affect the semantics of a sound program. The same goes for unittests, pre conditions and post conditions etc.

D has extensive compile-time introspection. If @disable was ignored it would change the result of some static if statements, including template constraints, changing the meaning of code. Even worse, this change could appear silently. The same goes for anything else that can be tested for at compile-time.

On 2013-12-28 12:38, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> I don't grasp the motivation for the naming of keywords in D. I think
> the syntax would be more clear if "@" was reserved for compiler hints.

Originally @ was added for some new keywords to get a new "namespace" for keywords. There was no risk of conflict with existing symbol names since @ wasn't allowed in symbol names. Since UDA's were introduces this isn't the case anymore.

-- 
/Jacob Carlborg

On Saturday, 28 December 2013 at 13:47:48 UTC, John Colvin wrote:
> D has extensive compile-time introspection. If @disable was ignored it would change the result of some static if statements, including template constraints, changing the meaning of code. Even worse, this change could appear silently. The same goes for anything else that can be tested for at compile-time.

Thanks for this perspective, this makes the distinction between integrity and functionality fuzzy. I am not sure if I like that or the effect it has on debugging/programming-in-large… I prefer languages that conceptually and visually try to separate different layers (e.g. the job of "lint" and the job of "code-generation").

On Saturday, 28 December 2013 at 14:32:20 UTC, Jacob Carlborg wrote:
> Originally @ was added for some new keywords to get a new "namespace" for keywords. There was no risk of conflict with

Understand. Objective-C and Python also suffers from the arbitrary "@" syntax. Basically what I would like to see is "@keyword" on stuff that can be hidden without making the semantics less clear (so you could have a "hide/show" button in your editor). I think it also would make the language easier for newbies if they can easily separate advanced-stuff-I-don't-need-to-understand-yet from more vital constructs.

It is easy to come up with many potentially useful "compiler hints" for programmers that care about performance:

// allocate simd-aligned and 0-padded string by sacrificing memory for efficiency,
// if supported

@simd string

// force loop-unrolling modulo 4 in order to trigger SIMD optimizations

@unroll(4) for(…) {}

etc...

On Saturday, 28 December 2013 at 15:27:36 UTC, Ola Fosheim Grøstad wrote:
> Thanks for this perspective, this makes the distinction between integrity and functionality fuzzy. I am not sure if I like that or the effect it has on debugging/programming-in-large… I prefer languages that conceptually and visually try to separate different layers (e.g. the job of "lint" and the job of "code-generation").

This is a solid approach and rationale behind trying to minimize warnings in D as much as possible (and potentially remove at all once standard lint-like tool will appear).

However it looks like you are mistaken in considering elements from your examples belonging to additional analysis layer. Anything that directly impacts basic semantical correctness of program is business of compiler core. Defining additional tokens that are invisible to introspection and supposed to be used only by lints may be useful but is not worth discussing until at least on such tool will mature.

Usage of "@" for new keywords is just a matter of avoiding name clashes with existing user code.