Am 06.11.2012 16:18, schrieb Walter Bright:> On 11/6/2012 6:30 AM, dennis luehring wrote:
>   > Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
>   >> On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
>   >>> User Defined Attributes (UDA) are compile time expressions that
>   >>> can be attached to a declaration.
>   >>
>   >> Hmmm, it didn't work on the most important place for my use case,
>   >> function parameters:
>   >>
>   >> void a(["test"] int foo) {
>   >>       pragma(msg, __traits(getAttributes, foo));
>   >> }
>   >
>   > sad - but its still very young feature :)
>   >
>   > im using something like an description on my methods to describe parameter
>   > "features" for an resource manager - something like "read", "write", "copy",
>   > "read_write" etc.
> But there's already out=write, read=all of them, read_write=ref, copy=not a ref
> or an out.

and now expand that to an higher level manager that use such information for implementing(generating) runtime loading and locking strategies in a tree/graph based environment - based on the parameters needs ... i've got something like that in C++ using its own interface description language and an generator

>
> I don't know what use UDAs would be for parameters.
>

exact the same as for every other symbol - it enriches the semantic meaning of that symbol :)

On 11/6/2012 8:27 AM, deadalnix wrote:
> OK, I may break all the happiness of that news but . . .
>
> Tuple in D is notoriously known to be a badly designed feature. Basing more
> stuff on that just because we have them is short sighted and will only result in
> D's tuples being broken forever, several tuples implementations for more user
> confusion, or future major breakage.

The only real trouble with tuples is that functions can't return them.


> We still don't have any scheme for a stable D, feature testing or whatever,

Are you aware of the test suite and the auto-tester?


> Let's not talk these awesome static code analysis tools, java would become jealous.

I have no idea what your point is.

Walter Bright:

> It would be a significant extension, and so I'd like to see a compelling use case first.

Right. Combined with the trait to read function arguments, it's useful to add semantics to function arguments. This is good.


> User defined attributes cannot invent new semantics for the language.

Right, that's my point :-)


> And besides, 'ref' already does what you suggest.

Nope. I have discussed the topic here:
http://forum.dlang.org/thread/znbtczbgipqqzllafmzk@forum.dlang.org

"ref" is useful to denote Case2 of that post of mine. But the @copy annotation I was talking here is the very uncommon (but unfortunately often used by mistake, and common source of bugs) Case3.

Bye,
bearophile

On 11/6/2012 8:42 AM, dennis luehring wrote:
> Am 06.11.2012 16:18, schrieb Walter Bright:> On 11/6/2012 6:30 AM, dennis
> luehring wrote:
>  >   > Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
>  >   >> On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
>  >   >>> User Defined Attributes (UDA) are compile time expressions that
>  >   >>> can be attached to a declaration.
>  >   >>
>  >   >> Hmmm, it didn't work on the most important place for my use case,
>  >   >> function parameters:
>  >   >>
>  >   >> void a(["test"] int foo) {
>  >   >>       pragma(msg, __traits(getAttributes, foo));
>  >   >> }
>  >   >
>  >   > sad - but its still very young feature :)
>  >   >
>  >   > im using something like an description on my methods to describe parameter
>  >   > "features" for an resource manager - something like "read", "write", "copy",
>  >   > "read_write" etc.
>  > But there's already out=write, read=all of them, read_write=ref, copy=not a ref
>  > or an out.
>
> and now expand that to an higher level manager that use such information for
> implementing(generating) runtime loading and locking strategies in a tree/graph
> based environment - based on the parameters needs ... i've got something like
> that in C++ using its own interface description language and an generator

