Re: [swift-users] Type inference issue with map and filter chained

[Mark Lacey via swift-users]

> On Sep 24, 2017, at 1:52 AM, Trevör ANNE DENISE via swift-users 
>  wrote:
> 
> Hello everyone, I found this on StackOverflow : 
> https://stackoverflow.com/questions/46381752/swift-4-methods-chaining/ 
> 
> 
> Is this a bug of Swift 4 or is this normal ? I don't understand why the 
> problem only happens when methods are chained !

It’s a bug.

The reason you see this when they are chained is because the type checker (in 
general) often finds multiple potential solutions (meaning a set of types and 
particular function overloads) and then has to select the “best” solution from 
those. For example one solution might involve “map” from type A combined with 
“filter” from type B, and another might involve “map” from type X and “filter” 
from type Y.

For the sake of illustration, let’s say it found only those two solutions in 
your case. Selecting the best solution involves examining the components of the 
solutions and comparing each component to determine which is best. In your 
example we may decide A.map is the best map, but Y.filter is the best filter. 
There is no solution that involves A.map combined with Y.filter, so we consider 
the solution to be ambiguous.

The combination of the type checker and standard library design should ensure 
this never happens, but we have some known bugs we need to work through in 
order to fix all of these cases.

Mark

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Type inference of array element type

[Mark Lacey via swift-users]

> On Mar 24, 2017, at 3:08 AM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> If I declare a variable and initialize it with an array literal whose 
> elements are integer literals and nil literals,
> the compiler will infer the type Array for that variable:
> 
> let arr = [1, nil, 3]
> print(type(of: arr))  // Array
> 
> However, that only works with nominal types such as Int and String. If I do 
> the same thing with an array of tuples,
> I get a compile error:
> 
> let arr = [(1, false), nil, (3, true)]// error: type of 
> expression is ambiguous without more context
> print(type(of: arr))
> 
> Why can't the compiler infer the type Array> in this 
> example? Is there a reason for this or is it a bug?

Offhand it seems like we should be able to properly handle this. Can you open a 
bug report at bugs.swift.org ?

Mark

> 
> Thanks and best regards,
> Toni
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 10:02 AM, piotr gorzelany <piotr.gorzel...@gmail.com> 
> wrote:
> 
> I tried using it with the latest Xcode release (version 8.2).

That was released prior to the addition of the new option. Recent snapshot 
builds from https://swift.org/download/#snapshots 
<https://swift.org/download/#snapshots> as well as the more recent Xcode 8.3 
betas have it.

Mark

