Boston D Meetup: Strawman Structs
Steven Schveighoffer via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Sat Jul 22 19:15:18 PDT 2017
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
More information about the Digitalmars-d-announce
mailing list