Started a new thread on this.
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty good. The issues an conveniences
> of throwing anything
I think restricting to user types makes sense because the type is
how you'd actually do anything with it.
My figuring is you'd generally do something like this:
foreach(t; __traits(getAttributes, foo))
static if(is(t == WhatICareAbout)) {
// use it
}
And if what you care about is
On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright
wrote:
Why would you look in module X for an attribute that you have
no reason to believe applies to symbols from X? How would an
attribute for module X's symbols leak out of X on their own?
What if you are using two different librar
On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright
wrote:
One last thing. Sure, string attributes can (and surely would
be) used for different purposes in different libraries. The
presumption is that this would cause a conflict. But would it?
There are two aspects to a UDA - the attri
On 2012-11-08, 00:18, Walter Bright wrote:
Started a new thread on this.
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people
having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty goo
On 11/08/2012 12:18 AM, Walter Bright wrote:
Started a new thread on this.
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people
having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty good.
On 2012-11-08 00:18, Walter Bright wrote:
There's another aspect to this.
D's UDAs are a purely compile time system, attaching arbitrary metadata
to specific symbols. The other UDA systems I'm aware of appear to be
runtime systems.
This implies the use cases will be different - how, I don't re
On Thursday, 8 November 2012 at 09:05:31 UTC, Jacob Carlborg
wrote:
I think we should only allow user defined types marked with
@attribute, i.e.
@attribute struct foo {}
@attribute class foo {}
@attribute interface foo {}
@attribute enum foo {}
And so on.
Or
struct @foo {}
interface @foo {}
On 2012-11-08, 11:56, simendsjo wrote:
On Thursday, 8 November 2012 at 09:05:31 UTC, Jacob Carlborg wrote:
I think we should only allow user defined types marked with @attribute,
i.e.
@attribute struct foo {}
@attribute class foo {}
@attribute interface foo {}
@attribute enum foo {}
And so
On 2012-11-08 11:56, simendsjo wrote:
Or
struct @foo {}
interface @foo {}
enum @foo {0
etc
That syntax looks a bit backwards to me. What if I want to annotate the
attribute.
@serializable struct @foo {}
Looks a bit confusing which is the name of the attribute and the which
is the attached
On Thursday, 8 November 2012 at 13:19:29 UTC, Jacob Carlborg
wrote:
That syntax looks a bit backwards to me. What if I want to
annotate the attribute.
Sorry, I could not resist:
http://cdn.memegenerator.net/instances/400x/29863604.jpg
David
On Thursday, 8 November 2012 at 13:19:29 UTC, Jacob Carlborg
wrote:
On 2012-11-08 11:56, simendsjo wrote:
Or
struct @foo {}
interface @foo {}
enum @foo {0
etc
That syntax looks a bit backwards to me. What if I want to
annotate the attribute.
@serializable struct @foo {}
Looks a bit confus
On 2012-11-08 17:26, David Nadlinger wrote:
Sorry, I could not resist:
http://cdn.memegenerator.net/instances/400x/29863604.jpg
Hehe, exactly :)
--
/Jacob Carlborg
On 2012-11-08 17:53, simendsjo wrote:
I guess it depends. I find it easier to see that it's an attribute,
especially when you annotate it. But it's harder to grep for.
Is foo an attribute or not?
@serializable
@xmlRoot
@attribute
@displayName("foo")
struct foo {}
Is foo an attri
On Thursday, 8 November 2012 at 17:20:39 UTC, Jacob Carlborg
wrote:
On 2012-11-08 17:53, simendsjo wrote:
I guess it depends. I find it easier to see that it's an
attribute,
especially when you annotate it. But it's harder to grep for.
Is foo an attribute or not?
@serializable
@xmlRoot
On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright
wrote:
Started a new thread on this.
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to
people having
> more experience with UDAs than you.
>
> For me the analogy with Excepti
On Thu, 08 Nov 2012 10:05:30 +0100
Jacob Carlborg wrote:
>
> I think we should only allow user defined types marked with
> @attribute, i.e.
>
> @attribute struct foo {}
> @attribute class foo {}
> @attribute interface foo {}
> @attribute enum foo {}
>
> And so on.
>
I completely agree. I real
On Thu, Nov 08, 2012 at 10:45:05PM -0500, Nick Sabalausky wrote:
> On Thu, 08 Nov 2012 10:05:30 +0100
> Jacob Carlborg wrote:
> >
> > I think we should only allow user defined types marked with
> > @attribute, i.e.
> >
> > @attribute struct foo {}
> > @attribute class foo {}
> > @attribute inter
On Friday, 9 November 2012 at 03:45:11 UTC, Nick Sabalausky wrote:
the *one* thing I hate about D ranges is that they don't force
you to explicitly say "Yes, I *intend* this to be an
InputRange" (what are we, Go users?).
Just a note, of course it still wouldn't *force*, but maybe it'd
be a go
On Thu, 8 Nov 2012 20:17:24 -0800
"H. S. Teoh" wrote:
>
> Actually, I just thought of a solution to the whole duck-typing range
> thing:
>
> struct MyRange {
> // Self-documenting: this struct is intended to be a
> // range.
> static assert(isInput
On 11/8/2012 8:18 PM, Adam D. Ruppe wrote:
On Friday, 9 November 2012 at 03:45:11 UTC, Nick Sabalausky wrote:
the *one* thing I hate about D ranges is that they don't force you to
explicitly say "Yes, I *intend* this to be an InputRange" (what are we, Go
users?).
Just a note, of course it stil
On Thursday, November 08, 2012 21:10:55 Walter Bright wrote:
> Many algorithms (at least the ones in Phobos do) already do a check to
> ensure the inputs are the correct kind of range. I don't think you'll get
> very far trying to use a range that isn't a range.
>
> Of course, you can always still
On Thu, Nov 08, 2012 at 11:51:29PM -0500, Nick Sabalausky wrote:
> On Thu, 8 Nov 2012 20:17:24 -0800
> "H. S. Teoh" wrote:
> >
> > Actually, I just thought of a solution to the whole duck-typing range
> > thing:
> >
> > struct MyRange {
> > // Self-documenting: this struct is int
On 11/8/2012 9:24 PM, Jonathan M Davis wrote:
So, I really don't see this as a problem.
Neither do I.
BTW, there's no compiler magic in the world that will statically guarantee you
have a non-buggy implementation of a range.
On Thursday, November 08, 2012 21:49:52 Walter Bright wrote:
> BTW, there's no compiler magic in the world that will statically guarantee
> you have a non-buggy implementation of a range.
That's what unit tests are for. :)
- Jonathan M Davis
On 11/9/12, H. S. Teoh wrote:
> Then all input ranges will have to explicitly declare they are an input
> range thus:
Or:
Change definition of isInputRange to:
---
template isInputRange(T)
{
enum bool isInputRange = (__attributes(T, RequiresInputRangeCheck)
&&
On Thu, Nov 08, 2012 at 09:37:00PM -0800, H. S. Teoh wrote:
> On Thu, Nov 08, 2012 at 11:51:29PM -0500, Nick Sabalausky wrote:
[...]
> > Those are only half-solutions as they only prevent false-negatives,
> > not false-positives. Plus, there's nothing to prevent people from
> > forgetting to do it
On Thu, Nov 08, 2012 at 10:03:03PM -0800, Jonathan M Davis wrote:
> On Thursday, November 08, 2012 21:49:52 Walter Bright wrote:
> > BTW, there's no compiler magic in the world that will statically
> > guarantee you have a non-buggy implementation of a range.
Yeah, that's one major missing feature
On 11/8/2012 10:20 PM, H. S. Teoh wrote:
But of course that's just splitting hairs.
"Let's not go splittin' hares!"
-- Bugs Bunny
On Thu, 08 Nov 2012 21:10:55 -0800
Walter Bright wrote:
>
> Many algorithms (at least the ones in Phobos do) already do a check
> to ensure the inputs are the correct kind of range. I don't think
> you'll get very far trying to use a range that isn't a range.
>
It can't check semantics. If some
On Thu, 8 Nov 2012 21:37:00 -0800
"H. S. Teoh" wrote:
>
> IOW, you want the user-defined type to declare that it's an input
> range, and not just some random struct that happens to have input
> range like functions?
>
Yes.
> What about modifying isInputRange to be something like this:
>
>
On Friday, November 09, 2012 01:44:51 Nick Sabalausky wrote:
> On Thu, 08 Nov 2012 21:10:55 -0800
>
> Walter Bright wrote:
> > Many algorithms (at least the ones in Phobos do) already do a check
> > to ensure the inputs are the correct kind of range. I don't think
> > you'll get very far trying t
On Thu, 08 Nov 2012 21:24:49 -0800
Jonathan M Davis wrote:
> On Thursday, November 08, 2012 21:10:55 Walter Bright wrote:
> > Many algorithms (at least the ones in Phobos do) already do a check
> > to ensure the inputs are the correct kind of range. I don't think
> > you'll get very far trying to
On 11/9/12, H. S. Teoh wrote:
> Yeah, that's one major missing feature from D/Phobos/etc.: a mixin
> template called EliminateBugs that will fix all your program's bugs for
> you. I think that should be the next top priority on D's to-do list! ;-)
Considering you can do a string import of the mod
On Friday, November 09, 2012 01:53:40 Nick Sabalausky wrote:
> Looking at one set of interfaces in isolation, sure the chances might
> be low. (Just like the chances of name collisions when hygeine is
> lacking, and yet we thankfully have a real module system, instead of C's
> clumsy "Well, it shou
On 2012-11-09 07:20, H. S. Teoh wrote:
Well, unittests are a runtime check, and they don't *guarantee*
anything. (One could, in theory, write a pathological pseudo-range that
passes basic unittests but fail to behave like a range in some obscure
corner case. Transient ranges would fall under tha
On Friday, November 09, 2012 08:21:38 Jacob Carlborg wrote:
> On 2012-11-09 07:20, H. S. Teoh wrote:
> > Well, unittests are a runtime check, and they don't *guarantee*
> > anything. (One could, in theory, write a pathological pseudo-range that
> > passes basic unittests but fail to behave like a r
On 2012-11-09 08:28, Jonathan M Davis wrote:
But the types are already tested by the templat constraints and the fact that
they compile at all. It's the functions' runtime behaviors that can't be
tested, and no language can really test that at compile time, whereas unit
test _do_ test the runtim
On Friday, 9 November 2012 at 07:29:28 UTC, Jonathan M Davis
wrote:
On Friday, November 09, 2012 08:21:38 Jacob Carlborg wrote:
On 2012-11-09 07:20, H. S. Teoh wrote:
> Well, unittests are a runtime check, and they don't
> *guarantee*
> anything. (One could, in theory, write a pathological
> p
On Friday, 9 November 2012 at 05:11:05 UTC, Walter Bright wrote:
Many algorithms (at least the ones in Phobos do) already do a
check to ensure the inputs are the correct kind of range.
There's two annoyances there:
1) the error messages can be godawful, not giving you any
indication why. It's
On Friday, 9 November 2012 at 05:25:12 UTC, Jonathan M Davis
wrote:
Given that a range requires a very specific set of functions, I
find it highly unlikely that anything which isn't a range will
qualify as one.
I've had it happen to me several times. Let me show you some code
from my dom.d:
On Friday, November 09, 2012 14:14:01 Adam D. Ruppe wrote:
> Of course, they all have something in common: an open opDispatch.
> But that's a valid D feature so surely I'm not the only one using
> it.
Okay. I can see it happening there, and alias this could cause similar
problems, but if you're a
Le 08/11/2012 11:56, simendsjo a écrit :
On Thursday, 8 November 2012 at 09:05:31 UTC, Jacob Carlborg wrote:
I think we should only allow user defined types marked with
@attribute, i.e.
@attribute struct foo {}
@attribute class foo {}
@attribute interface foo {}
@attribute enum foo {}
And so o
Le 08/11/2012 19:55, simendsjo a écrit :
On Thursday, 8 November 2012 at 17:20:39 UTC, Jacob Carlborg wrote:
On 2012-11-08 17:53, simendsjo wrote:
I guess it depends. I find it easier to see that it's an attribute,
especially when you annotate it. But it's harder to grep for.
Is foo an attrib
Le 08/11/2012 01:11, Timon Gehr a écrit :
On 11/08/2012 12:18 AM, Walter Bright wrote:
Started a new thread on this.
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people
having
> more experience with UDAs than you.
>
> For me the
Le 09/11/2012 07:53, Nick Sabalausky a écrit :
On Thu, 08 Nov 2012 21:24:49 -0800
Jonathan M Davis wrote:
On Thursday, November 08, 2012 21:10:55 Walter Bright wrote:
Many algorithms (at least the ones in Phobos do) already do a check
to ensure the inputs are the correct kind of range. I don'
On 11/09/12 07:41, Nick Sabalausky wrote:
> Of course, it'd be even nicer still to have all this wrapped up in
> some language sugar (D3? ;) ) and just do something like:
>
> struct interface InputRange {
> // ... *declare* .empty, .front, .popFront here
> }
>
> struct interface ForwardRange
47 matches
Mail list logo