> W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.la...@apple.com 
> <mailto:mark.la...@apple.com>> napisał(a):
>> On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzel...@gmail.com 
>> <mailto:piotr.gorzel...@gmail.com>> wrote:
>> 
>> Hi Mark,
>> 
>> Thanks for the answer, its great to know that somebody is working on it!
>> 
>> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
>> in the Other Swift Flags section but that gives me an error when compiling 
>> 
>> :0: error: unknown argument: '-debug-time-expression-type-checking'
>> 
>> Should I rather compile it on the command line using this option?
> 
> I added this to the compiler within the last couple months so you need to be 
> using a recent build in order to use this command-line option. Where did the 
> compiler that you tried it with come from?
> 
> Mark
> 
>> 
>> Regards,
>> Piotr
>> 
>> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> napisał:
>> 
>> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <swift-users@swift.org 
>> > <mailto:swift-users@swift.org>> wrote:
>> >
>> >
>> >> On 23 Mar 2017, at 08:27, David Hart <da...@hartbit.com 
>> >> <mailto:da...@hartbit.com>> wrote:
>> >>
>> >> Yes, it's best to avoid concatenating strings with +. Not only for 
>> >> performance reasons, but it's also less readable than string 
>> >> interpolation:
>> >>
>> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>> >> "?")\n”
>> >
>> > Concatenation may cause the increase, but this solved it too:
>> >
>> >let (clientIpOrNil, serviceOrNil) = 
>> > sockaddrDescription(info.pointee.ai_addr)
>> >let clientIp = clientIpOrNil ?? "?"
>> >let service = serviceOrNil ?? "?"
>> >str += "No: \(count), HostIp: " + clientIp + " at port: " + service 
>> > + "\n”
>> 
>> To make a long story short, expressions combining the results of 
>> nil-coalescing with other operators tend to be very slow to type check at 
>> the moment. I’m working on fixing this (really the more general issue as it 
>> is not specific to ?? but I’ve seen several bug reports that involve that 
>> operator).
>> 
>> I added another command-line option to help track issues like this down (at 
>> the expression level, rather than function level):
>>   -Xfrontend -debug-time-expression-type-checking
>> 
>> If you use that you’ll see a line for every expression that is type-checked, 
>> with source location information, and the time to type check the expression. 
>> In some cases we may not have valid source information (I believe this 
>> generally happens for things the compiler synthesizes rather than user 
>> code), and you’ll see ‘’ rather than the file/line/column info.
>> 
>> Mark
>> 
>> 
>> >
>> > Regards,
>> > Rien.
>> >
>> >
>> >>
>> >> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org 
>> >> <mailto:swift-users@swift.org>> wrote:
>> >>
>> >>> Thanks for that link, used it to track down the worst compile time 
>> >>> offender:
>> >>>
>> >>> This piece of code:
>> >>>
>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> >>> UnsafeMutablePointer) -> String {
>> >>>
>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>> >>>   var count: Int = 0
>> >>>   var info: UnsafeMutablePointer = infoPtr
>> >>>   var str: String = ""
>> >>>
>> >>>   while info != addrInfoNil {
>> >>>
>> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?&

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzel...@gmail.com> 
> wrote:
> 
> Hi Mark,
> 
> Thanks for the answer, its great to know that somebody is working on it!
> 
> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
> in the Other Swift Flags section but that gives me an error when compiling 
> 
> :0: error: unknown argument: '-debug-time-expression-type-checking'
> 
> Should I rather compile it on the command line using this option?

I added this to the compiler within the last couple months so you need to be 
using a recent build in order to use this command-line option. Where did the 
compiler that you tried it with come from?

Mark

> 
> Regards,
> Piotr
> 
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> napisał:
> 
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <swift-users@swift.org 
> > <mailto:swift-users@swift.org>> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart <da...@hartbit.com 
> >> <mailto:da...@hartbit.com>> wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for 
> >> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) = 
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + service 
> > + "\n”
> 
> To make a long story short, expressions combining the results of 
> nil-coalescing with other operators tend to be very slow to type check at the 
> moment. I’m working on fixing this (really the more general issue as it is 
> not specific to ?? but I’ve seen several bug reports that involve that 
> operator).
> 
> I added another command-line option to help track issues like this down (at 
> the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
> 
> If you use that you’ll see a line for every expression that is type-checked, 
> with source location information, and the time to type check the expression. 
> In some cases we may not have valid source information (I believe this 
> generally happens for things the compiler synthesizes rather than user code), 
> and you’ll see ‘’ rather than the file/line/column info.
> 
> Mark
> 
> 
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org 
> >> <mailto:swift-users@swift.org>> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time 
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
> >>> + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> >>> //str += "No: \

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 12:32 AM, Rien via swift-users  
> wrote:
> 
> 
>> On 23 Mar 2017, at 08:27, David Hart  wrote:
>> 
>> Yes, it's best to avoid concatenating strings with +. Not only for 
>> performance reasons, but it's also less readable than string interpolation:
>> 
>> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>> "?")\n”
> 
> Concatenation may cause the increase, but this solved it too:
> 
>let (clientIpOrNil, serviceOrNil) = 
> sockaddrDescription(info.pointee.ai_addr)
>let clientIp = clientIpOrNil ?? "?"
>let service = serviceOrNil ?? "?"
>str += "No: \(count), HostIp: " + clientIp + " at port: " + service + 
> "\n”

To make a long story short, expressions combining the results of nil-coalescing 
with other operators tend to be very slow to type check at the moment. I’m 
working on fixing this (really the more general issue as it is not specific to 
?? but I’ve seen several bug reports that involve that operator).

I added another command-line option to help track issues like this down (at the 
expression level, rather than function level):
  -Xfrontend -debug-time-expression-type-checking

If you use that you’ll see a line for every expression that is type-checked, 
with source location information, and the time to type check the expression. In 
some cases we may not have valid source information (I believe this generally 
happens for things the compiler synthesizes rather than user code), and you’ll 
see ‘’ rather than the file/line/column info.

Mark


> 
> Regards,
> Rien.
> 
> 
>> 
>> On 23 Mar 2017, at 08:11, Rien via swift-users  wrote:
>> 
>>> Thanks for that link, used it to track down the worst compile time offender:
>>> 
>>> This piece of code:
>>> 
>>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> UnsafeMutablePointer) -> String {
>>> 
>>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>>   var count: Int = 0
>>>   var info: UnsafeMutablePointer = infoPtr
>>>   var str: String = ""
>>> 
>>>   while info != addrInfoNil {
>>> 
>>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
>>> (service ?? "?") + "\n"
>>>   count += 1
>>>   info = info.pointee.ai_next
>>>   }
>>>   return str
>>> }
>>> 
>>> Took 38 seconds to compile.
>>> 
>>> Removing the “str” assignment:
>>> 
>>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> UnsafeMutablePointer) -> String {
>>> 
>>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>>   var count: Int = 0
>>>   var info: UnsafeMutablePointer = infoPtr
>>>   var str: String = ""
>>> 
>>>   while info != addrInfoNil {
>>> 
>>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: 
>>> " + (service ?? "?") + "\n"
>>>   count += 1
>>>   info = info.pointee.ai_next
>>>   }
>>>   return str
>>> }
>>> 
>>> Brought it down to 6.6ms
>>> 
>>> Obviously I have to rewrite, but it does show how just one line of code can 
>>> be responsible for approx 80% of the compile time.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
 On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
  wrote:
 
