[HN Gopher] Deferred Argument Evaluation
       ___________________________________________________________________
        
       Deferred Argument Evaluation
        
       Author : ibobev
       Score  : 22 points
       Date   : 2022-10-04 12:34 UTC (2 days ago)
        
 (HTM) web link (bannalia.blogspot.com)
 (TXT) w3m dump (bannalia.blogspot.com)
        
       | frankus wrote:
       | Swift has @autoclosure for this: https://docs.swift.org/swift-
       | book/LanguageGuide/Closures.htm...
        
       | slaymaker1907 wrote:
       | I understand why this works now, but stuff like this is why
       | people avoid STL like the plague. Non-C++ languages would have
       | just added a version of try_emplace which accepts a lambda (or a
       | function pointers plus a void pointer context).
       | 
       | Personally, I'd much rather see the try/catch version in my code
       | base than the clever deferred evaluation version.
        
         | thechao wrote:
         | My gut feeling is that a lot of issues in this class are
         | because the allocator for STL containers are built into the
         | container, rather than passed-in. So, rather than:
         | vector v;         v.push_back(Bob{ });
         | 
         | It should be:                   vector v;
         | v.push_back(BobAlloc, Bob{ });
         | 
         | But the ergonomics would be severely lacking.
        
           | leni536 wrote:
           | That's a different issue. Tangentially related that
           | Allocator::construct has the same slightly crippled
           | interface, so both the allocator concept and the container
           | interfaces would needed to be fixed for accepting a lambda.
           | 
           | The stored allocator issue comes up when you need to store a
           | bunch of vectors with the same stateful allocator, and you
           | needlessly have to have a copy in each vector.
        
           | Someone wrote:
           | I don't think that would work.
           | 
           | If every element of a vector can have its own allocator, and
           | you later do                 v.erase(v.end() - 1);
           | 
           | how would the vector know it has to call _BobFree_? The class
           | _could_ store that with each element, but for small element
           | sizes, that's quite a bit of overhead.
        
         | leni536 wrote:
         | That's quite correct. All of the functions in the standard
         | library that have "emplace" in the name would be better off by
         | accepting a lambda. Now they are stuck in having a "perfect
         | forwarding" interface that is not perfect at all.
        
       ___________________________________________________________________
       (page generated 2022-10-06 23:01 UTC)