> On Nov 2, 2017, at 7:05 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> Firstly, because for the proposed use case it's not a "default" parameter in
> that it's not overridable: you can't actually pass another argument.
Sure you can. Remember, you can call an operator with function-call synt
> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution
> wrote:
>
> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.
>
> Chris has mentioned in interviews that such a system is "a big feature that’s
> open-ended and requires a huge design process” which ma
> On Nov 3, 2017, at 9:16 PM, Swift via swift-evolution
> wrote:
>
> It’s possible I missed something, but my attempt at implementing it only
> touched 3 files. One was the actual implementation, another was adapting the
> diagnostics messages, and the third was the tests.
>
> I’m still ne
> On Nov 3, 2017, at 9:59 PM, Chris Lattner wrote:
>
>
>> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution
>> wrote:
>>
>> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.
>>
>> Chris has mentioned in interviews that such a system is "a big feature
>
> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution
> wrote:
>
> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.
>
> Chris has mentioned in interviews that such a system is "a big feature that’s
> open-ended and requires a huge design process” which mak
The call stack could certainly be a worthwhile thing to capture in an operator
implementation. The #file and #line would tell you which usage of the operator
you’re using, and the callStackSymbols would tell you how you got there. You’d
want them both, however, if you used the same custom operat
on Fri, 3 Nov 2017 09:40:35 -0600 Dave DeLong wrote:
> That’s cool, but a hygienic macro system isn’t anywhere on the Swift
roadmap.
>
> Chris has mentioned in interviews that such a system is "a big feature
that’s open-ended and requires a huge design process” which makes
off-the-table for Swift
That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.
Chris has mentioned in interviews that such a system is "a big feature that’s
open-ended and requires a huge design process” which makes off-the-table for
Swift 5, and (I’m guessing) unlikely for Swift 6 too.
Personal
Yeah. There are so many pitfalls to passing parameters implicitly. It only
works for exceptions because the function is annotated with throws.
Eric
> On Nov 2, 2017, at 10:05 PM, Xiaodi Wu wrote:
>
> I think the use case is legitimate, but I'm uncomfortable with the proposed
> solution. Fir
I think the use case is legitimate, but I'm uncomfortable with the proposed
solution. Firstly, because for the proposed use case it's not a "default"
parameter in that it's not overridable: you can't actually pass another
argument. Secondly, because you wouldn't want the two parameters of an
infix
I think this makes more sense as part of a hygienic macro system. These
“hidden” parameters could be made available to standard functions using some
sort of convention to exclude them from autocompletion.
Eric
> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution
> wrote:
>
> I li
While I agree that I can’t think of another use-case off the top of my head
(curried operators, somehow? Maybe?), I also don’t necessarily see the benefit
of restricting it.
As the implementation currently stands, we could add new keywords, like #module
or #context (which would capture #file, #
I like this idea as it's presented here, for the debugging/logging reasons
that you stated.
Should we tighten the shackles a little be to validate that *only* the
special #file/#line/#function directives can be permitted for these extra
parameters? I'm struggling to think of a case where we would
13 matches
Mail list logo
