View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2012
Re: User Defined Attributes
On Tuesday, November 06, 2012 01:06:49 Walter Bright wrote:
> On 11/6/2012 12:49 AM, Maxim Fomin wrote:
> > On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
> >> snip
> > 
> > Nice to hear because it was unexpected and was requested prevously by
> > community.
> I've been intending to do it for a while now.

I always figured that it was pretty much a given that we'd get it at some point 
but that we'd wait until things were more stable before adding it. But if it 
was quick and easy to do now, all the better.

- Jonathan M Davis
November 06, 2012
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 20:49:07 UTC, Walter Bright wrote:
> On 11/6/2012 12:28 PM, Max Samukha wrote:
>> In C#, I can distinguish, which of SomeFunkyID instances is 
>> intended for the
>> return value and which for the function itself. How would I do 
>> that if both
>> attributes were piled together in the same tuple?
>
> Make SomeFunkyID a parameter to a ReturnOnly template that 
> you've defined.

Right. However, the discussion is about adding real attributes to 
parameters. We all agree that they are not strictly necessary:

[ParameterAttributes!(SomeFunkyID!...)]
void foo(int x);

But that is what people are complaining about because it is 
inconsistent with other declarations. In other words, if you are 
going to implement parameter attributes, either go all the way or 
don't do that at all.
November 06, 2012
Re: User Defined Attributes
On Monday, November 05, 2012 23:55:49 Walter Bright wrote:
> UDA's can be extracted into an expression tuple using __traits:
> 
> [ 'c' ] string s;
> pragma(msg, __traits(getAttributes, s));
> 
> prints:
> 
> tuple('c')
> 
> If there are no user defined attributes for the symbol, an empty tuple is
> returned. The expression tuple can be turned into a manipulatable tuple:
> 
> template Tuple(T...) {
> alias T Tuple;
> }

Wait. That's a TypeTuple. Tuple is completely different. You're going to create 
serious confusion here if you call it Tuple. Tuple is in std.typecons. And 
we've already seriously discussed renaming TypeTuple to something else because 
it doesn't hold just types and because it really doesn't act like a tuple (if 
it were really a tuple, it wouldn't auto-expand). The idea here may be good, 
but the terminology used is going to cause a lot of confusion.

- Jonathan M Davis
November 06, 2012
Re: User Defined Attributes
On 11/6/2012 12:47 PM, Jonathan M Davis wrote:
> I always figured that it was pretty much a given that we'd get it at some point
> but that we'd wait until things were more stable before adding it. But if it
> was quick and easy to do now, all the better.


Anything I can do to make sure that going back to C++ is too terrible to 
contemplate <g>.

There's also I don't anticipate this being destabilizing. It doesn't affect the 
rest of the language at all. It doesn't break any existing code, or change any 
existing rules.
November 06, 2012
Re: User Defined Attributes
Le 06/11/2012 22:49, Walter Bright a écrit :
> On 11/6/2012 12:47 PM, Jonathan M Davis wrote:
>> I always figured that it was pretty much a given that we'd get it at
>> some point
>> but that we'd wait until things were more stable before adding it. But
>> if it
>> was quick and easy to do now, all the better.
>
>
> Anything I can do to make sure that going back to C++ is too terrible to
> contemplate <g>.
>
> There's also I don't anticipate this being destabilizing. It doesn't
> affect the rest of the language at all. It doesn't break any existing
> code, or change any existing rules.
>

As soon as this is added, code will use it and bugs in that part will 
soon not be limited to users of that part.
November 07, 2012
Re: User Defined Attributes
"Jacob Carlborg" <doob@me.com> wrote in message 
news:k7bp22$1rsc$3@digitalmars.com...
> On 2012-11-06 19:24, David Nadlinger wrote:
>
>> You are right, UDAs must definitely leverage D's module system for
>> encapsulation/disambiguation. Use of string literals (which are
>> intrinsically »global«) as annotations needs to be explicitly 
>> discouraged.
>
> Then why allow it in the first place?
>
> -- 
> /Jacob Carlborg

My thoughts exactly.  It reminds me of the horror of C++ exceptions.  I 
think it would be reasonable to require every annotation is a struct or 
class.
November 07, 2012
Re: User Defined Attributes
On 11/6/2012 6:10 PM, Daniel Murphy wrote:
> My thoughts exactly.  It reminds me of the horror of C++ exceptions.  I
> think it would be reasonable to require every annotation is a struct or
> class.


Good analogy. But I'm not sure at this point if that is the right thing to do.
November 07, 2012
Re: User Defined Attributes
Walter Bright:

> But I'm not sure at this point if that is the right thing to do.

Why?

[If you decide to restrict UDAs, then later it will be easy to 
extend them, it will not break code. While doing the opposite 
break code. It's you the one that has taught me to design things 
this way :-) ]

Bye,
bearophile
November 07, 2012
Re: User Defined Attributes
On 11/6/2012 7:52 PM, bearophile wrote:
> Walter Bright:
>
>> But I'm not sure at this point if that is the right thing to do.
>
> Why?

D was fortunate in having 10 years of experience with C++'s exception system to 
learn from. We don't have that with UDAs.


> [If you decide to restrict UDAs, then later it will be easy to extend them, it
> will not break code. While doing the opposite break code. It's you the one that
> has taught me to design things this way :-) ]

It's a good point, but I have no experience with UDAs. There may be emergent 
behavior with these features that is completely unexpected, and we wouldn't find 
out about it without having it there.

Yes, I know it's a risk.

(And it was a no-brainer to restrict the exception types. But one must be 
careful in drawing analogies in programming, as different things are, well, 
different and can be different in unexpected, surprising ways.)
November 07, 2012
Re: User Defined Attributes
On Tuesday, 6 November 2012 at 18:49:22 UTC, Walter Bright wrote:
> On 11/6/2012 10:10 AM, Jacob Carlborg wrote:
>> Walter, why aren't you using branches for these kind of things?
>
> Because I still think in a linear fashion :-)

Then you may find article about "git flow" useful:
http://nvie.com/posts/a-successful-git-branching-model/

It's basically enough to look at the picture at the beginning to 
get the idea.

git extensions from the author to support that branching model:
https://github.com/nvie/gitflow
11 12 13 14 15 16 17 18 19
Top | Discussion index | About this forum | D home