On Fri, Feb 1, 2019 at 12:59 PM Vern Paxson wrote:
> I don't see how it helps with
> deprecating existing parameters (which seems would be better served with
> some sort of attribute),
Support for in parameters is part of the changes.
But if we don't allow the user to immediately remove the
> The compelling use-case I'd say is the ability to change/deprecate
> event parameters without suddenly breaking people's code since that
> has come up many times already.
I see how it allows adding new parameters. I don't see how it helps with
deprecating existing parameters (which seems would
On 1 Feb 2019, at 11:24, Robin Sommer wrote:
> It's a nice a idea to relax parameter passing to work by name, and
> allow subsets. However, I can't quite get myself to really like it in
> this form, because it *looks* like an error to not have matching
> argument lists. Is there some syntax
On Fri, Feb 1, 2019 at 10:24 AM Robin Sommer wrote:
> On Thu, Jan 31, 2019 at 16:29 -0800, Vern Paxson wrote:
>
> > > global my_event: event(a: count, b: string);
> > > event my_event(b: string)
> > > { print "my_event", b; }
>
> it *looks* like an error to not have matching
>
On Thu, Jan 31, 2019 at 16:29 -0800, Vern Paxson wrote:
> > global my_event: event(a: count, b: string);
> > event my_event(b: string)
> > { print "my_event", b; }
> Is there a compelling use-case that's motivating this change?
I'm sure the main use case is changing an
On Thu, Jan 31, 2019 at 6:29 PM Vern Paxson wrote:
> > * user doesn't care about parameter 'a', so they shouldn't have to list it
> > * it makes it easier for to deprecate/change event parameters
>
> This seems like a pretty niche pair of benefits. Is there a compelling
> use-case that's
