Remaining conversions to std

[Federico Schwindt]

In this case they will be just casts or we can have the expression edited
to add the conversion.

My only concern is that this will add several type X to type Y functions
and we will have 2 different idioms, e.g. std.real() vs std.real2time().
The first assumes string, the other not.


On Mon, Jun 23, 2014 at 11:07 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> In message <
> CAJV_h0ZYBgiT-rNuUgcsN7fOX4ENJ1L0wDcvGccDqn63fXxq_A at mail.gmail.com>
> , Federico Schwindt writes:
> >--f46d044402f401155b04fc7df6fc
> >Content-Type: text/plain; charset=UTF-8
> >
> >I was thinking we edit the expression in vcc instead of erroring with
> >"Wrong argument type" if formats don't match.
> >Allowed conversions would be:
> >
> >TIME to REAL and INT
> >REAL to TIME and INT
> >INT to TIME and REAL
> >
> >I believe it would be relatively easy but do we want it?
>
> The point here is that you have no way to ask for REAL variable
> in the first place, so how will you trigger the conversion ?
>
> I'd rather stick with the current (simple) rule that the only
> implicit conversions are to STRING, everything else must be
> commanded.
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140623/f0cba2f9/attachment-0001.html>