Am 06.11.2012 17:41, schrieb Walter Bright:
> On 11/6/2012 8:23 AM, bearophile wrote:
>> Supporting annotations for function arguments is probably an important
>> sub-feature.
>
> It would be a significant extension, and so I'd like to see a compelling
> use case first.
>
>

Having seen how annotations for function arguments in Java 8 might look like, and the annotations everywhere that we have in the enterprise frameworks, I am weary of such support.

--
Paulo

Am 06.11.2012 17:26, schrieb Walter Bright:
> On 11/6/2012 8:02 AM, Tove wrote:
>> On Tuesday, 6 November 2012 at 15:19:53 UTC, Walter Bright wrote:
>>> On 11/6/2012 7:14 AM, Tove wrote:
>>>> Hmmm, actually it doesn't work in plain function/block scope either.
>>>
>>> Right, I don't see a compelling purpose for that, either.
>>
>> Hmm, what about library based GC annotations?
>>
>> ["GC.NoScan"] int* local_p;
>>
>
> I have no idea how you could make that work.

I can only see it work if the runtime is aware of magic annotations, which are kept in the binary.

--
Paulo

On 11/6/2012 10:19 AM, Jacob Carlborg wrote:
> No, what's the difference between this:
>
> @every_body_writes_their_names_like_this int a;
>
> And
>
> ["every_body_writes_their_names_like_this"] int a;
>
> None.
>

You're right, there is none. That's why using type names as attributes is more scalable and robust.

I understand your desire to have attributes be implicitly declared, but I think that implicit declarations have historically been seductive, and much later were realized to be a mistake. This pattern has happened over and over :-)

For example:

   @seperate

and sometime later:

   @separate

How long will it be before that bug is noticed?

Walter Bright:

First of all, assume I know how to use and abuse foreach in all the common and uncommon cases. So in this discussion we can assume we both know well enough what we are talking about. What I am discussing about is a real problem in real D code, a bug-prone characteristic of foreach. We may accept the situation like it is, and do nothing, or we may want to improve the situation. But this doesn't change the fact that there is a problem in the D design of foreach loops when you scan an array of structs. This problem is recognized by several other persons in the D community, it's not a creation of my mind.

That said, let me try again to explain the problem.

>> // Case3 (uncommon)
>> void main() {
>>     auto data = [0, 1, 2, 3];
>>     foreach (@copy x; data)
>>         writeln(++x);
>> }
>
> x is a value type, and it is already copied. And if you did want to copy it,
>
>     foreach (x; data)
>     {   auto copy = x;
>         writeln(++copy);
>     }
>
> I don't see what the annotation buys you, even if it could be made to work.

The point of Case3 is not that I want to copy it again. The annotation by itself buys you nothing. But he annotation is not meant to be the only change in D. There are two changes that need to happen at the same time:


Change1) Make this a compile-time error, this means if you write this code, the compiler refuses your code statically. So "x" despite not being const is like being const, because the compiler does not let you modify it inside the loop, if you try, it gives you an error (so maybe it's simpler to implement this Change1 really as putting "const" on default on x even if you don't write "const" there. C# language is designed this way!):

auto data = [1, 2, 3];
foreach (x; data)
    x++; // compilation error here


Change2) Introduce an annotation like @mutable to denote Case3 (I have replaced @copy with @mutable to make this explanation more clear for you, so maybe @mutable is really a better name for this idea). This means this is accepted, it's like saying that x is not const:

foreach (@mutable x; data)
    writeln(++x); // OK



Why I have suggested this pair of changes? The only purpose of those two changes is to remove one bug-prone situation from D code.

The situation is this:

struct Foo { int x; }
auto data = [Foo(1), Foo(2), Foo(3)];
foreach (f; data)
    f.x++;


What is the programmer trying to write there? Was she trying to change the structs inside data (Case2)? Or was she trying to modify just their copy (Case3)?

The problem is that usually programmers want Case1 or Case2, they most times do not want to write a Case3. But it's very easy to forget "ref". So the programmer wants to write a Case2 but often writes a Case3 by mistake.

The combined presence of Change1 and Change2 removes this source of errors. Because now if you forget "ref" the compiler refuses your code statically. If you want Case3 you add a @copy. In most cases you really meant to use a Case2 so you add "ref" and the D compiler has caught your bug!

If you were trying to write a Case1 you didn't put inside the loop code that modifies the struct, so the error of Change1 is not triggered and you need no @copy nor ref.


I have written probably 250_000+ lines of good-quality D1/D2 code, and bugs like this are still present in my code, so I'd like to remove them from D once and for all:

struct Foo { int x; }
auto data = [Foo(1), Foo(2), Foo(3)];
foreach (f; data)
    f.x++;

Bye,
bearophile

On Tuesday, 6 November 2012 at 17:17:50 UTC, Walter Bright wrote:
> On 11/6/2012 9:06 AM, deadalnix wrote:> Le 06/11/2012 16:15, Walter Bright a écrit :
> >> On 11/6/2012 5:14 AM, Adam D. Ruppe wrote:
> >>> Hmmm, it didn't work on the most important place for my use
> case,
> >>> function
> >>> parameters:
> >>
> >> It didn't occur to me to enable that.
> >>
> >
> > It should work everywhere or not work at all.
>
> You can't have @pure attributes on function parameters, either. Parameters don't work like regular declarations, never have, and I don't know of a language where they do. They even have a different grammar.

C# allows custom attributes on function parameters, including the return value. Actually, it allows custom meta-data everywhere. See a use case here http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx.
I believe Java does the same.

On Tuesday, 6 November 2012 at 18:36:54 UTC, Walter Bright wrote:
> For example:
>
>    @seperate
>
> and sometime later:
>
>    @separate
>
> How long will it be before that bug is noticed?

This doesn't put the @-syntax out of the game, though: @attribute could just be equivalent to @(attribute) and look up "attribute" in the local scope, following the usual rules. This would look much better than the bracket syntax, at least in my opinion, and avoid confusion with array literals.

David

On 11/6/2012 10:10 AM, Jacob Carlborg wrote:
> On 2012-11-06 18:00, David Nadlinger wrote:
>
>> Yes, it is nice to have a working prototype indeed. What is not so nice
>> in my opinion, however, is that this first prototype straight to Git
>> master, without any prior evaluation, at a time where the general goal
>> is to stabilize the language.
>
> Yes, very good point. I don't see why this hasn't been done before, it's dead
> easy. Just use:
>
> $ git checkout -b uda
> # code
> $ git commit -a -m "Add support for user defined attributes"
> $ git push origin uda
>
> Walter, why aren't you using branches for these kind of things?
>

Because I still think in a linear fashion :-)

On 11/6/2012 4:18 AM, Max Samukha wrote:
> Attributes on overloads are critical. Currently fails:

Found & fixed. Thanks!

On 11/6/2012 10:42 AM, Max Samukha wrote:
> C# allows custom attributes on function parameters, including the return value.
> Actually, it allows custom meta-data everywhere. See a use case here
> http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx.

Thank you. Under the "Remarks" section they give some good examples.

As for the return value attributes, I think that can be handled by attributing the function symbol itself, as it can only have one return type.

On 2012-11-06 19:49, Walter Bright wrote:

> Because I still think in a linear fashion :-)

Ok, please, please try to start to use more of the features of git.

-- 
/Jacob Carlborg