View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2012
Re: User Defined Attributes
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 :)
November 06, 2012
Re: User Defined Attributes
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.
November 06, 2012
Re: User Defined Attributes
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
November 06, 2012
Re: User Defined Attributes
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).
November 06, 2012
Re: User Defined Attributes
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.
November 06, 2012
Re: User Defined Attributes
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
November 06, 2012
Re: User Defined Attributes
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".
November 06, 2012
Re: User Defined Attributes
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)
November 06, 2012
Re: User Defined Attributes
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.
November 06, 2012
Re: User Defined Attributes
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.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home