On 7/21/17 8:49 PM, Nicholas Wilson wrote:
On Friday, 21 July 2017 at 21:55:01 UTC, Steven Schveighoffer wrote:
On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while
writing some MySQL serialization code. Hope you can attend!
https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431
I've set up a live stream for this. No guarantees of the quality, it
will be audio + slideshow.
Waiting for people to arrive, so probably won't start until at least
6:30.
https://www.youtube.com/watch?v=ZxzczSDaobw
Great talk!
Thanks!
Regarding the inferred attribute problem with the concepts like
Straw-man usage, this should not be a problem with my attributes DIP,
since all special attributes become normal attributes and you could just
have an AliasSeq of the required values.
Maybe I'm misunderstanding you, but my concern is that something like this:
struct StrawmanRange(T)
{
...
void popFront() {}
}
So popFront would be inferred to be pure, @safe, and nothrow. However,
since really we want to only do what was specified, we don't want the
compiler inferring this. More specifically, I wouldn't want the
`implements` function generating requirements that a suitable range
struct must have @safe nothrow pure popFront. I don't think
introspection can tell whether the attributes were specified or inferred.
I don't see how being able to combine attributes is going to be able to
prevent compiler inference of them. Or maybe I am missing something?
-Steve