But D already has parameter attributes that cover those bases. What would UDAs add to that? (I know C++ is deficient in this, which is why IDL was invented, but I don't see what UDAs add to what D already provides - no IDL is needed for D).

Le 06/11/2012 17:46, Walter Bright a écrit :
> On 11/6/2012 8:27 AM, deadalnix wrote:
>> OK, I may break all the happiness of that news but . . .
>>
>> Tuple in D is notoriously known to be a badly designed feature. Basing
>> more
>> stuff on that just because we have them is short sighted and will only
>> result in
>> D's tuples being broken forever, several tuples implementations for
>> more user
>> confusion, or future major breakage.
>
> The only real trouble with tuples is that functions can't return them.
>

If it is the only problem, we have a pandemic spread of hallucinogen trance amongs D users.

>
>> We still don't have any scheme for a stable D, feature testing or
>> whatever,
>
> Are you aware of the test suite and the auto-tester?
>

Yes, I'm also aware I hit compiler bugs on a daily basis, that my codebase is full of workaround on some of them.

>
>> Let's not talk these awesome static code analysis tools, java would
>> become jealous.
>
> I have no idea what your point is.

My point is that we have no tooling. Project exists, but they all ends up dead at some point or ends up not caring about compatibility that much (I'm aware of at least 3 serious D like projects that dropped dmd compatibility after spending quite a lot of time on it).

The situation is really bad in that regard (many stuff are implementation defined, or even not defined at all because the implementation is known to be buggy), and adding surprise, half specified features are really not helping.

If you have no idea what my point is, I'm probably wasting my time working on D.

On Tuesday, 6 November 2012 at 08:26:14 UTC, Walter Bright wrote:
> We can debate the syntax. I don't have a store set by this one. I was more interested in getting the semantics right. Anyhow, it's nice to have a working prototype to experiment with rather than a paper airplane.

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.

What if the implementation doesn't pan out as planned? Do you want to delay the next release until the new feature has become stable? It can be a big mess to hastily revert the commits again after the same areas might have been touched by other, unrelated sets of changes.

This is exactly what branches are good for. People can experiment with the new additions and shortcomings can be fixed, and then, if everything looks solid, the branch can be merged back into master – without affecting work on the main branch in the meantime (it has been three months since the last release, and there are quite a few open regressions).

Even Andrei submits pull requests for any non-trivial Phobos changes. Might I suggest adopting a similar policy for DMD, at least when language changes/additions are concerned?

David

On 11/6/2012 8:47 AM, bearophile wrote:
> Walter Bright:
>
>> It would be a significant extension, and so I'd like to see a compelling use
>> case first.
>
> Right. Combined with the trait to read function arguments, it's useful to add
> semantics to function arguments. This is good.

Ok, I ask again, what use case for a UDA is there for function parameters? (Note that IDL isn't it, as D already has enough parameter attributes to support IDL.)


>> User defined attributes cannot invent new semantics for the language.
>
> Right, that's my point :-)

So it cannot work for the use case you suggested. I'm still asking for a compelling use case.


>> And besides, 'ref' already does what you suggest.
>
> Nope. I have discussed the topic here:
> http://forum.dlang.org/thread/znbtczbgipqqzllafmzk@forum.dlang.org
>
> "ref" is useful to denote Case2 of that post of mine. But the @copy annotation I
> was talking here is the very uncommon (but unfortunately often used by mistake,
> and common source of bugs) Case3.

I don't see how having the user add a UDA is better than having the user add "const".

Am 06.11.2012 17:50, schrieb Walter Bright:
> On 11/6/2012 8:42 AM, dennis luehring wrote:
>> Am 06.11.2012 16:18, schrieb Walter Bright:> On 11/6/2012 6:30 AM, dennis
>> luehring wrote:
>>  >   > Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
>>  >   >> On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
>>  >   >>> User Defined Attributes (UDA) are compile time expressions that
>>  >   >>> can be attached to a declaration.
>>  >   >>
>>  >   >> Hmmm, it didn't work on the most important place for my use case,
>>  >   >> function parameters:
>>  >   >>
>>  >   >> void a(["test"] int foo) {
>>  >   >>       pragma(msg, __traits(getAttributes, foo));
>>  >   >> }
>>  >   >
>>  >   > sad - but its still very young feature :)
>>  >   >
>>  >   > im using something like an description on my methods to describe parameter
>>  >   > "features" for an resource manager - something like "read", "write", "copy",
>>  >   > "read_write" etc.
>>  > But there's already out=write, read=all of them, read_write=ref, copy=not a ref
>>  > or an out.
>>
>> and now expand that to an higher level manager that use such information for
>> implementing(generating) runtime loading and locking strategies in a tree/graph
>> based environment - based on the parameters needs ... i've got something like
>> that in C++ using its own interface description language and an generator
>
> But D already has parameter attributes that cover those bases. What would UDAs
> add to that? (I know C++ is deficient in this, which is why IDL was invented,
> but I don't see what UDAs add to what D already provides - no IDL is needed for D).
>

just 2 questions:

1. what if my needs are beyond D?

for example my idl allows me to define a type based query source for parameters

CalculateStuff( TypeX [source="\\placement\(typeA|typeB|typeC)"] my_usage )

this defines the source of assignable objects to this method

2. what is the reason for stopping right before parameters? (except less coding on your side)

Le 06/11/2012 17:37, Walter Bright a écrit :
> On 11/6/2012 8:29 AM, deadalnix wrote:
>> In addition, this is [] thing will require lookahead when parsing to
>> detect if
>> we have an expression (array literal) or a declaration.
>
> Not really, as an array literal starting an expression is kinda
> meaningless,

Not with UFCS.

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.