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

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.

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

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.

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.

"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.

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.

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

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.)

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