Eliminate assert and lazy from D?

[Frank Benoit]

Andrei Alexandrescu schrieb:
> Frank Benoit wrote:
>> Andrei Alexandrescu schrieb:
>>> Right now, the language has enough power to express assert as a library
>>> function, as opposed to a primitive construct. (See e.g. enforce.) I
>>> think it would be good to relegate assert to object.d.
>>>
>>> This also brings up "lazy", which seems to be quite botched. Are there
>>> suggestions on how to replicate its functionality in a different way? I
>>> even seem to recall lazy was discussed as a disadvantage in the recent
>>> dialog on reddit, see
>>>
>>> http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
>>>
>>>
>>>
>>> I personally believe it's useful to be able to pass an unevaluated
>>> expression into a function, for example assert and enforce themselves
>>> use that.
>>>
>>> But let's open this for discussion: should assert and/or lazy be
>>> removed? If not, why not? It yes, why? How can we replicate their
>>> functionality?
>>>
>>>
>>> Andrei
>>
>> I have seen lazy only used in its own show case. In log functions. In
>> Tango too it is used in log functions. I use delegates as function
>> parameters often, but not lazy. This is because I may add parameters and
>>  on the caller site, IMO it must be obvious, this expression is not
>> evaluated as others. Maybe it is acceptable to remove lazy and write
>> logging statements with delegate and the curly braces.
>> log({ "bla bla "~info });
> 
> std.contracts.enforce also uses it.
> 

Yes, this is, both are functions that try to help the programmer itself
and are part of the infrastructure. But is lazy useful for e.g. user
libs? Is it useful in an API the user is not fully aware of?
I mean if you call a function and you did not know the argument is lazy,
it may have strange effects. This is why i would avoid lazy. I think the
callers code should have the noticeable different syntax, and we already
have that with the curly braces.

>> A related issue with passing arguments, that i think needs a better
>> solution in D are the variadic arg list. No magic param names and the
>> possibility to pass this list - or a slice of it - to another function.
> 
> I'm hoping that template variadics + arrays of Variant cover all needs.

Doesn't that mean, each call with different arguments will instantiate
another template instance?