[swift-evolution] Changing __LINE__ to #line (was Re: [Review] SE-0022: Referencing the Objective-C selector of a method)

[Andrew Bennett]

I think `#location` (or similar) as a tuple is much nicer than having
several `___SOMETHING___`s. I think a solution that doesn't exploit default
arguments is better, especially if it can reduce the number of reserved
words (not that I expect anyone to accidentally call something `__LINE__`.

I think Chris' point about accessing fields on the default argument needs
to be addressed before a tuple is a workable solution.

Another reason to not use a tuple (yet) is that the labels on the tuple are
insufficient to distinguish it, and/or Swift doesn't yet let you add an
extension to a tuple type.

This is a contrived example (I skipped part of the tuple for brevity):

typealias SourceLocation = (line: Int, file: String)

typealias RepeatConfig   = (count: Int, string: String)

func print(location: SourceLocation) {

    print("\(location.file):\(location.line)")

}

func print(config: RepeatConfig) {

    for _ in 1 ... config.count { print(config.string) }

}

print((1,"this is ambiguous"))


This results in a compile-time error:

extension SourceLocation {

    var stringForError: String {

        return "\(self.file):\(self.line)"

    }

}


Error:

*non-nominal type 'SourceLocation' (aka '(line: Int, file: String)') cannot
be extended*



On Sat, Jan 23, 2016 at 11:31 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jan 22, 2016, at 4:21 PM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > It's only a "compiler-known type" if it's defined that way. What's wrong
> with just a regular tuple?
> > #location = (path: __FILE__, line: __LINE__, column: __COLUMN__,
> function: __FUNCTION__)
>
> This would make sense to me.  One complexity here is that you’d want to
> use:
>
> func f(a : Int = #location.line) {}
>
> and our default argument model doesn’t support that.  A default argument
> is either an expression, or one of these magic __LINE__ indicators.  They
> aren’t really first-class values.
>
> -Chris
>
> >
> > - Dave Sweeris
> >
> >> On Jan 22, 2016, at 11:42, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>
> >>> On Jan 21, 2016, at 21:44, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>>
> >>>> On Jan 21, 2016, at 9:25 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>>
> >>>> Okay, you know this was coming: let's Groff this thing.
> >>>>
> >>>> How about #(line) where you can decouple the specific compiler
> implementation bits from the keyword bits without hardcoding support,
> enabling implementation of, for example, #(runcible) for future Swift
> compiler substitution logic.
> >>>
> >>> If you're going to bring me into it…I would prefer coalescing all
> these __FILE__, __LINE__, etc. things into one #sourceLocation structure.
> If you want one source-location-related thing, you tend to want the others,
> and you also want to be able to forward the source location info easily
> through the depths of your assertion/logging framework.
> >>
> >> The downside is that this becomes Yet Another Compiler-Known Type and
> Yet Another Thing In the Standard Library. All the current fields are
> string literals and integer literals.
> >>
> >> Jordan
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/29282562/attachment.html>