> 
> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>  wrote:
> 
> Hi, I hope I reached the right mailing list to ask a question about 
> tooling.
> 
> Can somebody from the compiler or Xcode team share some tips on how to 
> improve compilation times of larger Swift projects?
> 
> I am an iOS developer and the largest issue my team has with Swift so far 
> is that when the project gets semi large (~30 000 lines) the compilation 
> times start to be high (~10 minutes from clean). This is a MAJOR downside 
> since iOS development oftentimes requires rapid changes to UI or logic. 
> Every person of my team compiles a project at least 10 times a day to 
> test new features or functionalities. When compilation times start to be 
> higher than 10 minutes that gets us to ~1.5h a day of developer time 
> spend just on compiling. Not to mention the focus lost when this is 
> happening.
> 
> I know the Swift Evolution list is buzzing with new ideas and features 
> but from my experience the compilation times is a CRITICAL thing to 
> improve in the next Swift release since it cost real money to waste all 
> those developer hours. Just think of all the hours lost on compiling 
> across all Swift devs worldwide and you will get to probably dozens of 
> thousand of dev hours a day.
> 
> Is the core compiler team 

Re: [swift-users] Overload Resolution of Binary Operators

[Mark Lacey via swift-users]

> On Nov 14, 2016, at 2:05 PM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.

It’s a bug, and one that I’m aware of, but I’m not aware of anything in JIRA 
for it. Do you mind opening an issue there and assigning it to me?

Mark

> 
> Thanks and best regards,
> Toni
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Overload Resolution

[Mark Lacey via swift-users]

> On Oct 6, 2016, at 4:53 AM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> Does someone know a good explanation / summary of Swift's overload resolution 
> rules?
> After reading https://github.com/apple/swift/blob/master/docs/TypeChecker.rst 
>  I understand
> that the overloading resolution happens as part of the constraint solving 
> step in the type 
> checker, but maybe there's a document somewhere, that explains the rules in 
> more detail?

I don’t know of any existing documentation for overload resolution. I was 
hoping to find some time to write something up in the next few months, but I’m 
not sure exactly when I might get to it.

In the meantime the best advice I can give is to dig into the code a bit to 
understand what’s going on. The type checker runs the constraint solver and 
collections all applicable solutions, and then compares these solutions to find 
a winner. That step is done in ConstraintSystem::findBestSolution() in 
CSRanking.cpp. That calls into ConstraintSystem::compareSolutions(), which is 
where most of the specific logic is. It checks overloads, and then checks the 
specific type bindings in each solution.

That code is reasonably well documented, so even without knowing a lot about 
the compiler internals I think it shouldn’t be too hard to follow.

Mark


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Function overload resolution rules

[Mark Lacey via swift-users]

> On Sep 30, 2016, at 5:02 AM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> I am trying to get a better understanding of Swift's function overload 
> resolution rules.
> As far as I can tell, if there are multiple candidates for a function call, 
> Swift favors
> functions for which the least amount of parameters have been ignored / 
> defaulted. For example:
> 
> // Example 1
> func f(x: Int) {  print("f1") }
> func f(x: Int, y: Int = 0) { print("f2") }
> f(x: 0)   // f1
> 
> // Example 2
> func f(x: Int, y: Int = 0) {  print("f1") }
> func f(x: Int, y: Int = 0, z: Int = 0) { print("f2") }
> f(x: 0)   // f1
> 
> It also looks like Swift favors functions with default-value parameters over 
> functions with variadic parameters:
> 
> func f(x: Int = 0) {  print("f1") }
> func f(x: Int...) { print("f2") }
> 
> f()   // f1
> f(x: 1)   // f1
> f(x: 1, 2)// f2 (makes sense because f1 would not work here)
> f(x: 1, 2, 3) // f2 (makes sense because f1 would not work 
> here)
> 
> But then I tested functions with default-value parameters and variadic 
> parameters and things start to get weird.
> For example, this must be a bug, right?
> 
> func f(x: Int..., y: Int = 0) { print(x, y) }
> func f(x: Int...) { print(x) }
> 
> f()   // []
> f(x: 1)   // [1]
> f(x: 1, 2)// [1, 2] 0
> f(x: 1, 2, 3) // [1, 2, 3]
> 
> I think, in this example, it should always call the second overload, because
> no parameter is ignored / defaulted. What do you think?

Can you open a new bug report for this at bugs.swift.org 
?

Mark

> 
> Thanks and best regards,
> Toni
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Assertion Failure When Using the swift-DEVELOPMENT-SNAPSHOT-2016-08-04-a Xcode Toolchain

[Mark Lacey via swift-users]

