Eliminate assert and lazy from D?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Oct 13 08:01:07 PDT 2009


Frank Benoit wrote:
> 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.

I'm wary about magic capabilities that are reserved only to the core 
compiler and library. Among other things, one wouldn't be able to write 
their own logging/enforcement library.

Historically, Walter has been prone to magic, but since recently he has 
started systematically using lowering - implement a higher-level feature 
by rewriting it in terms of simpler D code. He eliminated wads of code 
from the compiler that way.

Maybe it's just me, but I clearly remember: after my first Pascal class, 
when I learned that writeln is a "special" function that takes variadic 
arguments, my only desire has been to be able to write "writeln" itself.

>>> 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?

The template is small - all it does is pack the arguments.

void funImpl(Variant[]  args) { ... }

void fun(T...)(T args) {
     return funImpl(variantArray(args));
}


Andrei



More information about the Digitalmars-d mailing list