April 10, 2012
On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-04-09 23:49, deadalnix wrote:
>
>> If it is available at compile time, it is implementable at runtime as a
>> lib. So you pay for it only if you use it, and you don't add feature in
>> the language just because it is convenient.
>
> I'm not saying how it should be implemented, just that it should be accessible at runtime.

I think there was some confusion, read a quote of what you said:

"I don't see why the attributes *should* be accessible at runtime"

Emphasis added.  I think you meant "shouldn't"

-Steve
April 10, 2012
On 2012-04-10 13:41, Steven Schveighoffer wrote:
> On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2012-04-09 23:49, deadalnix wrote:
>>
>>> If it is available at compile time, it is implementable at runtime as a
>>> lib. So you pay for it only if you use it, and you don't add feature in
>>> the language just because it is convenient.
>>
>> I'm not saying how it should be implemented, just that it should be
>> accessible at runtime.
>
> I think there was some confusion, read a quote of what you said:
>
> "I don't see why the attributes *should* be accessible at runtime"
>
> Emphasis added. I think you meant "shouldn't"
>
> -Steve

Yeah, I did, hehe :)

This thread is getting too long now.

-- 
/Jacob Carlborg
April 10, 2012
Am Tue, 10 Apr 2012 13:53:09 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-04-10 13:41, Steven Schveighoffer wrote:
> > On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob@me.com> wrote:
> >
> >> On 2012-04-09 23:49, deadalnix wrote:
> >>
> >>> If it is available at compile time, it is implementable at runtime as a lib. So you pay for it only if you use it, and you don't add feature in the language just because it is convenient.
> >>
> >> I'm not saying how it should be implemented, just that it should be accessible at runtime.
> >
> > I think there was some confusion, read a quote of what you said:
> >
> > "I don't see why the attributes *should* be accessible at runtime"
> >
> > Emphasis added. I think you meant "shouldn't"
> >
> > -Steve
> 
> Yeah, I did, hehe :)
> 
> This thread is getting too long now.

So in the end we more or less agree that Walter and others can implement useful attributes for compile-time, whereas runtime support is nice-to-have (or can be provided by a lib)? My intention is to make it easier for the one who implements them if runtime support proves difficult.

-- 
Marco

April 10, 2012
On 2012-04-10 19:02, Marco Leise wrote:

> So in the end we more or less agree that Walter and others can implement useful attributes for compile-time, whereas runtime support is nice-to-have (or can be provided by a lib)? My intention is to make it easier for the one who implements them if runtime support proves difficult.

Something like that.

-- 
/Jacob Carlborg
April 10, 2012
On 04/10/12 12:32, Timon Gehr wrote:
> On 04/10/2012 12:18 AM, Walter Bright wrote:
>> On 4/6/2012 3:49 AM, Timon Gehr wrote:
>>> On 04/06/2012 12:23 PM, Walter Bright wrote:
>>>> On 4/6/2012 2:54 AM, Timon Gehr wrote:
>>>>> Should add additional information to the type Foo. I don't see any
>>>>> issues with
>>>>> it, and not supporting it would be very strange.
>>>>
>>>> How would:
>>>>
>>>> @attr(foo) int x;
>>>> int y;
>>>>
>>>> work? Are x and y the same type or not?
>>>
>>> Yes, they are.
>>>
>>> (But a future extension might leave this choice up to 'foo')
>>>
>>>> Now, consider:
>>>>
>>>> auto c = b ? x : y;
>>>>
>>>> What type does c have? int or @attr(foo)int ? And that's really just the
>>>> beginning. How about:
>>>>
>>>> struct S(T) {
>>>> T t;
>>>> }
>>>>
>>>> Instantiate it with S!int and S!(@attr(foo)int). Are those the same
>>>> instantiation, or different? If the same, does S.t have the attribute or
>>>> not?
>>>
>>> There is no such thing as an @attr(foo) int, because @attr is not a type
>>> constructor.
>>
>> But you said it was added to the *type*.
> 
> What I said was that it is added to the declaration. If the declaration happens to declare a type, then that must affect the type:
> 
> @attr(foo) struct Foo{} // annotate 'foo'
> 
> @attr(bar) Foo x;
> 
> __traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar'
> 
> __traits(getAttributes, x); // this will find 'bar', but not 'foo'

The last one is the one i'm not sure about. What's the advantage of not reporting 'foo' for 'x'? "Inheriting" the attrs from the type seems attractive, what does separating the attributes achieve in practice?

I'm assuming the type attributes do not influence the type in any way.

While it would be great if one could also have type-changing attributes [1] in addition to the just annotating ones, i'm not going to propose that - there were too many too complicated proposals in these threads already...

artur

[1] think "shared" etc, or multiple string types.
3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »