# Scoring Java lambdas with imports [duplicate]

In this answer, I used a java.util.List as a parameter to an anonymous function (lambda) answer. So, my question is,

## Should this import be counted to the byte total?

I know, it feels like the obvious answer should be YES - if you don't import java.util.*, my example usage won't compile.

However, it's not that simple. I could declare the type (which we don't score) as BiConsumer<java.util.List<String>, String> - use the full name instead of importing - and then everything would be fine and dandy. To blur the line further, say an external class has a method that takes a BiConsumer<List<String>, <String>. Then, in my test class I could use this lambda without ever referencing the java.util package at all!

To clarify, On scoring imported functions refers to scoring a submission of a default method, where this is still scoring a lambda. The issue here is does the import statement need to be counted in the score, as it is possible to compile the lambda without the import but only under very specific conditions.

## marked as duplicate by Downgoat, Mego♦, Addison Crump, Kevin W., RɪᴋᴇʀMar 24 '16 at 19:48

• I'm not familiar with Java, is it part of Java's standard libraries? Or is it some additional library? – Downgoat Mar 23 '16 at 6:12
• @Downgoat yes, java.util is one of the default classpaths. I don't think this is a dupe as that question concerns scoring when submitting a built in as-is, and this is still a written function. – CAD97 Mar 23 '16 at 11:39
• List is not automatically imported, it requires a specific import statement. This is a duplicate, however, as lambdas are functions. – Addison Crump Mar 23 '16 at 18:23
• @CoolestVeto I may have mis-phrased myself by stating java.util as default, as it does require an import. Either way, I'm considering this solved as YES. I still don't see this as a dupe but maybe I'm missing something as well. – CAD97 Mar 23 '16 at 18:47

## Yes, the import should be scored.

The argument against is that the code could be compiled without it in certain conditions of surrounding code. However, the lambda, though anonymous, is still a function and not a snippet, and this is what makes it an acceptable answer.

To stand alone, the types of the arguments must be accessible, and as such the import should be scored.

More generally, types used as Java lambda parameters must always be imported (and scored as such) or the parameters must be typed to make the lambda a valid stand-alone solution.

• I'm considering the two comments as an effective consensus. I still don't see this as a dupe (I'm not submitting a built-in, just using the features of a List), but I'll leave that to the higher-reps. – CAD97 Mar 23 '16 at 18:45
• That's pretty brutal against languages like Java and C#, which have very few facilities implicitly imported (not even ArrayList/List!) – Alexander Jul 29 '17 at 0:24
• Hey, I asked this because I primarily like golfing in Java/Kotlin. I may rephrase this question later on and try and present it in light of more recent consensus, and see if I can get a better discussion with points on both sides. (And this question was closed as a dupe of something else for some reason I still don't quite understand?) I understand the issue better now as well. But for now, type your lambdas. – CAD97 Jul 29 '17 at 1:05
• @Alexander (see above I forgot to tag you) and also, I've seen multiple answers (from higher rep users) even after this that don't do so. Even more reason to bring it up again. – CAD97 Jul 29 '17 at 1:25
• Yeah, I found this question after searching on whether or not import Foundation adds to my byte count. It's pretty much necessary for any non-trivial work in Swift, especially string manipulation. It's a bummer that it's a fixed tax pretty much any complex string/regex manipulation answer in Swift has to pay – Alexander Jul 29 '17 at 1:27
• @Alexander If you refer to a type by name, there is no question whether you need to count the import. That's just the "practical" language tax :P – CAD97 Jul 29 '17 at 1:46
• Foundation is a framework, not an individual type and as the name implies... it's pretty fundamental :p – Alexander Jul 29 '17 at 2:02
• @Alexander I've used Swift. Swift's import Foundation is basically import stdlib::* in other languages. And if you want to use a Foundation type unfortunately you have to bring it into the namespace somehow... – CAD97 Jul 29 '17 at 2:04
• There's a difference. E.g. in C++ you can import namespace std and then say string s = .... But it's optional. You could instead just say std::string s = .... Same with Java. In Swift, importing is mandatory, and you can't just say Foundation.NSSomething, for example – Alexander Jul 29 '17 at 2:06
• @Alexander I don't write the rules, just interpret them. Unfortunately that's the only fair way to score golf: include all code required to make your submission work. And one of the two reasons I don't use Swift is that I don't like its package system (no namespacing, bring in all of a library's types). (The other is that I use Windows.) Anyway, isn't it more Swifty to use non-NS types when possible anyway? – CAD97 Jul 29 '17 at 2:10
• – Alexander Jul 29 '17 at 2:32