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