> On Aug 4, 2016, at 8:51 PM, Saagar Jha via swift-users 
>  wrote:
> 
> Hello Swift Users,
> 
> This afternoon I updated my Xcode to Xcode 8 beta 4, and tried to compile one 
> of my previously migrated Swift 3 projects. Along with a couple of renames, 
> the compiler kept crashing due to a segmentation fault. Since the issue 
> appeared to be similar to SR-2227, which was supposedly fixed with a pull 
> request a couple days ago, I downloaded today’s snapshot toolchain. The new 
> toolchain throws an assertion:
> 
> Assertion failed: (value != OpenExistentials.end() && "didn't see this OVE in 
> a containing OpenExistentialExpr?"), function walkToExprPre, file 
> /Users/buildnode/jenkins/workspace/oss-swift-package-osx/swift/lib/Sema/CSDiag.cpp,
>  line 3082.
> 0  swift0x00010a932ebb 
> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
> 1  swift0x00010a932106 llvm::sys::RunSignalHandlers() 
> + 70
> 2  swift0x00010a93360f SignalHandler(int) + 383
> 3  libsystem_platform.dylib 0x7fffa6122d7a _sigtramp + 26
> 4  libsystem_platform.dylib 0x00010001 _sigtramp + 1508758177
> 5  swift0x00010a93335e abort + 14
> 6  swift0x00010a933341 __assert_rtn + 81
> 7  swift0x000108431879 
> eraseOpenedExistentials(swift::Expr*&)::ExistentialEraser::walkToExprPre(swift::Expr*)
>  + 361
> 8  swift0x0001085b8ea5 (anonymous 
> namespace)::Traversal::visit(swift::Expr*) + 4981
> 9  swift0x0001085b6f75 
> swift::Expr::walk(swift::ASTWalker&) + 53
> 10 swift0x00010842e375 (anonymous 
> namespace)::FailureDiagnosis::typeCheckChildIndependently(swift::Expr*, 
> swift::Type, swift::ContextualTypePurpose, swift::OptionSet unsigned int>, swift::ExprTypeCheckListener*) + 1221
> 11 swift0x000108434ea3 (anonymous 
> namespace)::FailureDiagnosis::typeCheckArgumentChildIndependently(swift::Expr*,
>  swift::Type, (anonymous namespace)::CalleeCandidateInfo const&, 
> swift::OptionSet) + 1987
> 12 swift0x00010843e9a1 (anonymous 
> namespace)::FailureDiagnosis::visitApplyExpr(swift::ApplyExpr*) + 913
> 13 swift0x000108428f6a swift::ASTVisitor<(anonymous 
> namespace)::FailureDiagnosis, bool, void, void, void, void, 
> void>::visit(swift::Expr*) + 170
> 14 swift0x000108422888 
> swift::constraints::ConstraintSystem::diagnoseFailureForExpr(swift::Expr*) + 
> 104
> 15 swift0x0001084289a8 
> swift::constraints::ConstraintSystem::salvage(llvm::SmallVectorImpl&,
>  swift::Expr*) + 4056
> 16 swift0x0001084ab665 
> swift::TypeChecker::solveForExpression(swift::Expr*&, swift::DeclContext*, 
> swift::Type, swift::FreeTypeVariableBinding, swift::ExprTypeCheckListener*, 
> swift::constraints::ConstraintSystem&, 
> llvm::SmallVectorImpl&, 
> swift::OptionSet) + 917
> 17 swift0x0001084b17d1 
> swift::TypeChecker::typeCheckExpression(swift::Expr*&, swift::DeclContext*, 
> swift::TypeLoc, swift::ContextualTypePurpose, 
> swift::OptionSet, 
> swift::ExprTypeCheckListener*, swift::constraints::ConstraintSystem*) + 625
> 18 swift0x00010852c061 swift::ASTVisitor<(anonymous 
> namespace)::StmtChecker, void, swift::Stmt*, void, void, void, 
> void>::visit(swift::Stmt*) + 545
> 19 swift0x00010852c543 swift::ASTVisitor<(anonymous 
> namespace)::StmtChecker, void, swift::Stmt*, void, void, void, 
> void>::visit(swift::Stmt*) + 1795
> 20 swift0x00010852bf8e swift::ASTVisitor<(anonymous 
> namespace)::StmtChecker, void, swift::Stmt*, void, void, void, 
> void>::visit(swift::Stmt*) + 334
> 21 swift0x00010852b369 (anonymous 
> namespace)::StmtChecker::typeCheckBody(swift::BraceStmt*&) + 25
> 22 swift0x00010852a63f 
> swift::TypeChecker::typeCheckFunctionBodyUntil(swift::FuncDecl*, 
> swift::SourceLoc) + 383
> 23 swift0x00010852a463 
> swift::TypeChecker::typeCheckAbstractFunctionBodyUntil(swift::AbstractFunctionDecl*,
>  swift::SourceLoc) + 35
> 24 swift0x00010852afe4 
> swift::TypeChecker::typeCheckAbstractFunctionBody(swift::AbstractFunctionDecl*)
>  + 180
> 25 swift0x0001084e5c56 
> typeCheckFunctionsAndExternalDecls(swift::TypeChecker&) + 166
> 26 swift0x0001084e68f0 
> swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, 
> swift::OptionSet, unsigned int, 
> unsigned int) + 1568
> 27 swift0x00010818798c 
> 

Re: [swift-users] Redeclaration of guard variable is ignored at top-level

[Mark Lacey via swift-users]

> On Jun 16, 2016, at 10:18 PM, Martin R via swift-users 
>  wrote:
> 
> Hi,
> 
> I wonder why the Swift compiler does not complain about the
> redeclaration of `number` after the guard-statement in top-level code:
> 
>// main.swift
>import Swift
> 
>guard let number = Int("1234") else { fatalError() }
>print(number) // Output: 1234
>let number = 5678
>print(number) // Output: 1234
> 
> It looks as if the statement `let number = 5678` is completely ignored.
> 
> However, doing the same inside a function causes a compiler error:
> 
>func foo() {
>guard let number = Int("1234") else { fatalError() }
>print(number)
>let number = 5678 //  error: definition conflicts with previous value
>}
> 
> Tested with
> - Xcode 7.3.1, "Default" and "Snapshot 2016-06-06 (a)" toolchain
> - Xcode 8 beta.
> 
> Am I overlooking something or is that a bug?

Hi Martin,

Yes, this looks like a bug. Can you open a report at bugs.swift.org 
?

Mark

> 
> Martin
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users